Saltar al contingut principal
L’informe de Verificació de telèfon recull el resultat complet d’un desafiament OTP telefònic: a qui hem enviat el codi, quin operador i canal l’han gestionat, quants intents han calgut, si el número és d’un sol ús o VoIP, i qualsevol coincidència entre sessions amb la teva llista de bloqueig o amb les sessions d’altres usuaris. Aquesta pàgina documenta l’estructura JSON que retorna l’endpoint de decisió perquè puguis analitzar els resultats de l’OTP, les metadades de l’operador i els indicadors de risc de cada número verificat.
Informe de verificació de telèfon de Didit que mostra el resultat de l'OTP, les metadades de l'operador i els indicadors de risc

Visió general

Es genera un informe de telèfon cada vegada que un node del flux de treball executa la funcionalitat de Verificació de telèfon. Cada informe representa un desafiament OTP per a un número de telèfon i conté:
  • El número de telèfon desglossat en prefix, número nacional i format E.164 complet, a més del codi de país ISO i el nom del país.
  • Metadades de l’operador (name, type) obtingudes a partir de la xarxa de destinació.
  • Indicadors booleans de risc (is_disposable, is_virtual) derivats de l’anàlisi del tipus de línia.
  • El canal de lliurament real utilitzat (verification_method) i el nombre d’intents d’enviament de l’OTP.
  • Un registre cronològic lifecycle[] de cada enviament, reintent, esdeveniment de lliurament i intent de comprovació del codi.
  • Una matriu matches[] que mostra el mateix número en altres sessions —de qualsevol estat, tant en verificacions KYC i KYB com en verificacions independents mitjançant l’API— o a la teva llista de bloqueig.
  • Una matriu warnings[]: esdeveniments de risc emesos durant la verificació (consulta Advertències de Verificació de telèfon).
  • Un node_id que identifica quin node del graf del flux de treball ha generat l’informe (només sessions V3).
En els fluxos de verificació allotjats, Didit gestiona l’intercanvi d’OTP per tu. Per a les integracions directes de l’API, el mateix flux consisteix en dues crides: POST /v3/phone/send/ per lliurar el codi i POST /v3/phone/check/ per validar l’entrada de l’usuari. Un OTP pendent és vàlid durant 5 minuts des del primer enviament (els reintents no amplien aquest període). En les sessions de flux de treball, els usuaris tenen per defecte 2 intents d’enviament d’OTP (phone_max_retries) i 2 intents d’introducció del codi (phone_max_check_attempts), ambdós configurables per node del flux de treball; esgotar qualsevol d’aquests límits finalitza el pas com a Declined amb VERIFICATION_CODE_ATTEMPTS_EXCEEDED. L’API de telèfon independent permet 3 intents d’introducció del codi per verificació.

On apareix a les respostes de l’API

L’endpoint de decisió (GET /v3/session/{sessionId}/decision/) retorna els informes de telèfon sota la clau d’array en plural phone_verifications. L’array conté una entrada per cada node de Verificació de telèfon al graf del flux de treball —normalment una, però els fluxos d’escalada en poden generar diverses.
Un valor null significa que encara no s’ha executat cap pas de Verificació de telèfon. Itera sobre l’array (en lloc de llegir directament phone_verifications[0]) quan el teu flux de treball pugui recollir més d’un número de telèfon.

Esquema

L’esquema canònic camp per camp es troba a la pàgina Models de dades.

Valors d’estat

Tipus d’esdeveniments del cicle de vida

lifecycle[] està ordenat cronològicament. Cada esdeveniment té type, timestamp, details i una tarifa (fee) facturable (quan correspongui): El payload de details depèn de la família d’esdeveniments:
  • Esdeveniments d’enviament (PHONE_VERIFICATION_MESSAGE_SENT, PHONE_VERIFICATION_RETRY_MESSAGE_SENT, PHONE_VERIFICATION_BLOCKED) — { status, reason, channel, actual_channel }. status és Success, Retry o Blocked; reason és null tret que l’enviament s’hagi bloquejat (invalid_phone_number, repeated_attempts, suspicious, spam, unknown); channel és el canal sol·licitat i actual_channel el canal que realment l’ha lliurat (per exemple, un enviament per WhatsApp que ha passat a SMS).
  • Esdeveniments de lliurament (PHONE_DELIVERY_DELIVERED, PHONE_DELIVERY_UNDELIVERABLE) — { channel, status } amb status delivered o undeliverable.
  • Esdeveniments de comprovació (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } amb status Approved, Declined, Failed o Expired or Not Found.
  • Esdeveniments d’estat final — null, excepte PHONE_VERIFICATION_DECLINED / PHONE_VERIFICATION_IN_REVIEW, que porten { "reason": "<risk code>" } (per exemple, PHONE_NUMBER_IN_BLOCKLIST).
El fee d’un esdeveniment d’enviament és el preu total d’aquest enviament: el preu de l’operador o de WhatsApp més la tarifa de $0.02 de Didit, o només la tarifa de $0.02 de Didit per a un codi de WhatsApp enviat des del teu propi número de WhatsApp Business. És el preu estimat fins que es confirma el lliurament, i després l’import realment facturat. Només els enviaments Blocked són garantits com a gratuïts: qualsevol altre enviament es cobra quan la verificació finalitza o caduca, fins i tot si el lliurament no s’ha confirmat mai o el missatge no s’ha pogut lliurar. Els esdeveniments de lliurament, comprovació i estat sempre porten fee: 0.

Coincidències entre sessions

matches[] registra altres sessions a la mateixa aplicació on s’ha vist el mateix número —entre verificacions de KYC, KYB i API independent, independentment del seu estat— a més de coincidències amb les llistes de bloqueig configurades a les llistes de l’API de gestió. Les sessions que comparteixen el vendor_data de la sessió actual s’exclouen (el mateix usuari final no es fa coincidir amb ell mateix), i la llista està limitada a un màxim de 5 entrades. Quan el número és a la teva llista de bloqueig però cap de les sessions coincidents està a la llista de bloqueig, s’afegeix al principi de la llista una entrada sintètica amb source: "list_entry" (amb tots els camps de la sessió a null).

Exemples

Aprovada — OTP de WhatsApp, operador mòbil

Rebutjada — número VoIP a la llista de bloqueig

L’usuari ha introduït un OTP vàlid, però la finalització ha detectat que el número es troba a la llista de bloqueig de l’aplicació (rebuig automàtic) i ha marcat el seu tipus de línia VoIP (voip_number_action s’ha mantingut a NO_ACTION, per la qual cosa es registra com a information). Com que cap sessió coincident està a la llista de bloqueig, la coincidència amb la llista de bloqueig apareix com una coincidència sintètica list_entry.

Relacionat

Darrera modificació el 7 de novembre del 2026