El lliurament de webhooks, que depèn de la versió, es documenta a Esdeveniments d’autenticació i webhooks. Activitat d’autenticació: no registris tipus d’esdeveniment d’autenticació que no hi siguin inclosos amb l’API de destinacions actual.
Visió general
Els webhooks són la manera com Didit envia actualitzacions en temps real al teu backend cada cop que canvia l’estat d’una sessió de verificació, d’una sessió d’empresa, d’un usuari del proveïdor, d’una empresa del proveïdor o d’una transacció. Si subscrius una o diverses destinacions als esdeveniments que t’interessen, pots reaccionar en el moment en què el resultat està a punt, normalment en pocs segons després que l’usuari que fa la verificació acabi el seu flux. Els webhooks són el patró d’integració recomanat. El sondeig deGET /v3/session/{id}/decision/ està disponible com a alternativa, però és més lent, fa més peticions i no rep esdeveniments com data.updated, transaction.status.updated ni els canvis a nivell d’entitat, que només s’emeten amb webhooks. Considera el lliurament de webhooks com la font de veritat i només fes sondejos en arrencar en fred o per a la conciliació.
Aquest capítol de la lliçó d’integració de Didit Academy comença a la visió general dels webhooks.
La lliçó d’integració d’Academy tracta els webhooks a partir de 3:12: com afegir una destinació, com triar els esdeveniments i el secret de signatura que verificaràs més avall.
Usuaris de Cloudflare / WAF. Didit lliura els webhooks des de la IP estàtica
18.203.201.92 amb User-Agent: DiditWebhook/2.0 +https://didit.me. Si la teva capa perimetral bloqueja clients desconeguts, permet aquesta IP a Security > WAF > Tools > IP Access Rules i tria Permetre per al nom d’amfitrió receptor.Tipus d’esdeveniments
Utilitza el valor exacte en la matriusubscribed_events d’una destinació. No hi ha comodí: enumera cada família que vols rebre, i pots repartir els esdeveniments entre diverses destinacions.
Els valors d’aquesta taula són el conjunt complet d’esdeveniments subscriptibles: no hi ha
session.status.updated, kyc.completed ni cap altre de similar. L’única altra entrega que fa Didit és el callback kyb.registry_search.resolved sense signatura, que s’envia a la webhook_url específica de cada sol·licitud que passes a POST /v3/kyb/search/, i mai a una destinació del webhook.
Forma del payload
Embolcall
Tots els webhooks comparteixen el mateix embolcall. Els camps es serialitzen sempre ambsort_keys=True i separadors compactes (, / :), perquè el mateix payload reprodueixi la mateixa signatura en tots dos extrems.
Per als esdeveniments de sessió (
status.updated, data.updated a les sessions normals i empresarials), l’embolcall inclou a més:
Exemple d’embolcall de sessió
Matrius plurals de V3 (important)
Dins dedecision, cada resultat per funcionalitat és una matriu amb diversos elements, perquè un mateix flux de treball pugui incloure diverses instàncies de la mateixa funcionalitat (per exemple, diverses comprovacions d’identitat en diversos documents):
node_id que coincideix amb el graf del flux de treball, i un status per funcionalitat. No llegeixis els camps singulars heretats de V2 (id_verification, nfc, liveness, face_match, phone, email, poa, aml, ip_analysis, database_validation); només apareixen si una destinació està fixada explícitament a webhook_version: "v2".
Els resultats de la Signatura electrònica són a signatures[], només presents quan el flux de treball té un pas de Signatura electrònica: un element per signatari, amb el signatari, la confirmació del codi, el certificat, la marca de temps, els hashes i les rutes de descàrrega de cada document, i el PDF de l’evidència. No hi ha un esdeveniment de signatura independent: status.updated indica quan cal llegir-los. Consulta l’informe de signatura electrònica.
Els resultats de la Verificació bancària són a bank_verifications[], un element per cada pas de Verificació bancària. El method de cada element indica com s’ha verificat el compte: open_banking (inici de sessió al banc), account_lookup (comprovació del compte), o bé una alternativa statement o microdeposits, i és null fins que no s’avalua un compte. Quan la persona ha triat Continua sense el teu banc, continued_without_bank és true i continuation indica el motiu. En aquest cas, method és none, tret que abans s’hagi avaluat un intent: consulta Quan la persona no pot verificar el seu banc. Un compte verificat per comprovació del compte no llegeix dades financeres, de manera que financial_data.not_collected enumera els saldos, les transaccions o els ingressos que el pas demanava. Consulta Mètodes de verificació bancària.
Bloc de l’Investigator
Undecision V3 per a una sessió d’usuari o d’empresa també inclou investigator: l’última revisió d’Investigator de la sessió, o null si mai no n’ha tingut cap.
Les funcionalitats de recollida de documents, Documents KYB i Document AI, no tenen cap matriu específica per a múltiples elements. Apareixen a la llista
features[] de la decisió com a { "feature": "DOCUMENT_AI", "node_id": "…" } (una entrada per node). Consulta Document AI.
Les decisions de User Verification també inclouen un únic objecte biometric_consent: si la sessió requeria consentiment biomètric explícit, el trigger, el status de la resposta i la seva evidència. status: "pending" amb reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" vol dir que un SDK natiu anterior a la 4.10.0 ha capturat un rostre sense el pas de consentiment. Consulta Consentiment biomètric.
Claus del mètode de verificació d’identitat
Cada element deid_verifications[] indica quin mètode de verificació d’identitat l’ha produït, perquè un gestor pugui bifurcar segons l’evidència que realment ha rebut:
Els gestors existents continuen funcionant sense canvis: una sessió de document defineix
verification_method com a document i deixa la resta a null. Els tipus de cada camp es troben a Models de dades.
Sessió de cartera aprovada (status.updated)
Payloads d’esdeveniments d’entitat
ACTIVE, FLAGGED o BLOCKED. user.data.updated i business.data.updated conserven el camp status i afegeixen una matriu changed_fields i un mapa changes de { field: { previous, current } }. Els esdeveniments business.* usen vendor_business_id en lloc de vendor_user_id.
Payloads d’esdeveniments de transacció
Els webhooks de transacció utilitzen la mateixa infraestructura de distribució i el mateix embolcall, però identifiquen la transacció en lloc d’una sessió:action_required és null, o l’acció pendent de l’usuari (type wallet_ownership o verification_session, amb la seva url) descrita a Accions requerides de l’usuari.
Les transaccions noves tenen APPROVED per defecte. Si una regla, una llista de bloqueig o un flux de treball canvia l’estat durant la creació, el payload inicial de transaction.created reflecteix aquest estat final. transaction.status.updated té la mateixa forma amb el status actualitzat. Els estats de transacció són APPROVED, IN_REVIEW, DECLINED o AWAITING_USER; severity és UNKNOWN / LOW / MEDIUM / HIGH / CRITICAL i direction és INBOUND / OUTBOUND. transaction.created i transaction.status.updated només es lliuren per a aplicacions en producció. Els intercanvis de Travel Rule del sandbox sí que emeten travel_rule.status.updated amb environment: sandbox.
Callback de la cerca de registre KYB
El flux asíncron dePOST /v3/kyb/search/ envia un payload extra que no és un esdeveniment de destinació: quan passes un webhook_url a la sol·licitud de cerca, Didit fa un POST d’un callback kyb.registry_search.resolved a aquesta URL quan el registre resol la consulta. Es diferencia dels webhooks de destinació en tres aspectes:
- És sense signar: no té capçaleres
X-Signature*. Didit l’indica ambX-Didit-Unsigned-Callback: true; valida-la fent coincidirrequest_idamb l’id que ha retornat la sol·licitud de cerca. - El nom de l’esdeveniment és a
event_type(no awebhook_type), i no hi haapplication_idnienvironment. timestampicreated_atsón enters d’epoch, com altres webhooks, però a diferència delcreated_atISO de l’endpoint de cerca.
timestamp i continuen sense signar). Consulta la API de registre KYB per a l’esquema complet de la llista de candidats.
Verificació de la signatura
Cada webhook es signa amb HMAC-SHA256 fent servir elsecret_shared_key de la destinació. S’envien tres capçaleres de signatura perquè puguis escollir la que funcioni amb el teu stack:
Capçaleres que Didit sempre envia:
Durant 24 hores després que es rotí el secret de signatura d’una destinació, els lliuraments també porten
X-Signature-Previous, X-Signature-V2-Previous i X-Signature-Simple-Previous (consulta Rotació del secret de signatura).
Rotació del secret de signatura
Pots rotar el secret de signatura d’una destinació a la Business Console. Durant 24 hores després d’una rotació, cada lliurament a aquesta destinació porta tres capçaleres més, fetes amb el secret que s’ha substituït:
Un gestor que accepti una coincidència amb una capçalera de signatura o amb la seva capçalera
-Previous seguirà verificant mentre desplegues el nou secret: el secret antic coincideix amb la capçalera -Previous, i el nou amb la capçalera habitual.
Els exemples de codi de més avall ho fan.
Desplega el nou secret dins de les 24 hores, perquè després només es pugui verificar amb el nou secret.
previous_secret_expires_at a GET /v3/webhook/destinations/{destination_uuid}/ t’indica quan acaben les 24 hores.
Els reintents i els reenviaments es tornen a signar amb el secret actual de la destinació quan s’envien, i només porten les capçaleres -Previous mentre duren les 24 hores.
Si tornes a rotar dins de les 24 hores, el secret més antic es retira de seguida: només el secret que era vigent fins a la nova rotació continua verificant a través de les capçaleres -Previous, durant 24 hores des de la nova rotació.
Les capçaleres -Previous només existeixen per a les destinacions de webhook.
El secret_shared_key a nivell d’aplicació que signa el webhook_url heretat no es solapa: rotar-lo amb rotate_secret_key a PATCH /v3/webhook/ invalida el secret antic de seguida.
X-Signature-Simple està obsoleta
Això és una restricció de compatibilitat, no quelcom que puguem corregir en calent. La cadena canònica de quatre camps és un contracte de format de transmissió: cada receptor que verifica X-Signature-Simple recalcula exactament aquests quatre camps, així que canviar el que signa la capçalera trencaria en silenci tots aquests receptors a la ruta de verificació de la signatura. Cobrir el cos també exigeix una forma canònica del JSON especificada que els dos costats reprodueixin byte a byte, i Didit ja n’ofereix una com a X-Signature-V2. En lloc d’afegir una segona variant que cobreixi el cos amb les seves pròpies regles de canonicalització, la capçalera es manté exactament igual i queda obsoleta a favor de les variants existents que signen tot el payload.
Què significa això per a tu:
- Res no canvia en el canal de transmissió.
X-Signature-Simplecontinua enviant-se a cada lliurament, calculada de la mateixa manera. Els verificadors existents continuen funcionant, i anunciarem amb molta antelació qualsevol eliminació. - Les integracions noves han d’usar
X-Signature-V2. És segura per al middleware i cobreix tot el payload. - Si no pots deixar
X-Signature-Simple, verifica-la i després obtén el registre des de l’API en lloc de llegir-lo del cos del webhook.
Per què tres variants?
Alguns frameworks web (els analitzadors de cos d’Express, el middleware de Django, les passarel·les d’API) recodifiquen en silenci el JSON abans que el teu gestor el llegeixi. Si el cos original contenia"José" i el teu middleware el reescriu com a "José", els bytes canvien encara que les dades siguin idèntiques. Aleshores X-Signature falla. X-Signature-V2 es calcula a partir d’una forma canònica del JSON (claus ordenades, separadors compactes, Unicode sense escapar) que gairebé qualsevol middleware reprodueix de manera determinista. La signatura X-Signature-Simple obsoleta, en canvi, recorre a la signatura de només una cadena curta i independent de l’analitzador quan fins i tot això falla. Com que signa només aquesta cadena curta i mai el cos, no pot garantir el cos.
Ordre de verificació recomanat
- Prova primer
X-Signature-V2. Torna a codificarJSON.parse(body)amb les claus ordenades i Unicode preservat, desprésHMAC-SHA256(secret, canonical)itimingSafeEqualcontra la capçalera. - Si V2 falla i pots llegir els bytes en brut, prova
X-SignaturecontraHMAC-SHA256(secret, rawBody). - Només si fallen els dos, recorre a
X-Signature-Simple, obsoleta, contraHMAC-SHA256(secret, "{timestamp}:{session_id}:{status}:{webhook_type}"). Això només autentica el sobre: considera eldecisiondel cos com a no fiable i torna’l a obtenir des deGET /v3/session/{session_id}/decision/abans d’actuar-hi.
-Previous corresponent, accepta una coincidència amb qualsevol de les dues capçaleres (consulta Rotació del secret de signatura).
En tots els casos, rebutja qualsevol sol·licitud amb una diferència respecte de l’hora actual superior a 5 minuts (abs(now - X-Timestamp) > 300) per protegir-te d’atacs de repetició.
Política de reintents
Si el teu endpoint respon amb un5xx o un 404, Didit reintenta fins a 2 vegades amb una espera exponencial:
- 1r reintent: aproximadament 1 minut després de la fallada inicial.
- 2n reintent: aproximadament 4 minuts després del 1r reintent.
attempt: 1 per al primer lliurament d’un esdeveniment, i un número més que el de l’intent que repeteix, per a cada reintent o reenviament.
Els reintents automàtics s’envien a la URL on es va enviar el primer intent, encara que hagis canviat després el url de la destinació.
Un reenviament manual s’envia a la URL actual de la destinació, de manera que corregir una URL també corregeix el reenviament.
Altres regles de lliurament que has de conèixer:
- La sol·licitud HTTP de sortida té un temps d’espera de 5 segons.
- Didit bloqueja els lliuraments a URL privades o a localhost com a mesura de protecció contra SSRF, i mai no segueix redireccions. Utilitza un endpoint HTTPS públic que respongui directament.
- Una
urlde destinació que contingui una barra invertida literal, un caràcter de control o més d’una@a l’autoritat es rebutja com a malformada: aquesta URL no es pot crear i una d’existent no es pot tornar a lliurar ni repetir. Utilitza una URLhttps://host/pathsimple, amb com a màxim una secció d’informació d’usuari (per a URL de webhook a l’estil de l’autenticació bàsica). 2xxes considera èxit. Els temps d’espera i els errors de connexió es consideren reintentables (apareixen com a504/503al registre de lliuraments); les respostes3xxi4xx, excepte404, no es reintenten.- En cada reintent, Didit recalcula les signatures amb un
X-Timestampnou, de manera que el parell de marca de temps i signatura sempre coincideix. - Els reintents i els reenviaments es signen amb el secret de signatura actual de la destinació en el moment d’enviar-los.
Ordre de lliurament
Didit no garanteix l’ordre en què et arriben els webhooks. Cada lliurament es posa en cua per separat i un reintent arriba minuts després de l’intent inicial, de manera que unstatus.updated per a Approved pot arribar-te abans que un anterior per a In Progress.
Crea el receptor tenint això en compte:
- Considera un webhook com un senyal que alguna cosa ha canviat. Quan l’ordre importa, crida
GET /v3/session/{session_id}/decision/i actua segons elstatusactual. - No permetis mai que un esdeveniment més antic sobreescrigui un estat més nou: compara el
created_atde l’esdeveniment amb l’últim que hagis desat per a aquest registre i ignora’l si és més antic. - Detecta les repeticions per
event_id, que es manté igual entre reintents.
Configurar una destinació
Pots gestionar les destinacions des de la Business Console > API & Webhooks o mitjançant l’API de gestió.1
Crea la destinació
Crida
POST /v3/webhook/destinations/ (o fes clic a Afegir destinació a la consola) amb un label, una url pública, un webhook_version ("v3") i un array subscribed_events que contingui totes les famílies d’esdeveniments que aquest endpoint ha de rebre. Cal com a mínim un esdeveniment i no existeix cap comodí.2
Desa el secret_shared_key
La resposta de creació retorna el
secret_shared_key de la destinació. Desa’l amb els altres secrets del teu servidor: pertany només a aquesta destinació i és l’entrada de les tres variants de signatura HMAC-SHA256. GET /v3/webhook/destinations/{destination_uuid}/ el torna a retornar als clients amb clau d’API i als usuaris de la consola que poden llegir els webhooks.3
Implementa l'endpoint
Exposa una ruta
POST HTTPS pública, llegeix el cos en brut, verifica la signatura (preferint X-Signature-V2), comprova la finestra de la marca de temps i després distribueix segons el webhook_type. Retorna 2xx tan bon punt hagis posat el treball en cua: fes el processament pesat de manera asíncrona.4
Confirma les recepcions
Vigila la pestanya Lliuraments de la destinació. Els webhooks que funcionen correctament retornen
200 en un segon o dos. Un 5xx o 404 activa la política de reintents de Didit; les fallades persistents es descarten després del segon reintent.5
Itera amb Try Webhook
Fes servir els escenaris de Try Webhook de la consola per enviar al teu endpoint payloads d’aprovació, rebuig, revisió, KYB, entitat, activitat i transacció abans d’activar el trànsit de producció.

Envia webhooks de prova directament des de la Business Console per validar el teu endpoint abans de posar-lo en producció.
Mostres de codi
Per garantir la seguretat del teu endpoint de webhook, verifica l’autenticitat de les sol·licituds entrants amb elsecret_shared_key de la destinació.
Node.js / Express (recomanat: X-Signature-V2)
X-Signature funciona de la mateixa manera, però signa el cos en brut. La mantenim a la secció heretada següent per completesa.
Python / FastAPI (recomanat: X-Signature-V2)
PHP / Laravel (recomanat: X-Signature-V2)
Els valors per defecte del JSON de PHP no reprodueixen la forma canònica. Cal sobreescriure’n quatre, i si en falta només un, canvien els bytes signats i el resum mai no coincideix:
La trampa dels objectes buits és la que fa més mal. Els payloads de Didit porten sovint mapes buits, com
risk_view.countries.risk_scores, risk_view.crimes.risk_scores i risk_view.custom_list, de manera que una conversió associativa d’anada i tornada trenca la signatura en sessions aprovades habituals, en lloc de fer-ho només en algun cas excepcional i poc freqüent.
- Els nombres en coma flotant amb valor enter no necessiten cap tractament especial en PHP. Didit els serialitza com a enters (
100.0→100), i eljson_encodede PHP escriu un float amb valor enter de la mateixa manera, així que no cal cap passhortenFloats, a diferència de la mostra de Node.js de dalt. - Mantén
serialize_precisionen-1(el valor per defecte des de PHP 7.1). Si el teu servidor el sobreescriu amb17,json_encodeescriu87.42com87.420000000000002i totes les comprovacions deX-Signature-V2fallen.
verifySignatureRaw de dalt és l’alternativa més simple: el $request->getContent() de Laravel retorna els bytes sense tocar, de manera que X-Signature funciona sempre que res davant de PHP recodifiqui el cos. Precisament aquest és el cas per al qual està dissenyat X-Signature-V2, i per això es prova primer V2.
Proves
No cal que executis una verificació completa per provar el teu endpoint.- Des de Business Console > API & Webhooks > Try Webhook, tria un escenari (p. ex.
approved_full_features,declined_face_mismatch,in_review_aml_hit,business_session_approved,transaction_created,activity_created,user_status_updated) i envia un webhook amb el format complet a la URL de la teva destinació. - Cada escenari es signa amb les mateixes tres capçaleres de signatura i la mateixa codificació canònica que el trànsit de producció, incloses les dades de prova amb unicode (
approved_kyc_with_unicode), perquè puguis confirmar queX-Signature-V2funciona a través del teu middleware. Els lliuraments de prova porten dades d’exemple i es marquen amb una capçalera addicionalX-Didit-Test-Webhook: true(i amb un sufix(Test)alUser-Agent), perquè no afectin l’estat de producció. - Torna a reproduir qualsevol lliurament històric des de la pestanya Lliuraments d’una destinació si necessites depurar una regressió.
Exemples
Sessió KYC aprovada (status.updated)
Sessió rebutjada amb advertències (status.updated)
Sessió empresarial aprovada (status.updated, KYB)
Transacció creada (transaction.created)
Canvi d’estat d’un intercanvi de Travel Rule (travel_rule.status.updated)
travel_rule_status conté un dels 13 estats d’intercanvi documentats a Travel Rule.
rail és INTERNAL, TRP, GTR, TRUST, VERIFYVASP, SYGNA o EMAIL (cadena buida fins que se selecciona una via, si no se n’ha pogut determinar cap, i sempre en els registres sunrise), o TEST_VASP per a una transferència de sandbox que ha respost el Didit Test VASP, i direction és INBOUND o OUTBOUND.
Un esdeveniment de sandbox porta "environment": "sandbox", i un esdeveniment TEST_VASP porta també test_vasp: true i test_vasp_scenario (l’escenari que ha respost).
Quan Didit crea una transacció per a una transferència de Travel Rule (una crida POST /v3/transactions/, un registre sunrise posterior al dipòsit, una consulta TRP entrant o la part entrant de la via INTERNAL), envia primer l’esdeveniment transaction.created d’aquesta transacció i després els esdeveniments travel_rule.status.updated de la transferència.
Una regla que canvia l’estat de la transacció durant aquest pas també pot enviar transaction.status.updated abans de transaction.created, i un registre sunrise que s’adjunta a una transacció de dipòsit que ja has creat no envia cap transaction.created.
Cada webhook s’envia i es reintenta de manera independent, de manera que un esdeveniment reintentat pot arribar després d’un de posterior: fes que el teu gestor depengui de transaction_id i torna a llegir la transacció quan necessitis el seu estat actual.
Una transferència enviada per TRUST no rep mai un esdeveniment COMPLETED, perquè TRUST no envia res que Didit pugui llegir: es manté a AWAITING_COUNTERPARTY fins al termini de confirmació i després passa a EXPIRED. A GTR, VerifyVASP i Sygna Bridge, Didit llegeix la resposta de la contrapart des de la xarxa i l’esdeveniment la segueix (consulta xarxes de Travel Rule).
Canvi de compliment del flux de treball (workflow.compliance_changed)
transition.from i transition.to són cadascun un dels valors següents: compliant, gaps_detected, pending_change, unknown_coverage o not_evaluated.
severity és actionable quan s’han detectat llacunes, indicative per a un canvi pendent i informative quan s’han resolt llacunes.
Didit envia un esdeveniment per cada flux de treball que ha canviat.
Suggeriments de regla de transacció creats (transaction_rule_suggestions.created)
kind és ADD per a una regla nova, TWEAK per a un canvi en una regla existent i DISABLE per desactivar-ne una. rule_id és null per a ADD.
open_count és el nombre de suggeriments encara oberts després de l’execució, incloent-hi els nous.
La configuració dels suggeriments de regla activa o desactiva aquest webhook; consulta Webhooks de transaccions.
Esdeveniments d’Investigator (investigator.*)
Els dotze esdeveniments investigator.* fan servir la mateixa estructura (event_id, webhook_type, timestamp, created_at, application_id, environment) i les mateixes capçaleres de signatura que qualsevol altre esdeveniment. Només porten identificadors i xifres: mai un nom, un motiu que hagi escrit un revisor, una narrativa ni res que hagi escrit l’usuari final. No tenen session_id; l’element al qual fan referència s’indica a item.
provenance indica quina versió de l’Investigator ha escrit l’informe:
engineés la versió del motor de l’Investigator: un identificador opac de vuit caràcters. Canvia cada vegada que canvia el motor, de manera que dos informes amb el mateixengineels ha escrit el mateix motor.agent_versionés la versió de l’agent.policy_versionés la versió de la teva pròpia política que ha seguit l’informe.model_idés un àlies obsolet que porta el mateix valor queengine. Llegeixengineen lloc seu.prompt_hashja no s’envia.
item.kind indica el tipus d’element (una sessió, una sessió empresarial, una transacció o un cas) i item.id el seu identificador. Les marques de temps que acaben en _at són cadenes ISO 8601. Subscriu-te a aquests esdeveniments indicant les cadenes exactes a subscribed_events, igual que qualsevol altre esdeveniment.
Canvi d’estat de l’entitat d’usuari (user.status.updated)
Sessió reenviada
Obsolet: X-Signature amb el cos en brut
Encara s’enviaX-Signature en cada lliurament. És un HMAC-SHA256 sobre els bytes exactes que transmet Didit (json.dumps(..., sort_keys=True, separators=(",", ":"))). Utilitza-la només quan puguis llegir el cos en brut abans que cap middleware el modifiqui.
- Node.js
- Python
Obsolet: format de webhook V2
Els objectes per funcionalitat són els mateixos en les dues versions: una destinació V2 rep exactament el
match_score, risk_score, score_breakdown, risk_view i review_status per cada coincidència, i el score agregat que rep V3 (vegeu Informe AML). Fixar la destinació a V2 canvia on es troba l’informe AML dins de decision, però no el que conté.
Si un consumidor final encara necessita les formes V2, crea una destinació separada fixada a webhook_version: "v2" i mantén els nous consumidors a V3.
Relacionats
- API de destinacions de webhook: llista, crea, actualitza i elimina destinacions, i consulta els registres de lliurament.
- Crea una destinació del webhook: esquema de la petició i la resposta, inclòs el
secret_shared_keyde la destinació. - Models de dades: esquema canònic de cada objecte per funcionalitat inclòs a
decision. - Esquema de la decisió: llista completa de camps de l’objecte
decisioninclòs als webhooks de sessió. - Estats de verificació: valors exactes de
statusi les transicions esmentades més amunt. - Límits de freqüència: límits que s’apliquen quan es consulta
GET /v3/session/{id}/decision/com a alternativa.