WA Lookup
Datensätze von Registrierungsprüfungen durchlaufen die Zustände abgeschlossen, ungeklärt und Aktualisierung
Halten Sie abgeschlossene Beobachtungen und ungeklärte Versuche über den gesamten Ergebnis-Lebenszyklus hinweg getrennt.

Der Registrierungsstatus ist eine Beobachtung, kein dauerhaftes Etikett

Eine abgeschlossene WhatsApp-Registrierungsprüfung beantwortet, ob eine E.164-Nummer zum festgehaltenen Prüfzeitpunkt als registriert gemeldet wurde.

Das Ergebnis kann sofort nützlich sein, sollte aber nicht als ewige Eigenschaft wie phone.is_valid gespeichert werden. Telefonnummern und Plattformregistrierungen können sich ändern, und ein späterer technischer Fehler macht ein früheres abgeschlossenes Ergebnis nicht rückgängig. Ein dauerhaftes Modell hält daher sowohl die Entscheidung als auch den Kontext fest, in dem sie entstanden ist.

WA Lookup liefert Registrierungsinformationen synchron. Dadurch lässt sich die Beobachtung genau an der Stelle speichern, an der die Anwendung sie empfängt. Dasselbe Modell sollte dennoch eine abgeschlossene Prüfung von einer Anfrage unterscheiden, die nie eine Registrierungsentscheidung hervorgebracht hat.

Der minimal sinnvolle Ergebnisdatensatz

Feld Beispiel Warum es wichtig ist
source_phone Ursprünglich übermittelter Text Ermöglicht Korrektur und Audit, ohne die Quelle zu verändern
e164_phone +17253100591 Kennzeichnet den normalisierten Wert, der tatsächlich geprüft wurde
service_type ws Kennzeichnet den Ergebnisvertrag
outcome completed Die Klassifizierung Ihrer Anwendung: abgeschlossenes Ergebnis oder fehlgeschlagene Anfrage
registered true oder false Speichert das abgeschlossene Registrierungsergebnis
received_at Zeitstempel der Anwendung Hält fest, wann die synchrone Antwort eingegangen ist
api_code 0 Hält das äußere API-Ergebnis von der Registrierungsbeobachtung getrennt

Setzen Sie registered nur bei einer abgeschlossenen Entscheidung. Protokollieren Sie HTTP-Status und API-Code separat, wenn die Anwendung eine Fehlerhistorie benötigt; machen Sie aus diesen Antworten keinen weiteren Registrierungswert.

Die drei Antwortformen korrekt speichern

Der dokumentierte Vertrag kennt zwei Formen abgeschlossener Ergebnisse und eine separate Fehlerform:

  1. Abgeschlossenes Ergebnis „registriert“ – code=0 und data.registered=true.
  2. Abgeschlossenes Ergebnis „nicht registriert“ – code=0 und data.registered=false.
  3. Keine Entscheidung – ein API-Code ungleich null, ohne registered-Wert, der gespeichert werden könnte.

Ungültige Eingaben, unzureichendes Guthaben, Parallelitätslimits, Timeouts, Wartungsarbeiten und interne Fehler verwenden API-Codes ungleich null. Es handelt sich um Anfragefehler, nicht um Werte des WhatsApp-Registrierungsergebnisses.

Historie bewahren, wenn eine neue Prüfung läuft

Benötigt die Anwendung einen neueren Status, fügen Sie eine neue Beobachtung hinzu oder versionieren Sie den bestehenden Datensatz. Überschreiben Sie nicht den alten checked_at, während Sie dessen Ergebnis beibehalten, und ersetzen Sie den letzten abgeschlossenen Wert nicht durch false, nur weil eine Aktualisierung fehlgeschlagen ist.

Eine einfache Ansicht des aktuellen Zustands kann die neueste abgeschlossene Beobachtung auswählen, während die zugrunde liegende Tabelle jeden Versuch aufbewahrt. So erhält die Anwendung eine aktuelle Antwort, sofern eine existiert, und kann trotzdem erkennen, ob ein neuerer Versuch ungeklärt blieb.

Situation Letztes abgeschlossenes Ergebnis Separates Anfrageprotokoll
Erste Prüfung wird mit true abgeschlossen true, empfangen zu T1 Erfolg zu T1
Spätere API-Anfrage liefert einen Fehler true, empfangen zu T1 HTTP-/API-Fehler zu T2
Spätere Prüfung wird mit false abgeschlossen false, empfangen zu T3 Erfolg zu T3

Den Aktualisierungszeitpunkt anhand der Geschäftsentscheidung wählen

Es gibt keine universelle Ablaufzeit für ein Registrierungsergebnis. Das passende Aktualitätsfenster hängt davon ab, wie viel Verzögerung der umgebende Workflow verträgt. Eine Nutzeraktion auf Abruf kann eine neue synchrone Prüfung erfordern, während ein Analysebericht einen älteren Zeitstempel akzeptieren kann, solange dessen Alter sichtbar ist.

Legen Sie die Regel ausdrücklich fest:

  • welches maximale Ergebnisalter der Workflow akzeptiert;
  • welche API-Antworten ungleich null einen späteren Aufruf auslösen sollen;
  • nach welchen API-Fehlern der Aufrufer eine erneute Übermittlung vornimmt;
  • wie Parallelitätslimits und Timeouts eingehalten werden;
  • wie Zeitstempel für Bearbeiter angezeigt werden.

Entscheidend ist, einen alten Datenbankwert nicht als Echtzeit auszugeben. WA Lookup liefert beim Aufruf eine synchrone aktuelle Beobachtung; die integrierende Anwendung entscheidet, wann sie erneut aufrufen muss.

Das Prinzip zuverlässiger Speicherung

Speichern Sie Registrierungsbelege als Beobachtungen mit Zeitstempel und operative Versuche als eigene Zustände.

So bleibt registered=false aussagekräftig, Wiederholungen werden sicherer, und jede Oberfläche kann genau angeben, wann ihr angezeigter Status geprüft wurde. Das entspricht auch der Produktgrenze: WA Lookup liefert Ergebnisse von Registrierungsprüfungen, während das Kundensystem für Aufbewahrung, Aktualisierungsrichtlinie und nachgelagerte Entscheidungen verantwortlich ist.

Quellen