WA Lookup
Registros de verificación de registro que pasan por los estados completado, sin resolver y actualización
Mantenga separadas las observaciones completadas y los intentos sin resolver a lo largo de todo el ciclo de vida del resultado.

El estado de registro es una observación, no una etiqueta permanente

Una verificación de registro de WhatsApp completada responde si un número E.164 figuraba como registrado en el momento de verificación registrado.

El resultado puede ser útil de inmediato, pero no debe almacenarse como una propiedad eterna del tipo phone.is_valid. Los números de teléfono y los registros en la plataforma pueden cambiar, y un fallo técnico posterior no revierte un resultado completado anterior. Por tanto, un modelo duradero registra tanto la decisión como el contexto que la produjo.

WA Lookup devuelve la información de registro de forma síncrona. Esto facilita guardar la observación en el momento exacto en que la aplicación la recibe. Aun así, el mismo modelo debe distinguir una verificación completada de una solicitud que nunca produjo una decisión de registro.

El registro de resultado mínimo útil

Campo Ejemplo Por qué es importante
source_phone Texto original enviado Permite la corrección y la auditoría sin modificar el origen
e164_phone +17253100591 Identifica el valor normalizado que realmente se verificó
service_type ws Identifica el contrato del resultado
outcome completed La clasificación de su aplicación de un resultado completado o una solicitud fallida
registered true o false Almacena el resultado de registro completado
received_at Marca de tiempo de la aplicación Registra cuándo llegó la respuesta síncrona
api_code 0 Mantiene el resultado externo de la API separado de la observación de registro

Asigne registered solo para una decisión completada. Registre el estado HTTP y el código de la API por separado cuando la aplicación necesite un historial de errores; no convierta esas respuestas en otro valor de registro.

Almacene con precisión las tres formas de respuesta

El contrato documentado tiene dos formas de resultado completado y una forma de error independiente:

  1. Resultado completado registrado: code=0 y data.registered=true.
  2. Resultado completado no registrado: code=0 y data.registered=false.
  3. Sin decisión: un código de la API distinto de cero, sin ningún valor registered que almacenar.

La entrada no válida, el saldo insuficiente, los límites de concurrencia, los tiempos de espera agotados, el mantenimiento y los fallos internos utilizan códigos de la API distintos de cero. Son errores de solicitud, no valores del resultado de registro de WhatsApp.

Conserve el historial cuando se ejecute una nueva verificación

Si la aplicación necesita un estado más reciente, añada una nueva observación o versione el registro existente. No sobrescriba el checked_at anterior conservando su resultado, y no sustituya el último valor completado por false solo porque una actualización haya fallado.

Una vista sencilla del estado actual puede seleccionar la observación completada más reciente, mientras que la tabla subyacente conserva todos los intentos. Así, la aplicación obtiene una respuesta actual cuando existe y sigue mostrando si un intento más reciente quedó sin resolver.

Situación Último resultado completado Registro de solicitudes independiente
La primera verificación se completa con true true recibido en T1 Éxito en T1
Una solicitud posterior a la API devuelve un error true recibido en T1 Error HTTP/API en T2
Una verificación posterior se completa con false false recibido en T3 Éxito en T3

Elija el momento de actualización según la decisión de negocio

No existe un plazo de caducidad universal para un resultado de registro. La ventana de vigencia adecuada depende de cuánto retraso pueda tolerar el flujo de trabajo en cuestión. Una acción del usuario bajo demanda puede requerir una nueva verificación síncrona, mientras que un informe analítico puede aceptar una marca de tiempo más antigua siempre que su antigüedad sea visible.

Defina la regla de forma explícita:

  • qué antigüedad máxima de resultado acepta el flujo de trabajo;
  • qué respuestas de la API con código distinto de cero deben desencadenar una llamada posterior;
  • tras qué errores de la API el cliente decide volver a enviar la solicitud;
  • cómo se respetan los límites de concurrencia y los tiempos de espera;
  • cómo se muestran las marcas de tiempo a los operadores.

Lo importante es no presentar un valor antiguo de la base de datos como si fuera en tiempo real. WA Lookup proporciona una observación actual y síncrona cuando se le llama; la aplicación integradora decide cuándo necesita volver a llamar.

El principio de almacenamiento fiable

Almacene la evidencia de registro como observaciones con marca de tiempo y almacene los intentos operativos como estados propios.

Esto mantiene el significado de registered=false, hace que los reintentos sean más seguros y permite que cada interfaz indique exactamente cuándo se verificó el estado que muestra. También se ajusta al límite del producto: WA Lookup proporciona resultados de verificación de registro, mientras que el sistema del cliente es responsable de la retención, la política de actualización y las decisiones posteriores.

Fuentes