La actividad de autenticación y la entrega de webhooks asociada, que depende de la versión, se documentan en Eventos de autenticación y webhooks. No registres tipos de eventos de autenticación que no aparezcan en la lista en la API de destino actual.
Descripción general
Los webhooks son la forma en que Didit envía actualizaciones en tiempo real a tu backend cada vez que una sesión de verificación, una sesión de empresa, un usuario del proveedor, una empresa del proveedor o una transacción cambia de estado. Si suscribes uno o varios destinos a los eventos que te interesan, puedes reaccionar en cuanto un resultado está listo, normalmente a los pocos segundos de que el usuario que se verifica termine su flujo. Los webhooks son el patrón de integración recomendado. Consultar periódicamenteGET /v3/session/{id}/decision/ se admite como alternativa, pero es más lento, consume más solicitudes y no recibe eventos como data.updated, transaction.status.updated ni los cambios a nivel de entidad, que solo se emiten mediante webhooks. Considera la entrega de webhooks como la fuente de verdad y consulta solo en un arranque en frío o para conciliar datos.
Este capítulo de la lección de integración de Didit Academy comienza en la descripción general de los webhooks.
La lección de integración de Didit Academy trata los webhooks a partir del minuto 3:12: cómo añadir un destino, elegir eventos y el secreto de firma que verificarás más abajo.
Usuarios de Cloudflare o WAF. Didit entrega los webhooks desde la IP estática
18.203.201.92 con User-Agent: DiditWebhook/2.0 +https://didit.me. Si tu edge bloquea clientes desconocidos, permite esta IP en Security > WAF > Tools > IP Access Rules y elige Permitir para el hostname que recibe los webhooks.Tipos de eventos
Usa el valor exacto en el arraysubscribed_events de un destino. No hay comodín: incluye cada familia que quieras recibir. Puedes repartir los eventos entre varios destinos.
Los valores de esta tabla son el conjunto completo de eventos a los que puedes suscribirte: no existe
session.status.updated, kyc.completed ni nada similar. La única otra entrega que hace Didit es el callback kyb.registry_search.resolved sin firmar, que se envía al webhook_url que proporcionas con cada solicitud a POST /v3/kyb/search/, nunca a un destino.
Estructura del payload
Envoltorio
Todos los webhooks comparten el mismo envoltorio. Los campos se serializan siempre consort_keys=True y separadores compactos (, / :), de modo que el mismo payload produce la misma firma en ambos lados.
En los eventos de sesión (
status.updated, data.updated en sesiones normales y de empresa), el envoltorio incluye además:
Ejemplo de envoltorio de sesión
Arrays en plural de V3 (importante)
Dentro dedecision, cada resultado por función es un array plural, de modo que un mismo flujo puede incluir varias instancias de la misma función (por ejemplo, varias comprobaciones de identidad sobre distintos documentos):
node_id que coincide con el grafo del flujo, además de un status por función. No leas los campos singulares heredados de V2 (id_verification, nfc, liveness, face_match, phone, email, poa, aml, ip_analysis, database_validation); solo aparecen si un destino está fijado explícitamente a webhook_version: "v2".
Los resultados de Firma electrónica están en signatures[], que solo aparece cuando el flujo tiene un paso de Firma electrónica: un elemento por firmante, con el firmante, la confirmación del código, el certificado, la marca de tiempo, los hashes y las rutas de descarga de cada documento, y el PDF de evidencias. No existe un evento de firma independiente: status.updated te indica cuándo leerlos. Consulta el informe de Firma electrónica.
Los resultados de Verificación bancaria están en bank_verifications[], un elemento por cada paso de Verificación bancaria. El campo method de cada elemento indica cómo se verificó la cuenta: open_banking (inicio de sesión en el banco), account_lookup (comprobación de la cuenta), o una alternativa statement o microdeposits, y vale null hasta que se evalúa una cuenta. Cuando la persona eligió Continue without your bank, continued_without_bank es true y continuation indica el motivo. En ese caso method es none, salvo que antes se haya evaluado un intento: consulta Cuando la persona no puede verificar su banco. Una cuenta verificada mediante comprobación de la cuenta no lee datos financieros, por lo que financial_data.not_collected enumera los saldos, transacciones o ingresos que solicitaba el paso. Consulta Métodos de verificación bancaria.
Bloque del Investigator
Unadecision V3 de una sesión de usuario o de empresa también incluye investigator: la revisión más reciente del Investigator sobre la sesión, o null si nunca tuvo ninguna.
Las funciones de recopilación de documentos (Documentos KYB y Document AI) no tienen un array plural propio; aparecen en la lista
features[] de la decisión como { "feature": "DOCUMENT_AI", "node_id": "…" } (una entrada por nodo). Consulta Document AI.
Las decisiones de Verificación de usuarios también incluyen un único objeto biometric_consent: si la sesión exigió consentimiento biométrico explícito, el trigger, el status de la respuesta y su evidencia. status: "pending" con reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" significa que un SDK nativo anterior a la versión 4.10.0 capturó un rostro sin el paso de consentimiento. Consulta Consentimiento biométrico.
Claves del método de Verificación de identidad
Cada elemento deid_verifications[] indica qué método de Verificación de identidad lo generó, para que un handler pueda actuar según la evidencia que realmente obtuvo:
Los handlers existentes siguen funcionando sin cambios: una sesión con documento establece
verification_method en document y deja el resto en null. Los tipos campo por campo están en Modelos de datos.
Sesión con wallet aprobada (status.updated)
Payloads de eventos de entidades
ACTIVE, FLAGGED o BLOCKED. user.data.updated y business.data.updated mantienen el campo status y añaden un array changed_fields y un mapa changes de la forma { field: { previous, current } }. Los eventos business.* usan vendor_business_id en lugar de vendor_user_id.
Payloads de eventos de transacciones
Los webhooks de transacciones usan la misma infraestructura de fan-out y el mismo envoltorio, pero identifican la transacción en lugar de una sesión:action_required es null o la acción pendiente del usuario (type wallet_ownership o verification_session, con su url) descrita en Acciones requeridas del usuario.
Las transacciones nuevas tienen el estado APPROVED por defecto. Si una regla, la lista de bloqueo o un flujo cambia el estado durante la creación, el payload inicial de transaction.created refleja ese estado final. transaction.status.updated tiene la misma estructura con el status actualizado. Los estados de las transacciones son APPROVED, IN_REVIEW, DECLINED o AWAITING_USER; severity es UNKNOWN / LOW / MEDIUM / HIGH / CRITICAL y direction es INBOUND / OUTBOUND. transaction.created y transaction.status.updated solo se entregan para aplicaciones en producción. Los intercambios de Travel Rule en sandbox sí emiten travel_rule.status.updated con environment: sandbox.
Callback de búsqueda en el registro KYB
El flujo asíncrono dePOST /v3/kyb/search/ entrega un payload adicional que no es un evento de destino: cuando pasas un webhook_url en la solicitud de búsqueda, Didit envía por POST un callback kyb.registry_search.resolved a esa URL en cuanto el registro responde. Se diferencia de los webhooks de destino en tres aspectos:
- No está firmado: no lleva encabezados
X-Signature*. En su lugar, Didit lo marca conX-Didit-Unsigned-Callback: true; valídalo comprobando querequest_idcoincide con el ID devuelto por la solicitud de búsqueda. - El nombre del evento va en
event_type(no enwebhook_type) y no hayapplication_idnienvironment. timestampycreated_atson enteros de época, como en los demás webhooks, pero a diferencia delcreated_aten formato ISO del endpoint de búsqueda.
timestamp y siguen sin firmar). Consulta la API de registro KYB para ver el esquema completo de la lista de candidatos.
Verificación de firma
Cada webhook se firma con HMAC-SHA256 usando lasecret_shared_key del destino. Se envían tres encabezados de firma para que elijas el que funcione con tu stack:
Encabezados que Didit envía siempre:
Durante las 24 horas posteriores a la rotación del secreto de firma de un destino, las entregas también incluyen
X-Signature-Previous, X-Signature-V2-Previous y X-Signature-Simple-Previous (consulta Rotación del secreto de firma).
Rotación del secreto de firma
Puedes rotar el secreto de firma de un destino en la Business Console. Durante las 24 horas posteriores a una rotación, cada entrega a ese destino incluye tres encabezados más, generados con el secreto que se reemplazó:
Un handler que acepta una coincidencia tanto en un encabezado de firma como en su encabezado
-Previous sigue verificando mientras despliegas el nuevo secreto: el secreto antiguo coincide con el encabezado -Previous y el nuevo coincide con el encabezado normal.
Los ejemplos de código de más abajo lo hacen así.
Despliega el nuevo secreto dentro de esas 24 horas, porque después solo se podrá verificar con el nuevo secreto.
previous_secret_expires_at en GET /v3/webhook/destinations/{destination_uuid}/ te indica cuándo terminan las 24 horas.
Los reintentos y reenvíos se vuelven a firmar con el secreto actual del destino en el momento en que se envían, e incluyen los encabezados -Previous solo mientras duran las 24 horas.
Si vuelves a rotar dentro de las 24 horas, el secreto más antiguo se retira de inmediato: solo el secreto que estaba vigente hasta la nueva rotación sigue verificando a través de los encabezados -Previous, durante 24 horas desde la nueva rotación.
Los encabezados -Previous existen solo para los destinos de webhook.
La secret_shared_key a nivel de aplicación que firma el webhook_url heredado no tiene periodo de superposición: rotarla con rotate_secret_key en PATCH /v3/webhook/ invalida el secreto antiguo de inmediato.
X-Signature-Simple está obsoleto
Se trata de una restricción de compatibilidad, no de algo que podamos corregir sobre la marcha. La cadena canónica de cuatro campos es un contrato de protocolo: cada receptor que verifica X-Signature-Simple vuelve a calcular exactamente esos cuatro campos, así que cambiar lo que firma el encabezado haría que todos dejaran de funcionar silenciosamente al verificar firmas. Además, cubrir el cuerpo requiere una forma canónica especificada del JSON que ambas partes reproduzcan byte a byte, y Didit ya ofrece una como X-Signature-V2. En lugar de añadir una segunda variante que cubra el cuerpo con sus propias reglas de canonicalización, el encabezado se mantiene exactamente como está y queda obsoleto en favor de las variantes existentes que cubren el payload completo.
Qué significa esto para ti:
- No cambia nada en la transmisión.
X-Signature-Simplese sigue enviando en cada entrega, calculado de la misma manera. Los verificadores existentes siguen funcionando, y anunciaremos cualquier retirada con mucha antelación. - Las nuevas integraciones deben usar
X-Signature-V2. Es compatible con middleware y cubre todo el payload. - Si no puedes dejar de usar
X-Signature-Simple, verifícalo y después obtén el registro desde la API en lugar de leerlo del cuerpo del webhook.
Por qué tres variantes
Algunos frameworks web (parsers de cuerpo de Express, middleware de Django, API gateways) vuelven a codificar el JSON de forma silenciosa antes de que tu handler lo lea. Si el cuerpo original contenía"José" y tu middleware lo reescribe como "José", los bytes cambian aunque los datos sean idénticos. Entonces X-Signature falla. X-Signature-V2 se calcula a partir de una forma canónica del JSON (claves ordenadas, separadores compactos, Unicode sin escapar) que casi cualquier middleware reproduce de forma determinista, y el obsoleto X-Signature-Simple recurre a firmar solo una cadena corta e independiente del parser cuando incluso eso falla. Como firma solo esa cadena corta y nunca el cuerpo, no puede dar fe del cuerpo.
Orden de verificación recomendado
- Prueba primero con
X-Signature-V2. Vuelve a codificarJSON.parse(body)con las claves ordenadas y los caracteres Unicode sin escapar, calculaHMAC-SHA256(secret, canonical)y compáralo con el encabezado mediantetimingSafeEqual. - Si V2 falla y puedes leer los bytes sin procesar, prueba con
X-Signaturecomparándolo conHMAC-SHA256(secret, rawBody). - Solo si ambas fallan, recurre a la obsoleta
X-Signature-Simplecomparándola conHMAC-SHA256(secret, "{timestamp}:{session_id}:{status}:{webhook_type}"). Esta firma solo autentica el sobre: considera que ladecisiondel cuerpo no es de confianza y vuelve a obtenerla desdeGET /v3/session/{session_id}/decision/antes de actuar basándote en ella.
-Previous correspondiente, acepta la coincidencia con cualquiera de los dos encabezados (consulta Rotación del secreto de firma).
En todos los casos, rechaza cualquier solicitud con más de 5 minutos de antigüedad (abs(now - X-Timestamp) > 300) para protegerte frente a ataques de repetición.
Política de reintentos
Si tu endpoint responde con un5xx o un 404, Didit reintenta hasta 2 veces con espera exponencial:
- 1.er reintento: aproximadamente 1 minuto después del fallo inicial.
- 2.º reintento: unos 4 minutos después del 1.er reintento.
attempt: 1 para la primera entrega de un evento y, en cada reintento o reenvío, uno más que el del intento que repite.
Los reintentos automáticos se envían a la URL a la que se envió el primer intento, aunque hayas cambiado la url del destino desde entonces.
Un reenvío manual se envía a la URL actual del destino, así que al corregir una URL también se corrige el reenvío.
Otras reglas de entrega que debes conocer:
- El tiempo de espera de la solicitud HTTP saliente se agota después de 5 segundos.
- Didit bloquea las entregas a URL privadas o de localhost como protección frente a SSRF y nunca sigue redirecciones. Usa un endpoint HTTPS público que responda directamente.
- Una
urlde destino que contenga una barra invertida sin escapar, un carácter de control o más de un@en la autoridad se rechaza por estar mal formada: no se puede crear una URL así, y una existente no se puede volver a entregar ni reenviar. Usa una URLhttps://host/pathsimple con, como máximo, una sección de información de usuario (para URL de webhook con autenticación básica). - Un
2xxse considera un éxito. Los tiempos de espera agotados y los fallos de conexión se pueden reintentar (aparecen como504/503en el registro de entregas); las respuestas3xxy4xxdistintas de404no se reintentan. - Al reintentar, Didit vuelve a calcular las firmas con un
X-Timestampnuevo, de modo que la marca de tiempo y la firma siempre coinciden. - Los reintentos y reenvíos se firman con el secreto de firma vigente del destino en el momento en que se envían.
Orden de entrega
Didit no garantiza el orden en que te llegan los webhooks. Cada entrega se pone en cola por separado y un reintento llega minutos después del primer intento, por lo que unstatus.updated para Approved puede llegarte antes que uno anterior para In Progress.
Prepara tu receptor para ello:
- Trata un webhook como una señal de que algo ha cambiado. Cuando el orden importe, invoca
GET /v3/session/{session_id}/decision/y actúa según elstatusactual. - Nunca permitas que un evento más antiguo sobrescriba un estado más reciente: compara el
created_atdel evento con el último que guardaste para ese registro e ignora el más antiguo. - Identifica las repeticiones por
event_id, que no cambia entre reintentos.
Configurar un destino
Puedes gestionar los destinos desde Business Console > API & Webhooks o mediante la Management API.1
Crea el destino
Llama a
POST /v3/webhook/destinations/ (o haz clic en Add destination en la consola) con un label, una url pública, un webhook_version ("v3") y un array subscribed_events que contenga todas las familias de eventos que debe recibir este endpoint. Se requiere al menos un evento y no existe ningún comodín.2
Guarda el secret_shared_key
La respuesta de creación devuelve el
secret_shared_key del destino. Guárdalo junto con los demás secretos de tu servidor: pertenece solo a este destino y se usa como entrada para las tres variantes de firma HMAC-SHA256. GET /v3/webhook/destinations/{destination_uuid}/ lo devuelve de nuevo a quienes invocan la API con una clave de API y a los usuarios de la consola que pueden leer webhooks.3
Implementa el endpoint
Expón una ruta HTTPS
POST pública, lee el cuerpo sin procesar, verifica la firma (preferiblemente X-Signature-V2), comprueba la ventana de la marca de tiempo y, después, despacha según webhook_type. Devuelve un 2xx en cuanto hayas puesto el trabajo en cola: haz el procesamiento pesado de forma asíncrona.4
Confirma la recepción
Revisa la pestaña Deliveries del destino. Los webhooks que funcionan bien devuelven
200 en uno o dos segundos. Un 5xx/404 activa la política de reintentos de Didit; los fallos persistentes se descartan tras el segundo reintento.5
Itera con Try Webhook
Usa los escenarios de Try Webhook de la consola para hacer pasar tu endpoint por payloads aprobados, rechazados, en revisión, de KYB, de entidad, de actividad y de transacción antes de activar el tráfico de producción.

Envía webhooks de prueba directamente desde la Business Console para validar tu endpoint antes de pasar a producción.
Ejemplos de código
Para proteger tu endpoint de webhook, verifica la autenticidad de las solicitudes entrantes con lasecret_shared_key del destino.
Node.js / Express (recomendado: X-Signature-V2)
X-Signature funciona igual, pero firma el cuerpo sin procesar. La mantenemos en la sección heredada más abajo para que la documentación esté completa.
Python / FastAPI (recomendado: X-Signature-V2)
PHP / Laravel (recomendado: X-Signature-V2)
Los valores predeterminados de JSON en PHP no reproducen la forma canónica. Hay que sobrescribir cuatro de ellos, y basta con omitir uno solo para que cambien los bytes firmados y el digest nunca coincida:
La trampa del objeto vacío es la que más problemas causa. Los payloads de Didit suelen incluir mapas vacíos como
risk_view.countries.risk_scores, risk_view.crimes.risk_scores y risk_view.custom_list, así que una conversión de ida y vuelta con arrays asociativos rompe la firma en sesiones aprobadas normales, no en algún caso límite poco frecuente.
- Los floats con valor entero no necesitan ningún tratamiento especial en PHP. Didit los serializa como enteros (
100.0→100) yjson_encodede PHP escribe un float entero de la misma forma, así que no hace falta ningún pasoshortenFloats, a diferencia del ejemplo de Node.js anterior. - Mantén
serialize_precisionen-1(el valor predeterminado desde PHP 7.1). Si tu hosting lo cambia a17,json_encodeescribe87.42como87.420000000000002y todas las comprobaciones deX-Signature-V2fallan.
verifySignatureRaw, más arriba, es la alternativa más sencilla: $request->getContent() de Laravel devuelve los bytes intactos, así que X-Signature funciona siempre que nada delante de PHP recodifique el cuerpo. Ese es justo el caso que X-Signature-V2 está diseñado para resistir, y por eso V2 se prueba primero.
Pruebas
No necesitas ejecutar una verificación completa para probar tu endpoint.- Desde Business Console > API & Webhooks > Try Webhook, elige un escenario (por ejemplo,
approved_full_features,declined_face_mismatch,in_review_aml_hit,business_session_approved,transaction_created,activity_created,user_status_updated) y envía un webhook completamente formado a la URL de tu destino. - Cada escenario se firma con los mismos tres encabezados de firma y la misma codificación canónica que el tráfico de producción, incluidos datos de prueba con unicode (
approved_kyc_with_unicode), para que puedas confirmar queX-Signature-V2funciona a través de tu middleware. Las entregas de prueba contienen datos de ejemplo y se marcan con un encabezado adicionalX-Didit-Test-Webhook: true(y un sufijo(Test)en elUser-Agent), para que puedas evitar que afecten al estado de producción. - Si necesitas depurar una regresión, vuelve a enviar cualquier entrega anterior desde la pestaña Deliveries de un destino.
Ejemplos
Sesión KYC aprobada (status.updated)
Sesión rechazada con advertencias (status.updated)
Sesión de empresa aprobada (status.updated, KYB)
Transacción creada (transaction.created)
Cambio de estado de un intercambio de Travel Rule (travel_rule.status.updated)
travel_rule_status contiene uno de los 13 estados de intercambio documentados en Travel Rule.
rail es INTERNAL, TRP, GTR, TRUST, VERIFYVASP, SYGNA o EMAIL (cadena vacía hasta que se selecciona un rail, si no se pudo determinar ninguno, y siempre en los registros sunrise), o TEST_VASP para una transferencia en sandbox a la que respondió el Didit Test VASP, y direction es INBOUND u OUTBOUND.
Un evento de sandbox incluye "environment": "sandbox", y un evento TEST_VASP incluye además test_vasp: true y test_vasp_scenario (el escenario que respondió).
Cuando Didit crea una transacción para una transferencia de Travel Rule (una llamada a POST /v3/transactions/, un registro sunrise posterior al depósito, una consulta TRP entrante o el tramo entrante del rail INTERNAL), envía primero el evento transaction.created de esa transacción y después los eventos travel_rule.status.updated de la transferencia.
Una regla que cambie el estado de la transacción durante ese paso también puede enviar transaction.status.updated antes de transaction.created, y un registro sunrise que se asocia a una transacción de depósito que ya creaste no envía transaction.created.
Cada webhook se entrega y se reintenta por separado, así que un evento reintentado puede llegar después de uno posterior: usa transaction_id como clave en tu handler y vuelve a consultar la transacción cuando necesites su estado actual.
Una transferencia enviada por TRUST nunca recibe un evento COMPLETED, porque TRUST no devuelve nada que Didit pueda leer: permanece en AWAITING_COUNTERPARTY hasta la fecha límite de confirmación y luego termina en EXPIRED. En GTR, VerifyVASP y Sygna Bridge, Didit lee la respuesta de la contraparte desde la red y el evento la refleja (consulta Redes de Travel Rule).
Cambio de cumplimiento del flujo (workflow.compliance_changed)
transition.from y transition.to son uno de compliant, gaps_detected, pending_change, unknown_coverage o not_evaluated.
severity es actionable cuando se detectaron carencias, indicative para un cambio pendiente e informative cuando se subsanaron las carencias.
Didit envía un evento por cada flujo que cambió.
Sugerencias de reglas de transacciones creadas (transaction_rule_suggestions.created)
kind es ADD para una regla nueva, TWEAK para un cambio en una regla existente y DISABLE para desactivar una. rule_id es null para ADD.
open_count es el número de sugerencias que siguen abiertas después de la ejecución, incluidas las nuevas.
La configuración de sugerencias de reglas activa o desactiva este webhook; consulta Webhooks de transacciones.
Eventos de Investigator (investigator.*)
Los doce eventos investigator.* usan el mismo envoltorio (event_id, webhook_type, timestamp, created_at, application_id, environment) y los mismos encabezados de firma que cualquier otro evento. Solo contienen identificadores y cifras: nunca un nombre, un motivo escrito por un revisor, una narrativa ni nada que haya escrito el usuario final. No tienen session_id; el elemento al que se refieren se indica en item.
provenance indica qué versión de Investigator redactó el informe:
enginees la versión del motor de Investigator: un identificador opaco de ocho caracteres. Cambia cada vez que cambia el motor, así que dos informes con el mismoenginelos redactó el mismo motor.agent_versiones la versión del agente.policy_versiones la versión de tu propia política que siguió el informe.model_ides un alias obsoleto que contiene el mismo valor queengine. Usaengineen su lugar.prompt_hashya no se envía.
item.kind indica el tipo de elemento (una sesión, una sesión de empresa, una transacción o un caso) e item.id, su identificador. Las marcas de tiempo que terminan en _at son cadenas ISO 8601. Para suscribirte a estos eventos, indica las cadenas exactas en subscribed_events, como con cualquier otro evento.
Cambio de estado de la entidad de usuario (user.status.updated)
Sesión reenviada
Legado: X-Signature con el cuerpo sin procesar
X-Signature se sigue enviando en cada entrega; es un HMAC-SHA256 calculado sobre los bytes exactos que transmite Didit (json.dumps(..., sort_keys=True, separators=(",", ":"))). Úsalo solo cuando puedas leer el cuerpo sin procesar antes de que cualquier middleware lo modifique.
- Node.js
- Python
Legado: formato de webhook V2
Los objetos de cada función son los mismos en ambas versiones: un destino V2 recibe exactamente los mismos
match_score, risk_score, score_breakdown, risk_view y review_status por coincidencia y el mismo score agregado que V3 (consulta el informe AML). Fijar un destino a V2 cambia dónde se ubica el informe AML dentro de decision, no lo que contiene.
Si un consumidor posterior todavía necesita las estructuras de V2, crea un destino independiente fijado a webhook_version: "v2" y mantén tus nuevos consumidores en V3.
Relacionado
- API de destinos de webhook: lista, crea, actualiza y elimina destinos, e inspecciona los registros de entrega.
- Crear destino de webhook: esquema de solicitud y respuesta, incluido el
secret_shared_keydel destino. - Modelos de datos: esquema canónico de cada objeto específico de cada función incluido en
decision. - Esquema de decisión: lista completa de campos del objeto
decisionincluido en los webhooks de sesión. - Estados de verificación: valores exactos de
statusy transiciones mencionados más arriba. - Límites de solicitudes: límites que se aplican al consultar periódicamente
GET /v3/session/{id}/decision/como alternativa.