Registrieren Sie sich und kontaktieren Sie den Support, um 100 kostenlose Prüfungen zu erhalten.Kostenlos registrieren
CarrierLookup Workflow-Illustration zu „Integration der Carrier Lookup API: Workflows für ursprüngliche Netzbetreiber und Leitungstypen“
Ein visueller Überblick über den in diesem CarrierLookup Artikel beschriebenen Workflow.

Integrieren Sie die Carrier Lookup API, um die ursprüngliche Netzbetreiberzuweisung, den Leitungstyp und die geografische Nummerierung mithilfe von REST-Echtzeit-Endpunkten und Massendateiverarbeitung zu überprüfen.

Die Carrier Lookup API bietet Kontext zum ursprünglichen Netzbetreiber und zur Nummernzuweisung für das Telekommunikations-Datenmanagement. Wenn Unternehmen eine Telefonnummer über die API abfragen, liefert der Dienst Daten, die den Betreiber angeben, dem der Nummernblock ursprünglich zugewiesen wurde, sowie den Leitungstyp und die geografische Zuweisung. Diese Informationen repräsentieren die administrative Zuweisung gemäß Nummerierungsplänen und bieten einen stabilen Telekommunikationskontext für interne Routing- und Risikobewertungs-Workflows. Da dies die ursprüngliche Zuweisung widerspiegelt und nicht das aktive Routing im Netz des Teilnehmers, integrieren Teams CarrierLookup, um grundlegende Nummernparameter über Echtzeit-Einzelendpunkte, synchrone Abfragen mehrerer Elemente oder asynchrone Massendateien zu überprüfen.

Grundlegende Zuweisungsdaten und Leitungstyp-Attribute

Telekommunikations-Nummerierungspläne folgen internationalen Standards wie der ITU-T Recommendation E.164, die globale Nummerierungspläne mit Ländervorwahlen und Teilnehmernummern definiert. Innerhalb dieser Strukturen weisen Regulierungsbehörden den Netzbetreibern spezifische Nummernblöcke zu. CarrierLookup macht diese grundlegenden Eigenschaften durch seine Funktion zur Abfrage des ursprünglichen Netzbetreibers zugänglich.

Das Antwortschema organisiert den Telekommunikationskontext in verschiedene Datenpunkte:

  • carrier: Der Kommunikationsanbieter, dem der Nummernbereich ursprünglich zugewiesen wurde.
  • underlying_carrier: Der zugrunde liegende Infrastrukturanbieter, der mit dem zugewiesenen Bereich verbunden ist.
  • number_type: Die Klassifizierung der Leitung, wie z. B. Mobilfunk- oder Festnetzzuweisung.
  • country_code: Die internationale Vorwahl, die dem Zuweisungsgebiet entspricht.
  • region und city: Das administrative geografische Gebiet, das im Nummerierungsplan festgelegt ist.

Diese Datenpunkte etablieren statische Bereichsattribute. Da Nummern ihre ursprünglichen Bereichsdefinitionen unabhängig von der Teilnehmeraktivität beibehalten, fungieren diese Daten als konsistente Referenz für Filterung, Telekommunikationsanalyse und interne Datensatzorganisation.

Echtzeit-Einzel- und Mehrfachprüfungsintegration

Die Integration von Echtzeit-Abfragen ermöglicht es Backend-Systemen, Telefonnummern während der Aufnahme oder bei Überprüfungsworkflows synchron zu bewerten. Anfragen authentifizieren sich über den HTTP-Header X-API-Key, der von einem sicheren Anwendungsserver gesendet wird.

Workflow zur Einzelnummernprüfung

Um eine einzelne Kennung zu überprüfen, senden Sie eine Anfrage an POST /api/v1/check. Die Nutzlast erfordert eine Telefonnummer im internationalen E.164-Standardformat, bestehend aus einem führenden Pluszeichen, der Ländervorwahl und den Teilnehmerziffern ohne Leerzeichen oder Satzzeichen.

Nach der Verarbeitung gibt der Server eine JSON-Antwort zurück, die code, msg und ein flaches data-Objekt enthält. Die Daten-Nutzlast enthält service_type, identifier, carrier, underlying_carrier, number_type, country_code, region und city. Optionale Zuweisungsfelder können leer bleiben, wenn für diesen Bereich keine spezifischen Details gelistet sind, die Abfrage wird jedoch als erfolgreich abgeschlossen registriert.

Synchroner Mehrfachprüfungs-Workflow

Für Batches, die eine sofortige Bewertung erfordern, rufen Unternehmen POST /api/v1/batch-check auf. Dieser Endpunkt verarbeitet mehrere E.164-Nummern synchron in einem einzigen Aufruf. Die Antwort liefert hochrangige Ausführungsmetriken sowie ein geordnetes Array:

  • service_type: Bestätigt den ausgeführten Suchdienst.
  • total: Die Anzahl der übermittelten Kennungen.
  • succeeded: Die Anzahl der erfolgreich bewerteten Elemente.
  • failed: Die Anzahl der Elemente, bei denen Verarbeitungsfehler aufgetreten sind.
  • results: Eine geordnete Sammlung von Elementen, die jeweils identifier und exists enthalten.

In dieser synchronen Mehrfachantwort weist ein exists=false-Wert darauf hin, dass kein Standard-Zuweisungsdatensatz zurückgegeben wurde, anstatt eine getrennte oder fehlerhafte Leitung zu behaupten.

Asynchroner Workflow zur Massendateiverarbeitung

Bei der Verarbeitung umfangreicher Bestände an Telekommunikationsdatensätzen nutzen Teams den asynchronen carrier_batch-Dienst. Dieser Workflow verarbeitet dateibasierte Übermittlungen, ohne dass Client-Verbindungen offen gehalten werden müssen.

Aufgabenübermittlung und Struktur

Senden Sie Batch-Anfragen über POST /api/v1/bulk-tasks unter Verwendung von Multipart-Formulardaten. Der Upload erfordert eine einfache TXT- oder CSV-Datei mit einer Kennung pro Zeile sowie einen spezifizierten ISO-Länderparameter. Es gelten die produktbezogenen Limits für Aufgabengrößen; Leser können die aktuellen Betriebsparameter in der offiziellen API-Dokumentation einsehen.

Während der Aufnahme überprüft eine automatisierte Vorverarbeitung die Listeninhalte, um Duplikate, fehlerhafte Einträge und Zeilen mit Ländern außerhalb des ausgewählten Ziels zu filtern. Die Verarbeitung schließt diese nicht konformen Einträge von der Abfrageabrechnung aus.

Aufgabenlebenszyklus und Abruf

Clients überwachen den Batch-Fortschritt durch Abfrage von GET /api/v1/bulk-tasks/{id}. Abfrageintervalle sollten einem angemessenen Rhythmus folgen, wobei nicht häufiger als alle 30 Sekunden geprüft werden sollte. Der Aufgabenlebenszyklus durchläuft drei formale Zustände:

  • processing: Die Datei wird vom System ausgewertet.
  • failed: Die Aufgabe ist auf einen Ausführungsfehler gestoßen oder hat die Aufnahmevoraussetzungen nicht erfüllt.
  • success: Die Bereichsbewertung ist abgeschlossen und die Ausgabe ist verfügbar.

Wenn eine Aufgabe mit success endet, liefert der Endpunkt eine einzelne CSV-Datei. Die Ausgabestruktur enthält sieben standardisierte Header: identifier, carrier, underlying_carrier, number_type, country_code, region und city. Die Kennung in dieser Datei wird als Ziffern mit Ländervorwahl dargestellt, wobei Pluszeichen weggelassen werden.

Betriebliche Limits und Abdeckungsspezifikationen

Die Implementierung einer Carrier-Lookup-Integration erfordert die Abstimmung der technischen Architektur mit der System-Nebenläufigkeit und geografischen Parametern.

Betriebsparameter Spezifikationsdetails
Nebenläufige Slots 5 gemeinsam genutzte Echtzeit-Anfragen
Timeout für Einzelprüfung 60 Sekunden maximale Dauer
Timeout für Mehrfachprüfung 300 Sekunden maximale Dauer
Nebenläufigkeit für Mehrfach-Anfragen 1 aktive Mehrfach-Anfrage pro Konto
Kontostand-Endpunkt GET /api/v1/balance (gibt balance_micros zurück)

Die geografische Abdeckung weist unterschiedliche regionale Regeln auf. Echtzeit-Einzelnummernabfragen ermöglichen Anfragen für Festlandchina (+86), Hongkong (+852) und Macau (+853) bei moderaten Betriebsvolumina. Massendateien akzeptieren jedoch keine Nummern aus diesen drei Regionen. Der Abdeckungsstatus für Taiwan (+886) bleibt unbestätigt.

Um den Kontostatus vor dem Aufrufen von Prüfungen zu verifizieren, fragen Sie GET /api/v1/balance ab, um den aktuellen Kontostand abzurufen, ohne Abfragen zu verbrauchen. Darüber hinaus können neu registrierte Benutzer den Support kontaktieren, um 100 kostenlose Prüfungen zu erhalten, um ihre Integrations-Workflows mit Produktionsendpunkten zu validieren.

FAQ

Wie geht die API mit Nummern um, die zwischen Netzbetreibern portiert wurden?

CarrierLookup meldet den Betreiber, dem der Nummernbereich ursprünglich von den Verwaltungsbehörden zugewiesen wurde. In der Telekommunikation können Verbraucher den Anbieter wechseln und dabei ihre Nummer behalten, wie unter Porting: Keeping Your Phone Number When You Change Providers beschrieben. Folglich spiegelt das Feld carrier diese historische Bereichszuweisung wider und nicht den aktuell versorgenden Betreiber, wodurch ein unveränderliches strukturelles Attribut für die Nummerierungsanalyse beibehalten wird.

Was unterscheidet die Echtzeit-Mehrfachprüfung vom Massen-Batch-Dienst?

Der Echtzeit-Mehrfachprüfungs-Endpunkt POST /api/v1/batch-check bewertet Nummern synchron und liefert eine sofortige JSON-Nutzlast mit service_type, total, succeeded, failed sowie geordneten Ergebnissen, die die Kennung und einen exists-Booleschen Wert enthalten. Im Gegensatz dazu verarbeitet der Massen-Batch-Dienst Listen asynchron aus übermittelten CSV- oder TXT-Dateien. Sobald die Hintergrundanalyse abgeschlossen ist, stellen Massenaufgaben eine herunterladbare CSV-Datei bereit, die vollständige Zuweisungsspalten einschließlich carrier, underlying_carrier, number_type, country_code, region und city enthält.

Geben die Felder für Region und Stadt den physischen Standort des Geräts an?

Die Felder region und city bezeichnen die geografische Grenze der ursprünglichen Nummerierungsplan-Zuweisung, die der administrativen Zuweisung der Telefonvermittlung entspricht. Diese Werte bieten territorialen Kontext für den Teilnehmernummernblock. Sie repräsentieren statische Nummerierungszuweisungen und keine Echtzeit-Mobilgerätelokalisierung, Live-Mobilfunkmastverbindungen oder den physischen Aufenthaltsort eines einzelnen Teilnehmers.

Mehr erfahren

Wählen Sie die Produktinformationen, die zum nächsten Schritt in Ihrem Workflow passen.

Quellen