> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # API para crear transacciones: envío a KYT > Envía una transacción a Didit KYT para puntuación de riesgo, screening y Travel Rule. 1,000 transacciones al mes incluidas, luego $0.001 cada una. Prompt para la API de creación de transacciones Copiar el prompt al portapapeles \

\`Submit a transaction for Didit monitoring through the Management API.

Endpoint:
POST https://verification.didit.me/v3/transactions/

Authentication:
Use the x-api-key header with my Didit API key.

Goal:
\- Submit a transaction for KYT (transaction monitoring). Didit runs the configured rules engine, blockchain analytics, and AML screening synchronously and returns the verdict in the response. The full detail (parties, rule runs, provider results, remediation links) is also returned.
\- A Travel Rule transfer is stored in the same call, but Didit contacts the counterparty after the response: travel_rule.status comes back AWAITING_COUNTERPARTY (or NOT_APPLICABLE, UNCONFIRMED_OWNERSHIP, or COMPLETED for your own verified wallet) with travel_rule.protocol null, and every later status change, including COUNTERPARTY_VASP_NOT_FOUND, arrives as a travel_rule.status.updated webhook. Your rules run again when the rail or the status changes.

When to call:
\- At payment authorization, before fanning out funds, to decide allow / hold / decline based on status, score, severity.
\- On post-trade events (gambling bets, audit-trail events, KYC events) for long-running monitoring without a per-transaction decision.
\- On crypto deposits / withdrawals — set transaction_details.currency_kind = "crypto" and provide the relevant wallet address in payment_method.account_id.
\- For Travel Rule, set transaction_category = "travel_rule" and include travel_rule_details (alias travelRule).
travel_rule_details.status is required (400 if missing); when Travel Rule is enabled, Didit runs the exchange and ignores the status you send, and otherwise Didit records the transfer passively with that status.
When the subject is a user with an approved Didit KYC verification and Travel Rule is on, Didit replaces the originator_data fields the verification holds with the verified values (metadata.originator_provenance says which); otherwise it sends originator_data as you provide it, so build it from the identity you verified.
beneficiary_data carries the beneficiary (name, wallet_address, chain) and any routing hints (travel_address, counterparty_vasp_lei, counterparty_vasp_name, counterparty_vasp_email).
If beneficiary_data.chain is empty, Didit takes transaction_details.crypto_params.crypto_chain, else custom_properties.crypto_chain, else the currency, uppercases it, and sets it only when it is a chain Didit recognises (for example ETH or BTC).
\- Chain shapes: on XRP, XLM, EOS, ATOM and HBAR send the destination tag or memo as payment_method.memo (or beneficiary_data.memo); on BTC, LTC, BCH and DOGE send the transaction's inputs and outputs as travel_rule_details.utxo; on bitcoin or Lightning, payment_method.account_id may be a Lightning payment request or Lightning Address. What Didit resolved is on travel_rule.chain_details (see /transaction-monitoring/travel-rule#chain-shapes).

Identifiers:
\- transaction_id (alias txnId) is YOUR identifier (max 128 chars), unique per application.
It becomes txn_id on subsequent calls.
Reusing a transaction_id that already exists returns 400 {"transaction_id": ["A transaction with this transaction_id already exists."]}, and when two identical requests race each other the loser gets 409.
Neither response returns the existing transaction, so to retry safely, treat a 400 or 409 for a duplicate id as already created and look the transaction up instead of resubmitting: GET /v3/transactions/{uuid}/ with the Didit uuid from the first response, or with the transaction_id (the Didit uuid) that the transaction.created webhook carries next to your txn_id.
GET does not accept your txn_id. Sandbox applications do not receive transaction.created or transaction.status.updated, so save the Didit uuid from the create response. Sandbox Travel Rule exchanges do emit travel_rule.status.updated with environment: sandbox.
\- The returned uuid is Didit's stable identifier — use it in GET /v3/transactions/{transaction_id}/.

Linking to entities:
\- subject.vendor_data (and optionally counterparty.vendor_data) are your internal user/business identifiers. They link the transaction to the long-lived User / Business entity assembled from prior verification sessions. Use the SAME vendor_data you supplied when creating the KYC session.

Minimum request body (application/json):
\{
"transaction_id": "your-txn-2026-05-17-001",
"transaction_category": "finance",   // finance | kyc | travel_rule | user_event | audit_trail_event | gambling_bet | gambling_limit_change | gambling_bonus_change
"transaction_details": {
"direction": "outbound",            // "inbound" | "outbound"
"amount": 1500,                     // number or decimal string, up to 18 decimal places (string for exact precision); never negative, because direction carries the sign
"currency": "EUR",                  // any ISO 4217 code (EUR, USD, NGN, ...) or a crypto symbol
"currency_kind": "fiat",            // "fiat" | "crypto" (optional)
"action_type": "withdrawal"         // optional, e.g. deposit/withdrawal/transfer
},
"subject": {                          // APPLICANT party
"entity_type": "individual",        // "individual" | "company"
"vendor_data": "user-12345",        // required
"full_name": "Maria Garcia",        // required
"address": { "country": "ESP" }     // optional
},
"counterparty": { ... },              // optional COUNTERPARTY party (same shape as subject)
"transaction_at": "2026-05-17T08:42:00Z",  // optional, defaults to now
"travel_rule_details": { "status": "AWAITING_COUNTERPARTY", ... }   // optional, for crypto Travel Rule; status is required inside it
}

Currency codes:
\- currency has no enum. Any ISO 4217 alphabetic code (EUR, USD, NGN, ...) and any crypto asset symbol (BTC, ETH, ...) are accepted and stored exactly as you send them, up to 10 characters.
\- Prefer a currently-circulating code. Not every accepted code has an exchange rate: withdrawn currencies and accounting units such as XDR are often still quoted, but when Didit has no rate for the code you send (for example the ISO accounting unit XSU, or a crypto symbol Didit does not price), automatic conversion to your base currency fails and preferred_currency_amount comes back null. A pre-converted amount_in_default_currency is always used as sent when present, so supply it for any code you are not sure has a rate.
\- Set currency_kind = "crypto" for on-chain amounts. The kind gates the transaction's own crypto AML screening: without currency_kind = "crypto" that regular screening step is skipped and no screening fee is estimated or charged for it, even with monitoring enabled or include_crypto_screening = true. Travel Rule attribution is a separate path: on a production application with Travel Rule and VASP attribution enabled, an outbound transaction_category = "travel_rule" request whose beneficiary wallet and chain cannot be reached over any rail triggers a VASP attribution wallet screening, and that screening is billed at the wallet screening price whatever currency_kind is or is not set. The kind does not change the stored decimal scale: up to 18 decimal places are kept either way, but only when amount arrives as a decimal string ("0.123456789012345678"). A JSON number is parsed as a binary float first, so anything beyond about 15 significant digits is rounded before it is stored (0.123456789012345678 is stored as 0.12345678901234568). The kind also decides how the amount is rendered in the transaction PDF. Crypto amounts render with up to 8 decimal places, fiat amounts with their ISO 4217 minor unit (2 for most currencies). Without the kind, RON, MNT and GEL are rendered as fiat because each is both a token and an ISO 4217 currency, so a small token amount can show as 0 in the report.
The VASP attribution screening is skipped when the transaction's own crypto screening already screened that wallet: Didit reuses that result and charges nothing extra.

Example call:
curl -X POST "https://verification.didit.me/v3/transactions/" \
-H "x-api-key: YOUR_API_KEY" -H "Content-Type: application/json" \
-d '{
"transaction_id": "your-txn-2026-05-17-001",
"transaction_category": "finance",
"transaction_details": {"direction":"outbound","amount":1500,"currency":"EUR","action_type":"withdrawal"},
"subject": {"entity_type":"individual","vendor_data":"user-12345","full_name":"Maria Garcia"}
}'

What to read from the response:
\- uuid — Didit transaction id, use for GET /v3/transactions/{transaction_id}/.
\- status - APPROVED | IN_REVIEW | DECLINED | AWAITING_USER (live verdict; at creation, AWAITING_USER comes from a rule action).
\- score (0–100, higher = riskier) and severity (LOW | MEDIUM | HIGH | CRITICAL).
\- decision_reason_code / decision_reason_label — machine + human verdict reason.
\- parties (role APPLICANT for the subject, COUNTERPARTY for the counterparty; kind USER, BUSINESS or EXTERNAL), cost_breakdown, rule_runs, provider_results (crypto screening results) and network_snapshot.
\- travel_rule - the Travel Rule transfer (status, protocol, required, originator_data, beneficiary_data, direction, rail, counterparty_vasp, delivery, discovery, reason, next_actions), or null; action_required - a pending wallet-ownership or verification step, or null.
reason and next_actions say why a COUNTERPARTY_VASP_NOT_FOUND or COUNTERPARTY_VASP_NOT_REACHABLE transfer is stuck and what moves it on (for example email_undeliverable: update_compliance_email, then resend); they are "" and [] for any other status.

Webhooks:
\- transaction.created fires after this call succeeds.
\- For a travel_rule transaction, travel_rule.status.updated fires for each Travel Rule transition, after transaction.created. Each webhook is delivered and retried on its own, so key on transaction_id rather than on arrival order.
\- transaction.status.updated fires whenever the verdict changes (manual review, async screening, rule re-runs). Subscribe a destination via POST /v3/webhook/destinations/.

Failure modes:
\- 400 - duplicate transaction_id, missing required field (including travel_rule_details.status), an unknown travel_rule_details.status ("Invalid travel rule status: ..."), invalid direction/category enum, or malformed party object.
\- 409 - a concurrent request with the same transaction_id was created first.
\- 403 - missing x-api-key (a wrong, revoked or expired key gets 401), or a key without permission for this action; the body is a { "detail": "..." } envelope.
\- 403 - the organization's balance cannot cover the fees this request would charge: { "detail": "...", "code": "insufficient_credits" }, and nothing is created.
\- 429 — rate limited; back off and retry.

Side effects:
\- Creates the transaction record and runs the synchronous rules + screening pipeline.
\- Links the transaction to the User / Business entity that shares the subject.vendor_data.
\- An outbound travel_rule transaction is billed once, at creation, on one line. It pays the Travel Rule fee ($0.02) when Travel Rule is on and Didit starts an exchange for it (amount at or above threshold_amount, including a transfer to a self-hosted wallet or to the user's own verified wallet). Otherwise it is billed as transaction monitoring (included in the plan's monthly transaction allowance, $0.001 each beyond it): below threshold_amount, a Lightning payment the Travel Rule does not apply to, or data recorded while Travel Rule is disabled. A resend never charges again.
\- An inbound travel_rule transaction pays no base fee, an application that joined Travel Rule free pays none on outbound transactions until it turns outbound billing on, and sandbox applications are never charged.
\- Crypto screening, when it runs, adds the Wallet Verification & Screening charge.

For the full integration shape, see /integration/integration-prompt.`

\
Pegar en ## OpenAPI ````yaml es/openapi-25.json POST /v3/transactions/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API de verificación de identidad. Autentícate con el encabezado x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/transactions/: post: tags: - Transactions summary: Crear transacción description: >- Envía una transacción para su monitorización AML y de riesgo síncrona. La transacción se crea como `APPROVED`; después, tus reglas (y el análisis de criptoactivos, cuando corresponde) se ejecutan en línea y pueden cambiar el `status` devuelto a `IN_REVIEW` o `DECLINED`. **`transaction_id` es tu clave de idempotencia** (máx. 128 caracteres, única por aplicación); reutilizarla devuelve 400. Cuando la operación se completa correctamente, se envía un webhook `transaction.created` para las aplicaciones de producción. Las aplicaciones de sandbox no se facturan y no emiten webhooks `transaction.created` ni `transaction.status.updated`. Los intercambios de Travel Rule en sandbox sí emiten webhooks `travel_rule.status.updated` con `environment: sandbox`. Una transferencia de Travel Rule se almacena y se devuelve antes de contactar con ninguna contraparte: `travel_rule.status` se devuelve como `AWAITING_COUNTERPARTY` (o `NOT_APPLICABLE` por debajo de tu umbral, `UNCONFIRMED_OWNERSHIP` para una wallet sin custodia declarada, `COMPLETED` cuando la otra wallet es tu propia wallet verificada) y `travel_rule.protocol` es null. A continuación, Didit elige el canal y envía el intercambio, y cada cambio de estado posterior de la transferencia, incluido `COUNTERPARTY_VASP_NOT_FOUND` cuando ningún canal llega a la contraparte, llega como un webhook `travel_rule.status.updated`. Tus reglas se vuelven a ejecutar cuando cambia el canal o el estado. operationId: createTransaction requestBody: required: true content: application/json: schema: type: object properties: transaction_id: type: string description: >- Tu identificador único de esta transacción (máximo 128 caracteres). example: your-txn-2026-05-17-001 transaction_at: type: string format: date-time description: >- Cuándo se produjo la transacción. Si se omite, se usa el momento actual. time_zone: type: string description: Identificador de zona horaria IANA, p. ej. `Europe/Madrid`. transaction_category: type: string description: >- Categoría de la transacción. También se aceptan alias en CamelCase (`travelRule`, `userPlatformEvent`, `gamblingBet`, …); el valor almacenado y devuelto está en camelCase para las categorías de varias palabras. example: finance enum: - finance - kyc - travel_rule - user_event - audit_trail_event - gambling_bet - gambling_limit_change - gambling_bonus_change - travelRule transaction_details: type: object description: Datos financieros principales de la transacción. required: - direction - amount - currency properties: direction: type: string description: >- Sentido de la transacción respecto al sujeto. No distingue entre mayúsculas y minúsculas; se aceptan `in`/`out` como alias. Se devuelve en mayúsculas (`INBOUND`/`OUTBOUND`). example: outbound enum: - inbound - outbound - in - out amount: type: number description: >- Importe de la transacción (hasta 18 decimales). Envíalo como cadena decimal (p. ej., `"0.123456789012345678"`) cuando importe la precisión exacta: un número JSON se interpreta primero como un float binario, por lo que los dígitos que superan unos 15 dígitos significativos se redondean antes de almacenar el importe. Debe ser cero o mayor: la dirección indica el signo, y un importe negativo devuelve `400`. example: 1500 currency: type: string description: >- Código de moneda. Se acepta cualquier código alfabético ISO 4217 (p. ej., `EUR`, `USD`, `NGN`), así como el símbolo de un criptoactivo (p. ej., `BTC`). Es preferible usar un código actualmente en circulación. No todos los códigos aceptados tienen tipo de cambio: cuando no hay ninguno disponible para el código (por ejemplo, la unidad de cuenta ISO `XSU` o un símbolo cripto al que Didit no asigna precio), la conversión automática falla y `preferred_currency_amount` se devuelve como null, salvo que la solicitud haya incluido un `amount_in_default_currency` ya convertido. example: EUR currency_kind: type: string description: Si la moneda es `fiat` o `crypto`. amount_in_default_currency: type: number nullable: true description: >- Importe ya convertido a la moneda predeterminada. Si se omite, se intenta una conversión de divisas automática. Debe ser cero o mayor. default_currency: type: string description: >- El código de moneda predeterminado para el importe convertido. Cualquier código ISO 4217 actualmente en circulación. payment_details: type: string nullable: true description: Referencia o concepto de pago en texto libre. payment_reference_id: type: string nullable: true description: >- Referencia del sistema de pago externo. Para el análisis AML de hashes de transacciones cripto, envía el hash de la transacción en blockchain y proporciona también `subject.payment_method.account_id` con la dirección relacionada. action_type: type: string nullable: true description: >- Subtipo de la transacción, p. ej., `deposit`, `withdrawal`, `transfer`. crypto_params: type: object description: >- Selección de la red cripto, independiente de la moneda (el símbolo del activo). Registrar un símbolo de token personalizado no garantiza la cobertura del hash de transacción para su contrato. properties: crypto_chain: type: string description: >- Red que se usa realmente para el análisis. El análisis gestionado admite BTC, ETH, LTC, XRP, BCH, DOGE, TRX, SOL, MATIC, BNB, BASE (Base), OP (Optimism), ARB (Arbitrum One), AVAX (Avalanche C-Chain), ADA (Cardano), XLM (Stellar) y HBAR (Hedera). También se aceptan los nombres habituales de las redes, por ejemplo POLYGON o POL para MATIC, BSC para BNB y TRON para TRX. Especifícala siempre para tokens multired. Si falta para USDT, USDC o ETH enviados con un hash de transacción 0x, Didit busca el hash en Ethereum, BNB Chain, Polygon, Base, Arbitrum y Optimism y lo analiza en la red donde lo encuentra; si ninguna red lo tiene, la transacción no se analiza y custom_values.aml_screening_status es FAILED, con el motivo en custom_values.aml_screening_error. Si falta para USDT o USDC analizados por wallet (sin hash de transacción), una dirección de Tron se analiza en Tron, una dirección de Solana en Solana y una dirección 0x en la primera de esas seis redes en la que haya enviado una transacción o tenga el token, o en Ethereum si no está activa en ninguna de ellas. La cobertura de los proveedores conectados varía; LIGHTNING requiere un proveedor conectado compatible. example: BASE subject: type: object description: El sujeto (solicitante) de la transacción. required: - vendor_data - full_name properties: entity_type: type: string description: 'Tipo de entidad: `individual` o `company`.' vendor_data: type: string description: Tu identificador interno de usuario o empresa. example: user-12345 full_name: type: string description: Nombre completo del sujeto. example: Maria Garcia first_name: type: string description: Nombre de la persona. last_name: type: string description: Apellido de la persona. date_of_birth: type: string format: date description: Fecha de nacimiento (YYYY-MM-DD). address: type: object description: Objeto de dirección. properties: country: type: string description: >- Código de país (se recomienda ISO 3166-1 alfa-3). Se copia en el `country_code` de la parte. town: type: string state: type: string street: type: string post_code: type: string institution_details: type: object description: Datos de la institución (para sujetos institucionales). properties: name: type: string code: type: string address: type: object device_context: type: object description: >- Contexto del dispositivo capturado en el momento de la transacción. browser_family y platform deben enviarse como claves explícitas de nivel superior: no se derivan de user_agent. La solicitud también acepta el alias en camelCase device. properties: fingerprint: type: string description: Huella única del dispositivo. persistent_device_id: type: string description: >- Identificador de dispositivo estable entre sesiones (esquema de huella digital v2). user_agent: type: string description: >- Cadena del user agent del navegador o de la aplicación. Alias en CamelCase: userAgent. browser_family: type: string description: >- Familia del navegador (p. ej., Chrome, Firefox, Safari). Debe enviarse explícitamente: no se deriva de user_agent. Alias en CamelCase: browserFamily. browser_version: type: string description: >- Cadena de la versión del navegador. Debe enviarse explícitamente. Alias en CamelCase: browserVersion. platform: type: string description: >- Identificador de la plataforma (web, ios, android, macos, windows, linux). Debe enviarse de forma explícita: no se deduce de user_agent. os_family: type: string description: >- Familia del sistema operativo (p. ej., iOS, Android, Windows). Alias en CamelCase: osFamily. os_version: type: string description: >- Cadena de versión del sistema operativo. Alias en CamelCase: osVersion. accept_language: type: string description: >- Valor del encabezado Accept-Language. Alias en CamelCase: acceptLang. session_id: type: string description: >- Identificador de la sesión actual del usuario. Se almacena en los metadatos. Alias en camelCase: sessionId. session_age_ms: type: number description: >- Antigüedad de la sesión del usuario en milisegundos en el momento de la transacción. Alias en CamelCase: sessionAgeMs. network_context: type: object description: >- Contexto de red con dirección IP y geolocalización. Un bloque ipInfo de nivel superior también se integra en este objeto. properties: ip_address: type: string description: >- Dirección IP del cliente. Alias en CamelCase: ip. ip_country_code: type: string description: >- País de la IP resuelto por geolocalización (ISO 3166-1 alfa-3). Alias en CamelCase: countryCode3. latitude: type: number description: >- Latitud geográfica de la IP. Alias en CamelCase: lat. longitude: type: number description: >- Longitud geográfica de la IP. Alias en CamelCase: lon. payment_method: type: object description: Método de pago que usa el sujeto. properties: method_type: type: string description: >- Tipo de método de pago: `bank_card`, `bank_account`, `crypto_wallet`, `ewallet`, `unhosted_wallet`, `other`. account_id: type: string description: >- Identificador de la cuenta (p. ej., IBAN, dirección de wallet). Para el análisis cripto, debe contener la dirección de wallet de este participante. El análisis de hash de transacción entrante requiere la dirección de depósito del servicio o del cliente en el sujeto. El análisis saliente usa la wallet de destino de la contraparte. En una transferencia cripto en bitcoin o Lightning puede ser una solicitud de pago Lightning (factura BOLT11, oferta BOLT12, LNURL) o una Lightning Address: Didit guarda como cuenta el beneficiario que indica ("" cuando no indica ninguno) y lo que dice la solicitud en `chain_details.lightning` de la transferencia de Travel Rule. Como máximo 255 caracteres una vez guardado. En una transferencia cripto en bitcoin o Lightning puede ser una solicitud de pago Lightning (factura BOLT11, oferta BOLT12, LNURL) o una Lightning Address: Didit guarda como cuenta el beneficiario que indica ("" cuando no indica ninguno) y lo que dice la solicitud en `chain_details.lightning` de la transferencia de Travel Rule. Como máximo 255 caracteres una vez guardado. memo: type: string maxLength: 256 description: >- La etiqueta de destino o memo que forma parte de la wallet en una red con memo (XRP, XLM, EOS, ATOM, HBAR). En una misma dirección compartida de exchange, cada memo es un método de pago independiente. XRP: una etiqueta de destino, un número entero de 0 a 4294967295 (se acepta un número JSON). XLM: un memo de texto de hasta 28 bytes, un id de 64 bits o un hash de 32 bytes en hexadecimal. EOS: hasta 256 bytes. ATOM: hasta 256 caracteres. HBAR: hasta 100 bytes. Las wallets de Bitcoin, EVM, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin y Lightning no admiten memo: indicar uno en ellas produce un `400`. Alias: `destinationTag` o `destination_tag`. issuing_country: type: string description: Código de país ISO 3166-1 alpha-3 del emisor. counterparty: type: object description: La contraparte de la transacción (opcional). properties: entity_type: type: string description: 'Tipo de entidad: `individual` o `company`.' vendor_data: type: string description: Tu identificador interno de la contraparte. full_name: type: string description: Nombre completo de la contraparte. first_name: type: string last_name: type: string date_of_birth: type: string format: date address: type: object description: Objeto de dirección con `country` (ISO 3166-1 alfa-3). institution_details: type: object device_context: type: object description: >- Contexto del dispositivo de la contraparte. browser_family y platform deben enviarse como claves explícitas de nivel superior, ya que no se derivan de user_agent. properties: fingerprint: type: string description: Huella única del dispositivo. persistent_device_id: type: string description: >- Identificador de dispositivo estable entre sesiones (esquema de huella digital v2). user_agent: type: string description: >- Cadena del user agent del navegador o de la aplicación. Alias en CamelCase: userAgent. browser_family: type: string description: >- Familia del navegador (p. ej., Chrome, Firefox, Safari). Debe enviarse explícitamente: no se deriva de user_agent. Alias en CamelCase: browserFamily. browser_version: type: string description: >- Cadena de la versión del navegador. Debe enviarse explícitamente. Alias en CamelCase: browserVersion. platform: type: string description: >- Identificador de la plataforma (web, ios, android, macos, windows, linux). Debe enviarse de forma explícita: no se deduce de user_agent. os_family: type: string description: >- Familia del sistema operativo (p. ej., iOS, Android, Windows). Alias en CamelCase: osFamily. os_version: type: string description: >- Cadena de versión del sistema operativo. Alias en CamelCase: osVersion. accept_language: type: string description: >- Valor del encabezado Accept-Language. Alias en CamelCase: acceptLang. session_id: type: string description: >- Identificador de la sesión de la contraparte. Se almacena en los metadatos. Alias en camelCase: sessionId. session_age_ms: type: number description: >- Antigüedad de la sesión del usuario en milisegundos en el momento de la transacción. Alias en CamelCase: sessionAgeMs. network_context: type: object description: >- Contexto de red con dirección IP y geolocalización. Un bloque ipInfo de nivel superior también se integra en este objeto. properties: ip_address: type: string description: >- Dirección IP del cliente. Alias en CamelCase: ip. ip_country_code: type: string description: >- País de la IP resuelto por geolocalización (ISO 3166-1 alfa-3). Alias en CamelCase: countryCode3. latitude: type: number description: >- Latitud geográfica de la IP. Alias en CamelCase: lat. longitude: type: number description: >- Longitud geográfica de la IP. Alias en CamelCase: lon. payment_method: type: object description: >- Método de pago que usa la contraparte. En las transacciones travelRule, `method_type: "unhosted_wallet"` declara la wallet de la contraparte como wallet sin custodia: la transferencia omite el enrutamiento al VASP de la contraparte, se crea directamente en `UNCONFIRMED_OWNERSHIP` y (cuando `auto_wallet_verification` está activado) se genera automáticamente una sesión del widget de propiedad de la wallet, que se devuelve en el bloque `action_required` de la transacción. properties: method_type: type: string description: >- Tipo de método de pago: `bank_card`, `bank_account`, `crypto_wallet`, `ewallet`, `unhosted_wallet`, `other`. Usa `unhosted_wallet` para declarar una wallet sin custodia para la Travel Rule. account_id: type: string description: >- Identificador de la cuenta (p. ej., IBAN o dirección de wallet). En una transferencia cripto en bitcoin o Lightning puede ser una solicitud de pago Lightning (factura BOLT11, oferta BOLT12, LNURL) o una Lightning Address: Didit guarda como cuenta el beneficiario que indica ("" cuando no indica ninguno) y lo que dice la solicitud en `chain_details.lightning` de la transferencia de Travel Rule. Como máximo 255 caracteres una vez guardado. En una transferencia cripto en bitcoin o Lightning puede ser una solicitud de pago Lightning (factura BOLT11, oferta BOLT12, LNURL) o una Lightning Address: Didit guarda como cuenta el beneficiario que indica ("" cuando no indica ninguno) y lo que dice la solicitud en `chain_details.lightning` de la transferencia de Travel Rule. Como máximo 255 caracteres una vez guardado. memo: type: string maxLength: 256 description: >- La etiqueta de destino o memo que forma parte de la wallet en una red con memo (XRP, XLM, EOS, ATOM, HBAR). En una misma dirección compartida de exchange, cada memo es un método de pago independiente. XRP: una etiqueta de destino, un número entero de 0 a 4294967295 (se acepta un número JSON). XLM: un memo de texto de hasta 28 bytes, un id de 64 bits o un hash de 32 bytes en hexadecimal. EOS: hasta 256 bytes. ATOM: hasta 256 caracteres. HBAR: hasta 100 bytes. Las wallets de Bitcoin, EVM, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin y Lightning no admiten memo: indicar uno en ellas produce un `400`. Alias: `destinationTag` o `destination_tag`. issuing_country: type: string custom_properties: type: object description: >- Pares clave-valor arbitrarios adjuntos a la transacción. Cada clave se puede referenciar en las condiciones de las reglas con la ruta de campo `custom_values.`. additionalProperties: true example: merchant_id: test bank_name: test_2 travel_rule_details: type: object description: >- Datos de Travel Rule. Cuando Travel Rule está habilitada y transaction_category es travel_rule, Didit gestiona el intercambio por sí mismo: ignora status, protocol, required y obligations_count, y usa originator_data, beneficiary_data y metadata. En caso contrario, Didit almacena estos valores como un registro pasivo de Travel Rule. Mientras Travel Rule esté activada, una transferencia saliente igual o superior a tu umbral debe incluir lo que exige su régimen (EU TFR o la Recomendación 16 del FATF), que se comprueba en las partes que envías: si falta un campo, la respuesta es 400 en `travel_rule_details.originator_data` o `travel_rule_details.beneficiary_data`, por ejemplo "EU TFR requires the originator name." required: - status properties: status: type: string description: >- Obligatorio siempre que envíes travel_rule_details. Uno de los estados de transferencia de la Travel Rule (por ejemplo, AWAITING_COUNTERPARTY, COMPLETED, NOT_APPLICABLE); también se aceptan y se asignan las grafías en minúsculas y en camelCase, y los valores heredados UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED y EXEMPT. Cualquier otro valor devuelve 400. protocol: type: string required: type: boolean obligations_count: type: integer originator_data: type: object description: >- Parte ordenante, como campos planos o como una persona IVMS 101. Si se trata de tu usuario con una verificación KYC aprobada, Didit reemplaza los campos que contiene la verificación por los valores verificados (consulta `metadata.originator_provenance`). Debe ser un objeto: cualquier otro valor devuelve `400`. En una red con memo, una clave `memo` indica el memo o la etiqueta de la wallet del ordenante. beneficiary_data: type: object description: >- Parte beneficiaria, como campos planos o como una persona IVMS 101. Debe ser un objeto: cualquier otro valor devuelve un `400`. Para enrutar la transferencia, Didit lee `wallet_address` (si está vacío, se rellena con `counterparty.payment_method.account_id`), `chain` (se rellena con `transaction_details.crypto_params.crypto_chain` o con `currency` cuando esta nombra una cadena compatible), `name` (que recurre a `counterparty.full_name`), `travel_address`, `counterparty_vasp_name`, `counterparty_vasp_lei` y `counterparty_vasp_email`. En una red con memo, `memo` indica el memo o la etiqueta de la wallet del beneficiario. `wallet_address` y `memo` prevalecen sobre el método de pago de la contraparte. metadata: type: object utxo: allOf: - $ref: '#/components/schemas/TravelRuleUtxo' description: >- Opcional, solo para cadenas UTXO (BTC, LTC, BCH, DOGE). Las entradas y salidas de la transacción, a partir de las cuales Didit deduce la wallet del ordenante y la salida del beneficiario cuando no las declaras. originator: type: object description: >- Un bloque de ordenante IVMS 101: `originatorPersons` (una `naturalPerson` o `legalPerson`; una persona jurídica hace que la parte sea una empresa) y `accountNumber` (direcciones de wallet). Se usa para `originator_data` cuando ese objeto está vacío. Un bloque mal formado responde 400 con la clave de su ruta, por ejemplo `originator.originatorPersons`. beneficiary: type: object description: >- Un bloque de beneficiario IVMS 101: `beneficiaryPersons` (una `naturalPerson` o `legalPerson`; una persona jurídica hace que la parte sea una empresa) y `accountNumber` (direcciones de wallet). Se usa para `beneficiary_data` cuando ese objeto está vacío. Un bloque mal formado responde 400 con la clave de su ruta, por ejemplo `beneficiary.beneficiaryPersons`. ivms101: type: object description: >- Los bloques `originator` y `beneficiary` agrupados en un único objeto IVMS 101 (también se acepta `IVMS101`). Los bloques de nivel superior prevalecen sobre los del contenedor. network_snapshot: type: object description: Instantánea precalculada del grafo de red. properties: nodes: type: array items: type: object edges: type: array items: type: object metrics: type: object include_crypto_screening: type: boolean nullable: true description: >- Sobrescritura por transacción del análisis de blockchain de criptoactivos. Cuando es `true`, el análisis de criptoactivos se realiza independientemente del valor predeterminado de la aplicación. Cuando es `false`, el análisis de criptoactivos se omite aunque esté habilitado en la configuración de la aplicación. Cuando se omite o es `null`, se usa el valor predeterminado a nivel de aplicación configurado en la Console. El análisis de criptoactivos requiere `transaction_details.direction`, `currency_kind: "crypto"`, una cadena/moneda y la dirección de wallet que corresponde según la dirección de la transacción: el análisis entrante previo a la transferencia usa `counterparty.payment_method.account_id`, el análisis entrante por hash de transacción usa `subject.payment_method.account_id` y el análisis saliente usa `counterparty.payment_method.account_id`. Cuando `transaction_details.payment_reference_id` contiene un hash de transacción de blockchain, Didit realiza el análisis de la transacción y devuelve el enriquecimiento con el resumen de la transacción cuando está disponible. required: - transaction_id - transaction_category - transaction_details - subject examples: Minimal fiat withdrawal: summary: Payload mínimo aceptable para una transferencia fiat saliente value: transaction_id: your-txn-2026-05-17-001 transaction_category: finance transaction_details: direction: outbound amount: 1500 currency: EUR action_type: withdrawal subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia Crypto outbound with screening: summary: >- Retiro saliente de criptoactivos a una wallet sin custodia, con análisis opcional (opt-in) value: transaction_id: your-txn-2026-05-17-002 transaction_category: finance include_crypto_screening: true transaction_details: direction: outbound amount: 0.5 currency: BTC currency_kind: crypto amount_in_default_currency: 32500 default_currency: USD action_type: withdrawal subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia payment_method: method_type: crypto_wallet account_id: bc1qexampleexchangewalletaddressxyz issuing_country: ESP counterparty: entity_type: individual payment_method: method_type: unhosted_wallet account_id: bc1qexampleexternalwalletaddressabc Travel Rule transfer: summary: >- Transferencia saliente de criptoactivos con datos del ordenante y del beneficiario según la Travel Rule value: transaction_id: your-txn-2026-05-17-003 transaction_category: travel_rule transaction_details: direction: outbound amount: 25000 currency: USDT currency_kind: crypto action_type: transfer subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia date_of_birth: '1992-03-14' address: country: ESP town: Madrid street: Calle Mayor 1 post_code: '28013' counterparty: entity_type: individual full_name: John Beneficiary institution_details: name: Beneficiary VASP, Inc. code: BVASP-US travel_rule_details: status: AWAITING_COUNTERPARTY protocol: IVMS101 required: true originator_data: name: Maria Garcia beneficiary_data: name: John Beneficiary responses: '201': description: >- Transacción enviada y monitorizada. El cuerpo es el detalle completo de la transacción (con la misma estructura que `GET /v3/transactions/{transaction_id}/`) y refleja los resultados de las reglas ya aplicadas. content: application/json: schema: $ref: '#/components/schemas/TransactionDetail' examples: Approved with no rule hits: value: uuid: abcdef12-3456-4890-abcd-ef1234567890 environment: live transaction_number: 4123 txn_id: your-txn-2026-05-17-001 txn_date: '2026-05-17T08:42:00Z' zone_id: Europe/Madrid transaction_type: finance action_type: withdrawal direction: OUTBOUND status: APPROVED source: LIVE amount: '1500' currency: EUR currency_type: fiat amount_in_default_currency: '1620.45' default_currency_code: USD preferred_currency_amount: '1620.45' preferred_currency_code: USD payment_details: Withdrawal to crypto wallet payment_txn_id: null score: 0 severity: null decision_reason_code: null decision_reason_label: null vendor_data: user-12345 metadata: subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia address: {} institution_details: {} device_context: {} counterparty: {} props: {} tags: [] parties: - uuid: b1111111-2222-4333-8444-555555555555 role: APPLICANT entity_type: individual kind: USER vendor_data: user-12345 full_name: Maria Garcia first_name: null last_name: null country_code: null dob: null address: {} institution_info: {} device: {} external_party_snapshot: null payment_methods: [] documents: [] activities: - uuid: d4e5f6a7-8901-4bcd-9ef0-123456789abc activity_type: TRANSACTION_CREATED source: TRANSACTION status: APPROVED title: withdrawal description: Transaction recorded. metadata: {} occurred_at: '2026-05-17T08:42:11Z' alerts: [] rule_runs: [] provider_results: [] travel_rule: null network_snapshot: null remediation: null action_required: null cost_breakdown: null Flagged for review: value: uuid: abcdef12-3456-4890-abcd-ef1234567891 environment: live transaction_number: 4124 txn_id: your-txn-2026-05-17-002 txn_date: '2026-05-17T08:42:00Z' zone_id: Europe/Madrid transaction_type: finance action_type: withdrawal direction: OUTBOUND status: IN_REVIEW source: LIVE amount: '0.5' currency: BTC currency_type: crypto amount_in_default_currency: '32500' default_currency_code: USD preferred_currency_amount: '32500' preferred_currency_code: USD payment_details: Withdrawal to crypto wallet payment_txn_id: null score: 78 severity: HIGH decision_reason_code: WALLET_HIGH_RISK decision_reason_label: Destination wallet flagged as high risk vendor_data: user-12345 metadata: subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia address: {} institution_details: {} device_context: {} counterparty: {} props: order_id: ord-9988 tags: [] parties: - uuid: b1111111-2222-4333-8444-555555555555 role: APPLICANT entity_type: individual kind: USER vendor_data: user-12345 full_name: Maria Garcia first_name: null last_name: null country_code: null dob: null address: {} institution_info: {} device: {} external_party_snapshot: null payment_methods: [] documents: [] activities: [] alerts: - uuid: a7b8c9d0-1234-4abc-9def-567890abcdef title: Destination wallet flagged as high risk description: Provider risk score exceeded the configured threshold. severity: HIGH status: OPEN source: RULE metadata: {} created_at: '2026-05-17T08:42:12Z' due_at: null rule_runs: - uuid: e5f6a7b8-9012-4cde-af01-23456789abcd rule: f6a7b8c9-0123-4def-b012-3456789abcde rule_title: High-risk wallet screening rule_description: null rule_category: crypto matched: true is_test: false mode: ACTIVE severity: HIGH score_delta: 78 status_target: IN_REVIEW action_summary: score +78; change_status:IN_REVIEW metadata: {} created_at: '2026-05-17T08:42:12Z' provider_results: [] travel_rule: null network_snapshot: null remediation: null action_required: null cost_breakdown: null '400': description: >- La validación ha fallado (faltan campos obligatorios, `transaction_id` duplicado, valor de enumeración desconocido, moneda no válida, etc.). content: application/json: examples: Missing required field: value: transaction_details: amount: - This field is required. Duplicate transaction_id: value: transaction_id: - A transaction with this transaction_id already exists. Invalid category: value: non_field_errors: - Unsupported transaction category. Missing subject identity: value: subject: - subject.vendor_data and subject.full_name are required. Blocklisted participant: value: vendor_data: - >- The individual 'user-12345' is in the blocklist and cannot participate in transactions. '403': description: >- Falta la clave de API, no es válida o fue revocada, o la clave no puede enviar transacciones para esta aplicación. Si falta la clave, se devuelve `403`; si es incorrecta, fue revocada o expiró, se devuelve `401`. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- Otra solicitud con el mismo `transaction_id` creó la transacción mientras esta se procesaba, por lo que solo una de dos solicitudes simultáneas se completa con éxito. Consulta la transacción existente en lugar de volver a enviarla. content: application/json: examples: Concurrent duplicate: value: detail: A transaction with this transaction_id already exists. '429': description: >- Límite de solicitudes superado; espera y reintenta cuando haya pasado el intervalo indicado en `Retry-After`. content: application/json: examples: Throttled: value: detail: Request was throttled. Expected available in 30 seconds. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: |- curl -X POST 'https://verification.didit.me/v3/transactions/' \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{ "transaction_id": "your-txn-2026-05-17-001", "transaction_category": "finance", "transaction_details": { "direction": "outbound", "amount": 1500, "currency": "EUR", "action_type": "withdrawal" }, "subject": { "entity_type": "individual", "vendor_data": "user-12345", "full_name": "Maria Garcia" } }' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.transactions.create( transaction_id="your-txn-2026-05-17-001", transaction_category="finance", transaction_details={ "direction": "outbound", "amount": 1500.0, "currency": "EUR", "action_type": "withdrawal", }, subject={ "entity_type": "individual", "vendor_data": "user-12345", "full_name": "Maria Garcia", }, ) print(result) - lang: javascript label: Node.js source: |- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.transactions.create({ transaction_id: "your-txn-2026-05-17-001", transaction_category: "finance", transaction_details: { direction: "outbound", amount: 1500.0, currency: "EUR", action_type: "withdrawal", }, subject: { entity_type: "individual", vendor_data: "user-12345", full_name: "Maria Garcia", }, }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Transactions.Create(ctx, didit.TransactionsCreateParams{\n\tTransactionID: \"your-txn-2026-05-17-001\",\n\tTransactionCategory: \"finance\",\n\tTransactionDetails: didit.TransactionsCreateParamsTransactionDetails{\n\t\tDirection: \"outbound\",\n\t\tAmount: 1500.0,\n\t\tCurrency: \"EUR\",\n\t\tActionType: didit.String(\"withdrawal\"),\n\t},\n\tSubject: didit.TransactionsCreateParamsSubject{\n\t\tEntityType: didit.String(\"individual\"),\n\t\tVendorData: \"user-12345\",\n\t\tFullName: \"Maria Garcia\",\n\t},\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.TransactionsCreateParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.transactions().create(TransactionsCreateParams.builder() .transactionId("your-txn-2026-05-17-001") .transactionCategory(TransactionsCreateParams.TransactionCategory.of("finance")) .transactionDetails(TransactionsCreateParams.TransactionDetails.builder() .direction(TransactionsCreateParams.TransactionDetails.Direction.of("outbound")) .amount(1500.0) .currency("EUR") .actionType("withdrawal") .build()) .subject(TransactionsCreateParams.Subject.builder() .entityType("individual") .vendorData("user-12345") .fullName("Maria Garcia") .build()) .build()); System.out.println(result); - lang: php label: PHP source: |- transactions->create([ 'transaction_id' => 'your-txn-2026-05-17-001', 'transaction_category' => 'finance', 'transaction_details' => [ 'direction' => 'outbound', 'amount' => 1500.0, 'currency' => 'EUR', 'action_type' => 'withdrawal', ], 'subject' => [ 'entity_type' => 'individual', 'vendor_data' => 'user-12345', 'full_name' => 'Maria Garcia', ], ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.transactions.create( transaction_id: "your-txn-2026-05-17-001", transaction_category: "finance", transaction_details: { direction: "outbound", amount: 1500.0, currency: "EUR", action_type: "withdrawal", }, subject: { entity_type: "individual", vendor_data: "user-12345", full_name: "Maria Garcia", } ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Transactions.CreateAsync(new TransactionsCreateParams { TransactionId = "your-txn-2026-05-17-001", TransactionCategory = "finance", TransactionDetails = new() { Direction = "outbound", Amount = 1500.0, Currency = "EUR", ActionType = "withdrawal", }, Subject = new() { EntityType = "individual", VendorData = "user-12345", FullName = "Maria Garcia", }, }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: TravelRuleUtxo: type: object description: >- Las entradas y salidas de una transferencia UTXO (BTC, LTC, BCH, DOGE). Solo se aceptan en esas cadenas: en cualquier otra cadena se devuelve un `400`. A partir de ellas, Didit infiere la wallet del ordenante (la declarada o, si no, la dirección de entrada que más aportó) y la salida del beneficiario (la declarada o, si no, la única salida que no devuelve fondos a una dirección de entrada como cambio o, si no, la única salida que paga el importe de la transferencia). El resultado está en el `chain_details` de la transferencia. required: - outputs properties: inputs: type: array maxItems: 1000 items: $ref: '#/components/schemas/TravelRuleUtxoEntry' description: >- Opcional. Sin entradas, no se infiere ningún ordenante ni se reconoce ninguna salida de cambio. outputs: type: array minItems: 1 maxItems: 1000 items: $ref: '#/components/schemas/TravelRuleUtxoEntry' TransactionDetail: type: object description: >- Registro de monitorización completo de una transacción, tal como lo devuelven `GET /v3/transactions/{transaction_id}/` y `POST /v3/transactions/`. properties: uuid: type: string format: uuid description: >- Identificador estable de Didit de la transacción. Úsalo como `{transaction_id}` en las llamadas posteriores. environment: type: string enum: - live - sandbox description: >- Entorno de la aplicación a la que pertenece la transacción. Una transacción de `sandbox` se almacena, pero nunca se evalúa, analiza, notifica ni factura, por lo que un `rule_runs` vacío significa "no evaluada". transaction_number: type: integer description: >- Número secuencial de transacción dentro de la aplicación que se muestra en la consola (p. ej., `4123`). txn_id: type: string description: >- El `transaction_id` que proporcionaste al crearla (máx. 128 caracteres). Único por aplicación. txn_date: type: string format: date-time description: >- Cuándo se produjo la transacción (a partir de `transaction_at`; por defecto, el momento del envío). zone_id: type: string nullable: true description: Identificador de zona horaria IANA proporcionado al crear. transaction_type: type: string description: >- Categoría de nivel superior tal como se almacena: `finance`, `kyc`, `travelRule`, `userPlatformEvent`, `gamblingBet`, `gamblingLimitChange`, `gamblingBonusChange`, `auditTrailEvent`. Ten en cuenta que los valores de varias palabras se devuelven en camelCase aunque se envíen en snake_case. action_type: type: string description: >- Subtipo dentro de la categoría (p. ej., `deposit`, `withdrawal`, `transfer`). Si no se indica, toma por defecto el valor de la categoría. direction: type: string enum: - INBOUND - OUTBOUND description: >- Sentido respecto al sujeto. Se almacena en mayúsculas independientemente de cómo se envíe (en la entrada se aceptan `in`/`out`/`inbound`/`outbound`). status: type: string enum: - APPROVED - IN_REVIEW - DECLINED - AWAITING_USER description: >- Veredicto de monitorización actual. Las transacciones se crean como `APPROVED`; las reglas pueden cambiarlas a `IN_REVIEW`/`DECLINED` de forma síncrona. source: type: string enum: - LIVE - IMPORTED description: >- Cómo se originó el registro: `LIVE` para las transacciones enviadas mediante la API o el SDK, `IMPORTED` para las transacciones cargadas mediante la importación de la consola. amount: type: string description: >- Importe de la transacción como cadena decimal sin ceros finales (p. ej., `"1500"`, `"0.5"`, `"0.123456789012345678"`). Hasta 18 decimales. currency: type: string description: >- Código de moneda de `amount`. Se acepta cualquier código alfabético ISO 4217 (p. ej. `EUR`, `USD`, `NGN`), así como el símbolo de un criptoactivo (p. ej. `BTC`). Es preferible un código actualmente en circulación. No todos los códigos aceptados tienen tipo de cambio. Cuando no hay ninguno disponible para el código, la conversión automática falla. Es el caso, por ejemplo, de la unidad contable ISO `XSU` o de un símbolo cripto al que Didit no asigna precio. Entonces `preferred_currency_amount` se devuelve como null, salvo que la solicitud haya incluido un `amount_in_default_currency` ya convertido. currency_type: type: string nullable: true description: '`fiat` o `crypto`, tal como se envió en `currency_kind`.' amount_in_default_currency: type: string nullable: true description: >- Importe ya convertido que proporcionaste, como cadena decimal sin ceros finales. default_currency_code: type: string nullable: true preferred_currency_amount: type: string nullable: true description: >- `amount` convertido a la moneda preferida de la aplicación, cuando está disponible. preferred_currency_code: type: string nullable: true payment_details: type: string nullable: true description: Referencia o concepto de pago en texto libre del envío. payment_txn_id: type: string nullable: true description: >- Referencia del sistema de pago externo (p. ej., el hash de la transacción en blockchain) procedente de `payment_reference_id`. score: type: integer description: >- Puntuación de riesgo acumulada por las reglas (normalmente de 0 a 100). Cuanto más alta, mayor riesgo. severity: type: string nullable: true enum: - UNKNOWN - LOW - MEDIUM - HIGH - CRITICAL description: >- Gravedad categórica del riesgo establecida por reglas o proveedores (`UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`). `null` hasta que algo la establezca. decision_reason_code: type: string nullable: true description: Motivo legible por máquina del `status` actual. decision_reason_label: type: string nullable: true description: Etiqueta legible de `decision_reason_code`. vendor_data: type: string nullable: true description: Copia de conveniencia del `vendor_data` del solicitante. metadata: type: object description: >- Instantánea de los payloads `subject` y `counterparty` tal como se enviaron en el momento de la creación. props: type: object description: >- Las `custom_properties` que proporcionaste al crearlo. En las condiciones de las reglas, cada clave se referencia como `custom_values.`. tags: type: array items: type: object properties: uuid: type: string format: uuid name: type: string color: type: string description: type: string nullable: true source: type: string enum: - didit - custom description: >- Si la etiqueta es un preajuste de Didit o una etiqueta personalizada. description: >- Etiquetas asociadas a la transacción (manualmente o mediante reglas). parties: type: array items: type: object properties: uuid: type: string format: uuid role: type: string enum: - APPLICANT - REMITTER - BENEFICIARY - COUNTERPARTY description: >- Rol de la parte. El endpoint de creación asigna `APPLICANT` (el sujeto) y `COUNTERPARTY`. entity_type: type: string enum: - individual - company - external - unhostedWallet kind: type: string enum: - USER - BUSINESS - EXTERNAL description: >- Las partes `USER`/`BUSINESS` se vinculan a una entidad propiedad de Didit mediante `vendor_data`. Las partes `EXTERNAL` no tienen ninguna entidad de Didit detrás. vendor_data: type: string nullable: true description: Tu identificador interno de usuario o empresa. full_name: type: string nullable: true first_name: type: string nullable: true last_name: type: string nullable: true country_code: type: string nullable: true description: >- Código de país del `address.country` enviado (normalmente ISO 3166-1 alfa-3). dob: type: string format: date nullable: true description: Fecha de nacimiento del `date_of_birth` enviado. address: type: object description: Objeto de dirección tal como se envió. `{}` cuando se omite. institution_info: type: object description: >- Datos de la institución tal como se enviaron. `{}` si se omiten. device: type: object description: >- Contexto del dispositivo normalizado, incluido el enriquecimiento de IP del lado del servidor en network_context (geolocalización, indicadores de VPN o centro de datos) cuando se proporcionó una IP. properties: fingerprint: type: string description: Huella única del dispositivo. persistent_device_id: type: string description: >- Identificador de dispositivo estable entre sesiones (esquema de huella digital v2). user_agent: type: string description: Cadena del user agent del navegador o de la aplicación. browser_family: type: string description: Familia del navegador (p. ej., Chrome, Firefox, Safari). browser_version: type: string description: Cadena de la versión del navegador. platform: type: string description: >- Identificador de la plataforma (web, ios, android, macos, windows, linux). os_family: type: string description: >- Familia del sistema operativo (p. ej., iOS, Android, Windows). os_version: type: string description: Cadena de versión del sistema operativo. accept_language: type: string description: Valor del encabezado Accept-Language. session_id: type: string description: Identificador de la sesión (almacenado en los metadatos). session_age_ms: type: number description: Antigüedad de la sesión en milisegundos. network_context: type: object description: Contexto de red con dirección IP y geolocalización. properties: ip_address: type: string description: Dirección IP del cliente. ip_country_code: type: string description: >- País de la IP resuelto por geolocalización (ISO 3166-1 alfa-3). latitude: type: number description: Latitud geográfica de la IP. longitude: type: number description: Longitud geográfica de la IP. external_party_snapshot: type: object nullable: true description: >- Copia fija de los datos de la parte para las partes `EXTERNAL`. `null` mientras la parte esté vinculada a un usuario o una empresa de Didit. description: Partes de la transacción (solicitante, contraparte). payment_methods: type: array items: type: object properties: uuid: type: string format: uuid payment_method_type: type: string enum: - bank_card - bank_account - e_wallet - crypto_wallet - unhosted_wallet - other label: type: string nullable: true fingerprint: type: string nullable: true description: >- SHA-256 sobre `type:account_id:issuing_country`: identificador estable para correlacionar la reutilización del mismo instrumento. account_id: type: string nullable: true description: >- Identificador de la cuenta (IBAN, dirección de wallet, token de tarjeta, …). issuing_country: type: string nullable: true owner_kind: type: string enum: - USER - BUSINESS - EXTERNAL vendor_data: type: string nullable: true description: Tu identificador para el usuario o la empresa propietarios. owner_name: type: string nullable: true institution_info: type: object details: type: object description: Objeto `payment_method` sin procesar tal como se envió. external_owner_snapshot: type: object nullable: true role: type: string enum: - SOURCE - DESTINATION - FUNDING - BENEFICIARY description: >- Cómo se usó este método en la transacción. El endpoint de creación asigna `SOURCE`/`DESTINATION` según el sentido (saliente: sujeto = SOURCE; entrante: sujeto = DESTINATION). description: Métodos de pago vinculados a la transacción. documents: type: array description: >- Archivos adjuntados a la transacción desde la consola. `[]` cuando no hay ninguno. items: type: object properties: uuid: type: string format: uuid label: type: string nullable: true note: type: string nullable: true uploaded_by: type: string nullable: true created_at: type: string format: date-time files: type: array items: type: object properties: uuid: type: string format: uuid file_url: type: string format: uri nullable: true description: >- URL de descarga firmada de corta duración; obtenla cuando la necesites en lugar de guardarla. original_filename: type: string nullable: true file_size: type: integer nullable: true activities: type: array items: type: object properties: uuid: type: string format: uuid activity_type: type: string description: >- Por ejemplo, `TRANSACTION_CREATED`, `TRANSACTION_NOTE_ADDED`, `TRANSACTION_STATUS_CHANGED`. source: type: string status: type: string nullable: true title: type: string nullable: true description: type: string nullable: true metadata: type: object occurred_at: type: string format: date-time description: >- Entradas del registro de actividad (creación, notas, revisiones manuales, cambios de estado). alerts: type: array items: type: object properties: uuid: type: string format: uuid title: type: string description: type: string nullable: true severity: type: string enum: - UNKNOWN - LOW - MEDIUM - HIGH - CRITICAL status: type: string enum: - OPEN - INVESTIGATING - AWAITING_USER - PENDING_SAR - SAR_FILED - RESOLVED - DISMISSED source: type: string enum: - RULE - PROVIDER - MANUAL metadata: type: object created_at: type: string format: date-time due_at: type: string format: date-time nullable: true description: >- Actualmente siempre vacío. Una alerta abierta es una transacción con estado `IN_REVIEW` o `AWAITING_USER`. rule_runs: type: array items: type: object properties: uuid: type: string format: uuid rule: type: string format: uuid description: UUID de la regla que se ejecutó. rule_title: type: string rule_description: type: string nullable: true rule_category: type: string matched: type: boolean description: >- Si las condiciones de la regla coincidieron con esta transacción. Solo se registra una ejecución para las reglas que coinciden, por lo que las evaluaciones en producción siempre tienen `true`. is_test: type: boolean description: >- True cuando la regla se ejecutó en modo TEST (sin efecto en el estado ni en la puntuación). mode: type: string enum: - ACTIVE - DISABLED - TEST severity: type: string nullable: true score_delta: type: integer description: Puntuación añadida por las acciones `add_score` de esta regla. status_target: type: string nullable: true description: Estado establecido por una acción `change_status`, si la hay. action_summary: type: string nullable: true description: >- Resumen de las acciones que ejecutó la regla, unidas con `; ` (p. ej., `score +30; change_status:IN_REVIEW; add_tag:high_risk_country`). Partes: `score +N`, `change_status:`, `add_tag:`, `add_note`, `add_to_list`, `open_case`. `null` cuando la regla no ejecutó ninguna acción. metadata: type: object description: >- Detalle de la evaluación: `scope_match`, `conditions[]` y `aggregations[]`. Cada entrada de condición incluye `field`, `operator`, `expected_value`, el `current_value` leído de la transacción, `matched`, `group_index` y `group_logic`. Cada entrada de agregación (velocidad / recuento / suma) incluye `metric`, `field`, `operator`, `expected_value`, el `computed_value` que dio como resultado el agregado, `window`, `filters`, `matched` y `sample_references`; las agregaciones asíncronas diferidas tienen `computed_value: null` y `deferred: true`. Un grupo de condiciones anidado es una única entrada de `conditions[]` con `operator` `any_of` o `all_of`, `field` nulo y los resultados de sus miembros en su propio `conditions`. created_at: type: string format: date-time description: >- Resultados de ejecución por regla: qué regla se activó y con qué impacto en la puntuación. provider_results: type: array items: type: object properties: uuid: type: string format: uuid provider: type: string result_type: type: string enum: - FIAT_MONITORING - WALLET_SCREENING - TRANSACTION_SCREENING - TRAVEL_RULE - NETWORK_GRAPH - CUSTOM status: type: string severity: type: string nullable: true score: type: integer summary: type: string nullable: true payload: type: object description: Payload de respuesta del proveedor sin procesar. created_at: type: string format: date-time description: >- Payloads sin procesar de los proveedores (análisis AML, analítica de blockchain, etc.). travel_rule: nullable: true allOf: - $ref: '#/components/schemas/TransactionTravelRule' description: >- Transferencia o comprobación de Travel Rule. Se rellena cuando se envió `travel_rule_details`, y también cuando Travel Rule está habilitada y la transacción se creó con `transaction_category: travelRule` (Didit inicia el intercambio por sí mismo, incluso sin `travel_rule_details`). `null` cuando no existe ninguna transferencia ni comprobación. En una transferencia entrante, los `originator_data` y `beneficiary_data` de la contraparte permanecen enmascarados (`data_masked: true`) hasta que se confirma la propiedad de la wallet. network_snapshot: type: object nullable: true description: >- Instantánea del grafo de transacciones/partes relacionadas que usa el motor de reglas. Es el `network_snapshot` enviado con la transacción o el grafo que Didit construye a partir de un análisis AML de wallet exitoso (que reemplaza al enviado). `null` cuando no existe ninguno. properties: uuid: type: string format: uuid nodes: type: array items: type: object edges: type: array items: type: object metrics: type: object remediation: type: object nullable: true description: >- Sesión de corrección que se ofrece al usuario cuando se requiere una reverificación. Ha sido reemplazada por `action_required`, que es el bloque canónico; se mantiene por compatibilidad con versiones anteriores. properties: session_id: type: string session_token: type: string url: type: string format: uri status: type: string action_required: type: object nullable: true description: >- Acción pendiente del usuario final necesaria para completar esta transacción, o null cuando no hay ninguna. Los SDK de Didit abren la acción automáticamente de forma predeterminada y actualizan la transacción cuando termina. Hay dos variantes, que se distinguen por `type`: `verification_session` (una sesión de verificación alojada creada por la acción de una regla) y `wallet_ownership` (una sesión del widget de propiedad de la wallet generada automáticamente para una transferencia de la Travel Rule que requiere probar el control de la wallet, sujeta a la configuración `auto_wallet_verification` de la Travel Rule). Cuando ambas podrían aplicarse, `wallet_ownership` tiene prioridad porque bloquea el intercambio de la Travel Rule. oneOf: - $ref: '#/components/schemas/TransactionVerificationSessionAction' - $ref: '#/components/schemas/TransactionWalletOwnershipAction' discriminator: propertyName: type mapping: verification_session: '#/components/schemas/TransactionVerificationSessionAction' wallet_ownership: '#/components/schemas/TransactionWalletOwnershipAction' cost_breakdown: type: object nullable: true description: >- Coste de esta transacción: `total_price` e `items`, uno por cargo, cada uno con `usage_type`, `price`, `details` y `created_at`. Un nuevo análisis de la misma transacción es un ítem nuevo. TravelRuleUtxoEntry: type: object description: >- Una entrada o salida de una transacción UTXO, tal como la registró la cadena. required: - address properties: address: type: string maxLength: 128 amount: type: string nullable: true description: >- Cadena decimal en la unidad propia de la moneda (BTC, no satoshis). Opcional. example: '0.0125' txid: type: string maxLength: 128 description: Opcional. La transacción que gasta una entrada. vout: type: integer nullable: true minimum: 0 description: Opcional. El índice de la salida que gasta una entrada. TransactionTravelRule: type: object description: >- La transferencia Travel Rule de una transacción, tal como la devuelven `GET /v3/transactions/{transaction_id}/`, la respuesta `201` de `POST /v3/transactions/` y cada fila de `GET /v3/transactions/`. `direction`, `rail`, `counterparty_vasp`, `delivery`, `discovery`, `reason` y `next_actions` tienen la misma forma que en `PATCH /v3/transactions/{transaction_id}/travel-rule/`, de modo que una sola lectura de una transacción indica por qué su transferencia está bloqueada y qué la hace avanzar. properties: uuid: type: string format: uuid status: type: string protocol: type: string nullable: true required: type: boolean obligations_count: type: integer originator_data: type: object description: >- Parte ordenante. En una transferencia entrante, los valores de la contraparte están enmascarados hasta que se confirma la propiedad. beneficiary_data: type: object description: >- Parte beneficiaria. En una transferencia entrante, los valores de la contraparte están enmascarados hasta que se confirma la propiedad. name_match: type: object nullable: true description: >- La comparación de nombres que decidió la transferencia (puntuación y nivel de exigencia). Null hasta que se haya ejecutado una. Los nombres comparados se enmascaran junto con las partes. data_match: $ref: '#/components/schemas/TravelRuleDataMatch' mismatched_fields: type: array items: type: string description: >- Atajo para `data_match.mismatched_fields`. Vacío cuando nada difiere. data_unmasked: $ref: '#/components/schemas/TravelRuleDataUnmasked' data_masked: type: boolean description: >- True mientras los datos personales de la contraparte están enmascarados en esta respuesta. metadata: type: object direction: type: string enum: - INBOUND - OUTBOUND description: Qué lado del intercambio representa esta transferencia. rail: type: string nullable: true description: >- La vía por la que pasó la transferencia: `INTERNAL`, `TRP`, `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` o `EMAIL` (`TEST_VASP` en una aplicación de sandbox, cuando respondió el VASP de prueba de Didit), o `null` hasta que se elige una vía. counterparty_vasp: type: object nullable: true properties: name: type: string lei: type: string dd_score: type: integer description: >- Puntuación de diligencia debida de 0 a 100, donde un valor más alto es mejor. Usa la misma escala que el directorio de VASP. dd_score_breakdown: type: object description: >- Contribuciones de cada componente a dd_score, un objeto por componente como en el directorio de VASP (jurisdiction, verification, protocol, lei, history, essentials, responsiveness), cada uno con {points, max, reason, detail}. {} hasta que se haya evaluado la contraparte. additionalProperties: type: object properties: points: type: number description: Puntos otorgados a este componente. max: type: integer description: Puntos máximos que puede otorgar este componente. reason: type: string description: Código legible por máquina del veredicto del componente. detail: type: string description: Motivo legible de los puntos asignados. dd_assessed_at: type: string format: date-time nullable: true description: >- Cuándo se ejecutó por última vez la evaluación de diligencia debida. Nulo hasta que se haya evaluado la contraparte. description: >- La entrada del directorio de la contraparte, o `null` cuando la transferencia no vincula ninguna. delivery: nullable: true allOf: - $ref: '#/components/schemas/TravelRuleDelivery' description: >- El mensaje más reciente que la transferencia debe a otra parte. `null` cuando no ha debido ninguno, por ejemplo por debajo de `threshold_amount` o para una wallet sin custodia declarada. discovery: type: array description: >- Cómo buscó Didit la contraparte, con una entrada por cada paso ejecutado. Vacío cuando no se ejecutó ningún descubrimiento, por ejemplo, en una transferencia entrante. items: $ref: '#/components/schemas/TravelRuleDiscoveryStep' reason: type: string description: >- Por qué está bloqueada una transferencia `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`; `""` para cualquier otro estado. Primero lo determina una entrega fallida, solo en `COUNTERPARTY_VASP_NOT_REACHABLE`: `email_undeliverable` (el proveedor de correo rechazó el correo de cumplimiento y no queda ninguna dirección que probar: al enviarlo, en un recordatorio o como rebote permanente notificado más tarde) o `delivery_failed` (el canal que realizaba la entrega falló de forma definitiva: un canal de red rechazó el mensaje o agotó los reintentos, un host de identidad `TRP` no respondió o el host `TRP` de la contraparte no aceptó la consulta). En caso contrario, lo determina la traza `discovery`: `awaiting_end_user` (ningún paso indicó una contraparte a la que Didit pueda llegar), `directory_match_no_route` (un paso indicó un VASP del directorio que no tiene ruta), `picked_member_without_proven_wallet` (el usuario final eligió un cliente de Didit que no ha demostrado el control de la wallet) o `no_directory_match` cuando la traza no da ningún otro motivo. Un reenvío hace avanzar la transferencia, por lo que el motivo se borra. Consulta [Por qué está bloqueada una transferencia](/es/transaction-monitoring/travel-rule#por-qué-una-transferencia-está-bloqueada). next_actions: type: array description: >- Qué hace avanzar la transferencia; `[]` para cualquier estado que no sea `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. `email_undeliverable` ofrece `update_compliance_email` y después `resend`. `delivery_failed` ofrece `resend`. Un motivo de descubrimiento ofrece `select_counterparty_vasp`, `declare_self_hosted`, `add_vasp_hint` y `resend`. items: $ref: '#/components/schemas/TravelRuleNextAction' chain_details: $ref: '#/components/schemas/TravelRuleChainDetails' TransactionVerificationSessionAction: title: Verification session type: object properties: type: type: string enum: - verification_session url: type: string format: uri description: URL de verificación alojada que se debe abrir para el usuario final. session_id: type: string format: uuid description: ID de la sesión de verificación. session_token: type: string description: >- Token de sesión que usan los SDK móviles para iniciar el flujo de forma nativa. status: type: string description: Estado de la sesión de verificación. required: - type - url TransactionWalletOwnershipAction: title: Wallet ownership type: object properties: type: type: string enum: - wallet_ownership url: type: string format: uri description: >- URL del widget alojado de propiedad de la wallet. Ábrela en un navegador real: en dispositivos móviles usa SFSafariViewController o una Chrome Custom Tab, nunca una webview integrada. widget_session_id: type: string format: uuid description: ID de sesión del widget de propiedad de la wallet. expires_at: type: string format: date-time description: Cuándo expira la sesión del widget. required: - type - url TravelRuleDataMatch: type: object nullable: true description: >- Comparación campo a campo de los datos de las partes de la transferencia con lo que la otra parte sabe del titular de la wallet. Indica campos y resultados, nunca valores, por lo que sigue siendo legible mientras los datos de la contraparte están enmascarados. Es null hasta que se realiza una comparación. properties: matched: type: boolean description: True cuando ningún campo comparado difiere. mismatched_fields: type: array items: type: string enum: - name - date_of_birth - address - account description: Los campos que difieren. fields: type: object description: >- Una entrada por campo comparado para el tipo de entidad de la parte (`name`, `date_of_birth`, `address`, `account`; una empresa no tiene `date_of_birth`). additionalProperties: type: object properties: result: type: string enum: - matched - mismatched - not_compared description: >- `not_compared` cuando la regla es `NONE` o alguna de las dos partes no tiene valor para el campo. strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY TravelRuleDataUnmasked: type: object nullable: true description: >- Registro de auditoría del momento en que se desenmascararon los datos de la contraparte. Es null mientras los datos siguen enmascarados, y en las transferencias salientes. properties: at: type: string format: date-time reason: type: string enum: - ownership_confirmed - wallet_proof - address_book_match - own_verified_wallet - inquiry_approved - known_payment_method - travel_address description: >- Qué confirmó la propiedad: ownership_confirmed (tu confirmación a través de la consola o de la API), wallet_proof (una prueba de wallet en el widget o una transferencia entrante INTERNAL; se establece al crearla), address_book_match (una wallet verificada de la libreta de direcciones), own_verified_wallet (la propia wallet verificada de tu usuario), inquiry_approved (tu aprobación de una consulta TRP entrante o de un mensaje GTR o Sygna), known_payment_method (una wallet con la que tu usuario ya pagó) o travel_address (la travel address propia de cada wallet identificó la wallet). actor: type: string description: >- Quién lo confirmó: el correo electrónico del usuario de la consola o la etiqueta de la clave de API. Vacío en una decisión automática. TravelRuleDelivery: type: object description: >- Estado del último mensaje que la transferencia debe a la otra parte. Didit contacta con la contraparte después de que la solicitud que creó o modificó la transferencia haya respondido, así que este objeto indica si ese mensaje llegó: en cola, en envío, a la espera de reintentarse tras un error, entregado o fallido. Un fallo del que la red aún puede recuperarse (sin respuesta a tiempo, conexión fallida, HTTP `408`, `429` o `5xx`) se reintenta a los 30 segundos, 2 minutos, 10 minutos, 30 minutos y 1 hora. Cuando un primer mensaje (`kind: SEND`) falla de forma definitiva, porque la red lo rechazó o porque también falló el sexto intento, la transferencia pasa a `COUNTERPARTY_VASP_NOT_REACHABLE` con `last_error` en su `timeline`; cualquier otro mensaje que falle de forma definitiva se registra en el `timeline`. El `status` de la transferencia sigue siendo la fuente de verdad del intercambio en sí. required: - kind - status - rail - attempts - last_error - next_attempt_at - delivered_at properties: kind: type: string enum: - SEND - ANSWER - TXID - CANCEL - POLL description: >- Qué transporta el mensaje. `SEND`: el primer mensaje de la transferencia a la contraparte (saliente; el canal se elige al enviarlo). `ANSWER`: tu aceptación o rechazo, que se debe a la red que lo solicitó (entrante). `TXID`: el hash de la transacción on-chain, después de que completes la transferencia. `CANCEL`: la cancelación, después de que la canceles. `POLL`: una consulta de estado a una red que la ofrece, repetida cada 5 minutos mientras la transferencia espera a la contraparte. status: type: string enum: - QUEUED - SENDING - RETRYING - DELIVERED - FAILED description: >- `QUEUED`: en espera de envío. `SENDING`: hay un intento en curso. `RETRYING`: un intento falló y el siguiente se ejecuta en `next_attempt_at`. `DELIVERED`: la otra parte aceptó el mensaje. `FAILED`: la otra parte lo rechazó, o falló el último intento. rail: type: string enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - '' description: >- La vía que transporta el mensaje. Vacía hasta que Didit elige una para un primer mensaje. attempts: type: integer minimum: 0 description: >- Intentos realizados hasta ahora para este mensaje. Un mensaje que no es una consulta de estado se intenta como máximo 6 veces. last_error: type: string description: >- El tipo de fallo que tuvo el último intento, `""` si no hubo ninguno: por ejemplo `email undeliverable`, `trp identity endpoint unreachable` o `trp transfer inquiry delivery failed`. Nunca incluye la respuesta de la propia contraparte, que permanece en el `timeline` de la transferencia. Cuando GTR responde con un error, se incluyen su propio código de estado y su mensaje. Los cuerpos de respuesta nunca se incluyen. example: email undeliverable next_attempt_at: type: string format: date-time nullable: true description: >- Fecha y hora del próximo intento mientras el mensaje está en `QUEUED` o `RETRYING`. delivered_at: type: string format: date-time nullable: true description: Fecha y hora en que el otro extremo aceptó el mensaje. TravelRuleDiscoveryStep: type: object description: >- Un paso del descubrimiento de contraparte que Didit ejecutó para una transferencia saliente, en el orden en que los ejecutó. El primer paso que identifica un VASP con una ruta finaliza la cadena. properties: step: type: string enum: - internal_address_book - wallet_attribution - network_lookup - customer_hint - end_user description: >- `internal_address_book`: otro cliente de Didit que demostró tener el control de la wallet de destino. `wallet_attribution`: la atribución de la wallet según la analítica de blockchain. `network_lookup`: una red que puede indicar qué VASP custodia la dirección. `customer_hint`: el nombre, el LEI o la jurisdicción del VASP que enviaste en `beneficiary_data`. `end_user`: la contraparte que eligió el usuario final (o tú), o la solicitud para que se elija una. outcome: type: string enum: - match - miss - skipped description: >- `match`: el paso identificó una contraparte. `miss`: se ejecutó y no encontró ninguna. `skipped`: no se pudo ejecutar, y `reason` indica el motivo. reason: type: string description: >- Motivo legible por máquina, `""` cuando hay coincidencia: `no_proven_internal_wallet`, `attribution_disabled`, `already_attributed`, `no_attributed_entity`, `directory_match_no_route`, `gtr_address_lookup_runs_on_dispatch`, `no_membership`, `network_switched_off`, `no_network_address_lookup`, `no_directory_match`, `awaiting_end_user` o `picked_member_without_proven_wallet`. vasp: type: string format: uuid nullable: true description: El VASP del directorio que indicó el paso, cuando indicó uno. rail: type: string nullable: true description: La vía que llega a esa contraparte, cuando el paso encontró una. at: type: string format: date-time TravelRuleNextAction: type: object description: >- Algo que hace avanzar una transferencia en estado `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. Consulta [Por qué una transferencia está bloqueada](/es/transaction-monitoring/travel-rule#por-qué-una-transferencia-está-bloqueada). properties: action: type: string enum: - select_counterparty_vasp - declare_self_hosted - add_vasp_hint - update_compliance_email - resend description: >- `select_counterparty_vasp`: el usuario final elige el VASP de destino en el widget de propiedad de la wallet, o haces un PATCH con `action=beneficiary_vasp`. `declare_self_hosted`: el usuario final declara en el widget que la wallet es sin custodia. `add_vasp_hint`: indica a Didit quién es la contraparte con un nombre de VASP, un LEI o una travel address (por ejemplo, una `travel_address` en la entrada de la libreta de direcciones de la wallet de destino) y vuelve a enviarla. `update_compliance_email` y `resend` son valores de `action` de `PATCH /v3/transactions/{transaction_id}/travel-rule/`: vuelve a indicar el correo electrónico de cumplimiento de la contraparte y vuelve a ejecutar el enrutamiento. url: type: string format: uri description: >- El enlace del widget de propiedad de la wallet, en `select_counterparty_vasp` y `declare_self_hosted` mientras la transferencia tiene una sesión de widget abierta. required: - action TravelRuleChainDetails: type: object description: >- Cómo identifica la cadena de la transferencia sus dos wallets, cuando no se trata simplemente de una dirección que paga a otra. Vacío (`{}`) en una transferencia de una cadena basada en cuentas (EVM, Solana, Tron), donde las dos direcciones son las wallets. La coincidencia, el enrutamiento y la libreta de direcciones leen las wallets primero de aquí. properties: chain: type: string description: >- Cadena canónica, p. ej., `BTC`, `XRP` o `LIGHTNING` para una transferencia Lightning. shape: type: string enum: - utxo - memo - lightning originator: $ref: '#/components/schemas/TravelRuleChainSide' beneficiary: $ref: '#/components/schemas/TravelRuleChainSide' utxo: type: object description: >- En una transferencia UTXO: las entradas y salidas tal como se almacenan (importes como cadenas decimales) y cómo interpretó Didit cada salida. properties: inputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' outputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' change_output_indexes: type: array items: type: integer description: Salidas que devuelven fondos a una dirección de entrada. beneficiary_output_index: type: integer nullable: true description: >- La salida que paga al beneficiario; null cuando no se pudo distinguir ninguna. lightning: type: object description: >- En una transferencia Lightning: lo que indica la solicitud de pago. Siempre `kind` (`bolt11`, `bolt12_offer`, `bolt12_invoice`, `bolt12_invoice_request`, `lnurl`, `lightning_address`, `node_id` o `unknown`); una factura BOLT11 añade `network`, `payee_node_id`, `payment_hash`, `amount_msat`, `created_at` y `expires_at`; una cadena BOLT12, `blinded_paths` y `payee_node_id`; una LNURL o una Lightning Address, su `domain`. No se resuelve nada a través de la red: la solicitud solo se decodifica. additionalProperties: true warnings: type: array items: type: string enum: - declared_originator_not_an_input - declared_beneficiary_not_an_output - beneficiary_output_ambiguous - beneficiary_output_amount_differs description: >- Incoherencias UTXO que conviene revisar: el ordenante declarado no es una entrada, el beneficiario declarado no es una salida, no se pudo distinguir una única salida del beneficiario o la salida del beneficiario paga un importe distinto del que indica la transacción. not_applicable_reason: type: string enum: - LIGHTNING_NO_PAYEE_IDENTIFIER - LIGHTNING_BOLT12_BLINDED_PAYEE - LIGHTNING_LNURL_NAMES_NO_PAYEE description: >- En una transferencia Lightning saliente cuya solicitud de pago no indica ningún beneficiario: por qué la transferencia es `NOT_APPLICABLE`. `LIGHTNING_NO_PAYEE_IDENTIFIER` (la solicitud no indica ningún nodo beneficiario o no se pudo decodificar), `LIGHTNING_BOLT12_BLINDED_PAYEE` (la oferta oculta su beneficiario tras rutas cegadas), `LIGHTNING_LNURL_NAMES_NO_PAYEE` (una LNURL indica un servicio, no un beneficiario). El mismo código abre la última entrada del `timeline` de la transferencia. TravelRuleChainSide: type: object description: >- La wallet de una de las partes tal como Didit la resolvió a partir de los datos de la cadena. properties: address: type: string description: >- La wallet. En una red con memo, la dirección clásica (una X-address de XRP se divide en su dirección clásica y su tag); en Lightning, el ID de nodo del beneficiario o la Lightning Address. memo: type: string description: >- La etiqueta de destino o memo que forma parte de la wallet; `""` si no hay ninguno. source: type: string enum: - declared - x_address - largest_input - only_non_change_output - amount_match - invoice_payee - updated description: >- Origen de la wallet: `declared` (tu solicitud), `x_address` (extraída de una X-address de XRP), `largest_input` (la dirección de entrada UTXO que más aportó), `only_non_change_output` (la única salida UTXO que no es cambio), `amount_match` (la única salida UTXO que paga el importe de la transferencia), `invoice_payee` (el beneficiario que indica una solicitud de pago Lightning), `updated` (establecida más tarde con `action: update_originator_wallet`). securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- La clave de API de tu aplicación, que encontrarás en Developers -> API keys en la Business Console. La clave principal tiene acceso completo. Una clave con nombre puede tener un alcance limitado: ninguno, lectura o escritura por recurso, limitada a algunos flujos o a sesiones aprobadas, a una lista de direcciones IP y a una fecha de caducidad. 401 significa que la clave es incorrecta, se revocó o expiró; 403 significa que no se envió ninguna clave, que la clave no tiene acceso a este recurso o acción, o que la solicitud provino de una dirección fuera de su lista de IP; 404 en una ruta de sesión significa que la sesión está fuera de los flujos o estados de la clave. Una clave sin acceso a contenido multimedia recibe las URL de imágenes, videos y PDF como null, y una clave sin permiso de escritura en sesiones recibe los enlaces y tokens de sesión como null. Consulta https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.