> ## 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 sesión: inicia una verificación KYC o KYB
> POST /v3/session/ inicia una sesión de verificación en Didit: endpoint unificado KYC + KYB, pago por uso, inferencia <2 s y $10 gratis al mes.
Prompt para crear una sesión
Copiar el prompt al portapapeles
\
\`Create a verification session via Didit's REST API.
Endpoint:
POST https://verification.didit.me/v3/session/
Authentication:
Use the x-api-key header with your Didit API key. The workflow's type (KYC or KYB) determines which kind of session is created — there is no separate endpoint for KYB.
Request body:
\- workflow_id (string, UUID, required) — Stable workflow UUID from /v3/workflows/. KYC workflows create User Verification sessions; KYB workflows create Business Verification sessions.
\- vendor_data (string, optional) — Your stable identifier for the entity (user or business). Strongly recommended: it binds the session to a User or Business entity and is used for duplicate detection across sessions.
\- callback (string, URL, optional): Where the hosted flow redirects the user when finished. Didit appends ?verificationSessionId={session_id}&status={status}. Falls back to the workflow default. When the application has allowed domains (allowed_domains on PATCH /v3/webhook/), an http or https callback must be on one of those origins (same scheme, host and port), otherwise creation fails with 400 on callback: "callback must be on one of the application's allowed domains: https://app.example.com". Custom URL schemes (app deep links such as myapp://) are always accepted. A workflow-default callback outside the allowed domains is not used for the redirect.
\- callback_method (string, optional, default "initiator") — One of "initiator", "completer", "both". Use "both" if the callback sometimes fails to fire.
\- metadata (object, optional) — Arbitrary JSON echoed back in responses and webhooks. Not shown to the user.
\- tags (array of strings, optional): Tags added to the session when it is created, by name, for example ["VIP", "ONBOARDING Q4"]. Up to 10, each up to 50 characters. Names are case-insensitive and stored in upper case; a name that does not exist yet in the application is created as a new tag. The tags show on the session in the console, where you can filter by them, and come back in the create response.
\- language (string, optional) — ISO 639-1 code for the verification UI (en, es, fr, de, pt, etc.). Defaults to browser detection.
\- contact_details (object, optional) — { email, send_notification_emails, email_lang, phone }. Pre-fills phone/email steps and (optionally) sends notification emails.
\- expected_details (object, optional) — Expected first_name, last_name, date_of_birth, nationality (ISO-3), id_country (ISO-3), expected_document_types (e.g. ["P","ID","DL","RP","SSC"]). Mismatches surface as decision warnings. For Business Verification (KYB) workflows, pass the business fields instead — company_name, registry_country, registration_number — to pre-fill the company registry search; registry_country is ISO 3166-1 alpha-2 and can include the state for state-level registries (e.g. "US-CA"), same format as the KYB Registry Search country_code. Person-level fields are ignored on KYB sessions.
\- portrait_image (string, base64, conditional) — Reference face for Biometric Authentication workflows (and graph workflows where Face Match runs before ID Verification). Max 2MB; JPEG, PNG, WebP, or TIFF. Optional when the vendor_data user already has a stored face: Didit reuses it automatically (approved liveness face, then ePassport chip photo, then ID document portrait, then a manually enrolled profile face). If omitted and no stored face exists, creation fails with 400. Ignored for other workflow types.
\- multi_account_segment (string, optional, max 64 chars) — Duplicate-detection realm inside your own organization. Duplicate face checks only compare this session against other sessions carrying the same segment, so an organization that runs separate account bases (personal vs business, or one per sub-client) does not see a person who legitimately holds one account in each reported as a duplicate. Omit it to use the single default realm — which is what every session uses today, so existing integrations are unaffected. Blocklist and allowlist matching ignore this field: a blocklisted face stays blocklisted in every segment.
\- sandbox_scenario (string, optional, sandbox applications only): Scenario slug from the sandbox catalog (GET /v1/sandbox/scenarios/). Expands the scenario's bundled magic values onto contact_details/expected_details so the session reproduces that outcome. Rejected with 400 on live applications. You can also arm or re-arm a scenario after create, as long as the session is still Not Started, via POST /v3/session/{session_id}/sandbox/arm/. See /integration/sandbox-testing.
\- user_state (string, optional, max 16 chars): Where the person lives, when you know it: an ISO 3166-2 code (US-IL) or a US state code or name (IL, Illinois). In Auto consent mode, Illinois, Texas or Colorado makes the flow ask for explicit biometric consent before the first face capture. 400 on an unrecognized value.
\- biometric_consent (object, optional): Consent you already collected: { given_at (ISO 8601, not in the future), text_version (max 64 chars) }. The flow does not ask again; the decision records it as given with trigger customer_collected.
\- sign (object, optional): { documents: [ { title, file_name, content_base64, fields } ], field_values: { : value } }. documents is for a workflow whose E-signature step takes documents from the session (signature_documents_source "session" or "both"). file_name ends in .pdf or .docx; content_base64 is the file in base64. Up to 20 documents and 50 MB in total; a PDF up to 20 MB and 100 pages, without a password, scripts or attachments; a Word file (.docx) up to 20 MB, converted to PDF while the request runs, at most 5 per session. fields is optional (up to 200 per document): signature, initials, full_name, date_signed, text, checkbox, email or data fields, each with a key unique in its document (^[a-z][a-z0-9_]{0,63}$), placed by page, x, y, width and height, or by anchor text ({ text, occurrence, offset_x, offset_y, width, height }). role defaults to the step's signer. field_values fills the fields whose prefill is "api.", on workflow and session documents alike: strings of 1 to 500 characters, booleans for checkboxes. 400 when the workflow has no E-signature step, takes workflow documents only and you sent documents, or needs session documents you didn't send; field_anchor_not_found, field_value_unknown, field_value_missing or field_value_invalid for fields and values. See /core-technology/electronic-signature/overview.
Idempotency:
Within one application, only one non-finished session can exist per (workflow_id, vendor_data). Calling create again with the same pair returns the existing session (and updates its callback + metadata, and adds any tags you send) instead of creating a duplicate. If you send sign again, its documents, fields and field values must be identical (same order, titles, file names, content, fields and values), or the call returns 400 { "sign": "signature_document_changed" }.
curl example:
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{
"workflow_id": "",
"vendor_data": "user-42",
"callback": "https://yourapp.com/callback",
"metadata": { "plan": "premium" }
}'
Response (201 Created) — keys you must handle:
\- session_id (UUID) — use this on every subsequent /v3/session/{session_id}/... call.
\- session_kind ("user" | "business") — discriminator, dispatch on this.
\- session_number (int) — human-friendly per-application sequence.
\- session_token (string) — short-lived, embedded in the hosted URL. Treat as secret.
\- url (string) — hosted verification URL. Redirect the end user here. (Field name is "url", NOT "verification_url".)
\- status (string) — newly created sessions return "Not Started".
\- workflow_id, workflow_version, vendor_data, metadata, callback — echoed back.
See /reference/data-models for the full schema.
Failure modes:
\- 400 — { "workflow_id": ["Invalid workflow_id."] } when the UUID is unknown.
\- 400 — { "vendor_data": ["This user or business has been blocked and cannot create new verification sessions."] } when blocklisted.
\- 400 — { "detail": "You don't have enough credits to perform this request. Please top up at https://business.didit.me" } when out of credits.
\- 400 — { "portrait_image": "No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first." } on a Face Match workflow when portrait_image is omitted and the vendor_data user has no stored face.
\- 401 — invalid or missing API key.
\- 403 — { "detail": "You do not have permission to perform this action." } when the key lacks write:sessions.
\- 429 — rate limited (600 successful calls/minute per token/IP). Honour Retry-After.
Disclosure & consent:
This endpoint generates a URL — it does not record that you obtained user consent. Show your privacy notice and any biometric-specific consent in your own UX before redirecting to the hosted flow.
For people covered by Illinois, Texas or Colorado law, the hosted flow and native SDK 4.10.0 or later can ask for explicit biometric consent before the selfie; native SDKs below 4.10.0 cannot show that step. See /getting-started/biometric-consent.
Next step:
After the user finishes (status changes to Approved / Declined / In Review), call GET https://verification.didit.me/v3/session/{session_id}/decision/ for the full decision — see /sessions-api/retrieve-session.
For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`
\
Pegar en
## Compatibilidad con KYC y KYBUn único endpoint crea tanto sesiones de Verificación de usuarios como de Verificación de empresas. El **tipo del flujo de verificación (workflow)** determina cuál se crea:- Si pasas el `workflow_id` de un **Flujo de trabajo KYC**, se crea una sesión de Verificación de usuarios (KYC). La respuesta incluye `session_kind: "user"`.
- Si pasas el `workflow_id` de un **Flujo de trabajo KYB**, se crea una sesión de Verificación de empresas (KYB). La respuesta incluye `session_kind: "business"`.Configura los flujos en la consola, en *Workflows → Create workflow*. Un flujo se define como KYC o KYB al crearlo; después no puedes cambiar su tipo.## Ejemplos> [tab] Verificación de usuarios (KYC)
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "workflow_id": "YOUR_KYC_WORKFLOW_ID",
> "vendor_data": "user-42",
> "callback": "https://yourapp.com/callback"
> }'
> ```
>
> **Respuesta (201 Created):**
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
> "session_kind": "user",
> "session_number": 1024,
> "session_token": "...",
> "url": "https://verify.didit.me/session/...",
> "status": "Not Started",
> "workflow_id": "YOUR_KYC_WORKFLOW_ID",
> "vendor_data": "user-42"
> }
> ```> [tab] Verificación de empresas (KYB)
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "workflow_id": "YOUR_KYB_WORKFLOW_ID",
> "vendor_data": "biz-acme-001",
> "callback": "https://yourapp.com/callback"
> }'
> ```
>
> **Respuesta (201 Created):**
>
> ```json theme={null}
> {
> "session_id": "bs-01HJX1...",
> "session_kind": "business",
> "session_number": 89,
> "session_token": "...",
> "url": "https://verify.didit.me/session/...",
> "status": "Not Started",
> "workflow_id": "YOUR_KYB_WORKFLOW_ID",
> "vendor_data": "biz-acme-001"
> }
> ```## Documentos de firma electrónicaCuando el flujo tiene un paso de [Firma electrónica](https://docs.didit.me/es/core-technology/electronic-signature/overview.md) que toma los documentos de la sesión (`signature_documents_source` con el valor `session` o `both`), envíalos en `sign.documents`. Cada documento es el archivo en base64, así que Didit nunca tiene que descargarlo desde una URL.```json theme={null}
{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-42",
"sign": {
"documents": [
{
"title": "Loan agreement",
"file_name": "loan-agreement.pdf",
"content_base64": "JVBERi0xLjcKJc...",
"fields": [
{ "key": "borrower_signature", "type": "signature", "label": "Borrower signature", "page": 3, "x": 0.1, "y": 0.78, "width": 0.32, "height": 0.06 },
{ "key": "date_signed", "type": "date_signed", "label": "Date", "page": 3, "x": 0.6, "y": 0.8, "width": 0.2, "height": 0.03, "date_format": "DD/MM/YYYY" },
{ "key": "loan_amount", "type": "data", "label": "Loan amount", "page": 1, "x": 0.34, "y": 0.31, "width": 0.3, "height": 0.03, "prefill": "api.loan_amount" },
{ "key": "initials", "type": "initials", "anchor": { "text": "[[initials]]", "occurrence": "all", "offset_x": 0, "offset_y": -0.005, "width": 0.12, "height": 0.04 } }
]
}
],
"field_values": { "loan_amount": "12,000 EUR" }
}
}
```| Campo | Reglas |
| - | - |
| `title` | Se muestra al firmante. De 1 a 255 caracteres. Por defecto, `file_name`. |
| `file_name` | Obligatorio. Termina en `.pdf` o `.docx`. De 1 a 255 caracteres. |
| `content_base64` | Obligatorio. Un PDF puede tener hasta 20 MB y 100 páginas, sin contraseña, scripts ni archivos adjuntos. Un archivo de Word puede tener hasta 20 MB y se convierte a PDF durante la solicitud, en un máximo de 25 segundos; el PDF resultante tiene entonces los mismos límites. Hasta 5 archivos de Word por sesión. |
| `fields` | Opcional. Hasta 200 [campos](https://docs.didit.me/es/core-technology/electronic-signature/overview.md#campos-en-el-documento) que colocar en el documento, con la estructura de campo sin `id`. Cada campo necesita una `key` y un `type`, y una posición (`page`, `x`, `y`, `width` y `height`) o un [`anchor`](#colocar-campos-por-texto-de-anclaje). `role` toma por defecto el firmante del paso, y `required` y `label` toman su valor por defecto según el tipo. Didit establece `position` según dónde se encuentre el campo. Las páginas y posiciones se refieren al PDF o, en el caso de un archivo de Word, al PDF convertido. |Sin `fields`, el firmante lee el documento y lo acepta.### Colocar campos por texto de anclajeEn lugar de una posición, un campo puede llevar un `anchor`: un fragmento de texto del documento que marca dónde va el campo. Los anclajes son adecuados para documentos que generas para cada sesión, por ejemplo a partir de una plantilla de Word. Para los documentos del flujo, coloca los campos en la consola.| Propiedad de `anchor` | Reglas |
| - | - |
| `text` | De 1 a 64 caracteres, que se buscan en el texto del documento. En un archivo de Word, en el PDF convertido. |
| `occurrence` | `first` (por defecto) coloca un campo en la primera coincidencia. `all` coloca un campo por coincidencia, y las claves posteriores a la primera reciben `_2`, `_3` y así sucesivamente. |
| `offset_x`, `offset_y` | Fracciones de la página. La esquina superior izquierda del campo es la esquina superior izquierda del texto de anclaje más estos desplazamientos. |
| `width`, `height` | El tamaño del campo, como fracciones de la página. |Si el texto no está en el documento, la llamada devuelve `400` con `field_anchor_not_found` y la clave del campo. Didit no elimina el texto de anclaje del PDF, así que escríbelo del mismo color que el fondo de la página.### Valores de campos`sign.field_values` establece el valor de cada campo cuyo `prefill` sea `api.`, tanto en los documentos del flujo como en los de la sesión. Es un objeto cuyas claves son esos nombres ``. Los valores son cadenas de 1 a 500 caracteres para los campos `text` y `data`, y booleanos para un `checkbox`.```json theme={null}
{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-42",
"sign": {
"field_values": { "credit_limit": "3,000 EUR", "monthly_fee": "4.90 EUR" }
}
}
```| Error (`400`) | Cuándo |
| - | - |
| `field_value_unknown` | Una clave que ningún campo usa. |
| `field_value_missing` | Un campo obligatorio cuyo `api.` no tiene valor. |
| `field_value_invalid` | Un valor que no supera la [validación](https://docs.didit.me/es/core-technology/electronic-signature/overview.md#validación) de su campo. |### Errores y llamadas repetidasUna sesión admite hasta 20 documentos y 50 MB en total. La llamada devuelve `400` con un error `sign` cuando:- El flujo no tiene un paso de Firma electrónica.
- Enviaste `sign.documents` y el paso solo admite documentos del flujo.
- El paso solo admite documentos de la sesión y no enviaste ninguno, o no tiene documentos del flujo y no enviaste ninguno.
- Un documento es demasiado grande, no es base64 válido o no es un archivo compatible.
- Un archivo de Word se rechaza con `signature_document_not_supported`, o no se puede convertir y devuelve `signature_document_conversion_failed`, en ambos casos con el `reason` indicado en [Archivos compatibles](https://docs.didit.me/es/core-technology/electronic-signature/overview.md#archivos-admitidos).
- Un campo no es válido, no se encuentra su anclaje (`field_anchor_not_found`) o se rechaza un [valor de campo](#valores-de-campos).Volver a invocar la operación de creación con el mismo `workflow_id` y `vendor_data` devuelve la sesión pendiente. Si esa llamada envía `sign`, sus documentos, campos y valores de campos deben ser idénticos a los de la primera llamada (mismo orden, títulos, nombres de archivo, contenido, campos y valores). Cualquier diferencia devuelve `400` con `{"sign": "signature_document_changed"}`: usa otro `vendor_data` o espera a que termine la sesión pendiente.## Pruebas con escenarios de sandboxEn una aplicación en modo sandbox, pasa `sandbox_scenario` para precargar un resultado determinista (aprobación, un rechazo concreto o un escenario En revisión) sin tocar proveedores reales ni tu saldo:```json theme={null}
{
"workflow_id": "YOUR_SANDBOX_WORKFLOW_ID",
"sandbox_scenario": "decline_document_expired"
}
````sandbox_scenario` se rechaza con `400` en las aplicaciones de producción. Si aún no conoces el resultado al crear la sesión, puedes activarlo (o reactivarlo) más tarde mediante `POST /v3/session/{session_id}/sandbox/arm/`, siempre que la sesión siga en `Not Started`: el selector de escenarios previo al flujo alojado usa este mismo endpoint. Consulta [Sandbox y datos de prueba](https://docs.didit.me/es/integration/sandbox-testing.md) para ver el catálogo completo de escenarios, el registro de valores mágicos y la estructura de solicitud y respuesta del endpoint de activación.## `vendor_data` vincula la sesión a una entidad- En los flujos KYC: se vincula a una [entidad de usuario](https://docs.didit.me/es/entities/users/overview.md). Si el usuario no existe, se crea automáticamente.
- En los flujos KYB: se vincula a una [entidad de empresa](https://docs.didit.me/es/entities/businesses/overview.md). Se crea automáticamente si es nueva.Más información en [vinculación de vendor data](https://docs.didit.me/es/entities/vendor-data-linking.md).## Consentimiento biométrico en Illinois, Texas y ColoradoEl flujo alojado y el SDK nativo 4.10.0 o posterior pueden mostrar un paso de consentimiento biométrico explícito antes de la primera captura facial, según el modo de consentimiento de la aplicación y el lugar donde se encuentre la persona. Dos campos opcionales intervienen en esa decisión:- `user_state`: dónde reside la persona, si lo sabes (`US-IL`, `IL` o `Illinois`). En el modo Auto, si reside en un estado sujeto a esta normativa, el flujo solicita el consentimiento.
- `biometric_consent`: un objeto con `given_at` y `text_version`, para el consentimiento que ya hayas recopilado. El flujo no vuelve a solicitarlo.Los SDK nativos anteriores a la 4.10.0 no pueden mostrar este paso: sus sesiones funcionan como hasta ahora y la decisión indica que el consentimiento no se recopiló. Consulta [Consentimiento biométrico](https://docs.didit.me/es/getting-started/biometric-consent.md).## Importante: la información al usuario y el consentimiento siguen siendo responsabilidad de tu producto`Create Session` genera una URL de verificación y un token de sesión. Por sí solo, **no** demuestra que hayas mostrado al usuario la información requerida ni que hayas obtenido el consentimiento necesario para tu caso de uso concreto.Si inicias una sesión de Didit desde tu propia aplicación, sitio web, wrapper de SDK o flujo de marca blanca, deberías gestionar los aspectos legales en tu propia experiencia de usuario antes de que el usuario comience la captura.## Lista de comprobación recomendada antes de la verificación1. Informa al usuario de que **tu empresa** solicita la verificación y de que **Didit** es el proveedor / encargado del tratamiento que impulsa el flujo.
2. Incluye un enlace a **tu aviso de privacidad** y a cualquier término legal del responsable del tratamiento que se aplique al proceso.
3. Incluye un enlace al [Aviso de privacidad de verificación](https://didit.me/terms/verification-privacy-notice) y a los [Términos para usuarios finales de verificación de identidad](https://didit.me/terms/identity-verification) de Didit.
4. Si tu flujo incluye captura de documentos, captura de selfie, prueba de vida o biometría, recopila un **consentimiento afirmativo explícito** siempre que la legislación aplicable o tu posición legal lo exijan.
5. Si usas una interfaz personalizada, un dominio personalizado o un proceso solo por API, muestra esta información en tu propio producto antes de enviar al usuario al flujo de Didit.
6. Conserva tu propio registro del texto del aviso / consentimiento, la marca de tiempo y los metadatos relacionados si tu equipo legal requiere un registro de auditoría.> [!WARNING]
>
> Los requisitos legales varían según la jurisdicción. La marca blanca no elimina el papel de Didit en el flujo de verificación. Revisa tu implementación con asesoría legal antes del lanzamiento si operas en jurisdicciones con normas específicas sobre biometría.
## OpenAPI
````yaml es/openapi-25.json POST /v3/session/
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/session/:
post:
tags:
- Sessions
summary: Crear una sesión de verificación
description: >-
Crea una sesión de Verificación de usuarios (KYC) o de Verificación de
empresas (KYB) y recibe una `url` de verificación alojada y un
`session_token` para redirigir a tu usuario final o integrarla en tu
aplicación. El `workflow_id` determina qué pasos de verificación se
ejecutan y si la sesión es KYC o KYB.
Llama a este endpoint desde tu backend (nunca desde el navegador, ya que
la clave de API es secreta) cada vez que necesites verificar a un
usuario o una empresa: en el registro, antes de una acción sensible o
cuando se requiera una reverificación. Requisitos previos: un flujo de
verificación (workflow) publicado (creado en la página
[Workflows](https://docs.didit.me/es/console/workflows) de la consola) y
una clave de API de la aplicación con créditos disponibles. Las
aplicaciones sandbox omiten la comprobación de créditos.
**Idempotencia:** si se proporciona `vendor_data` y ya existe una sesión
sin finalizar (`Not Started`, `In Progress`, `Resubmitted` o `Awaiting
User`) con el mismo `vendor_data` en la **versión publicada más reciente
actual** del flujo (y esa sesión ya tiene una URL de verificación
alojada), se devuelve la sesión existente (igualmente con `201`) en
lugar de crear un duplicado, con su `callback` y su `metadata`
actualizados a los nuevos valores proporcionados. Una sesión sin
finalizar creada en una versión anterior del flujo (que se haya vuelto a
publicar desde entonces) **no** se reutiliza; en su lugar, se crea una
nueva sesión fijada a la versión publicada más reciente. Las sesiones en
estado `Approved`, `Declined`, `In Review`, `Expired`, `Abandoned` o
`Kyc Expired` nunca se reutilizan.
**Efectos secundarios:** se genera y almacena la URL de verificación
alojada; si `contact_details.send_notification_emails` es `true` y se
proporciona un correo electrónico, se envía un correo de invitación a la
verificación. La sesión expira una vez transcurrido el tiempo de
expiración de sesión configurado en el flujo. En los flujos KYB, se
ignoran `contact_details.phone` y `expected_details`.
operationId: post_v3_session_create
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- workflow_id
properties:
workflow_id:
type: string
format: uuid
description: >-
Identificador estable del flujo de verificación (workflow)
que define qué pasos de verificación ejecutará la sesión.
Los flujos se crean y gestionan en la página
[Workflows](/es/console/workflows) de la consola. El
`workflow_id` también determina de forma implícita si la
sesión es de KYC o de KYB.
example: 11111111-2222-3333-4444-555555555555
x-readme-id: '0.0'
vendor_data:
type: string
description: >-
Un identificador único del usuario que se verifica, como un
UUID, un correo electrónico o un ID de usuario interno. Este
campo se usa para: (1) **Agrupación de usuarios**: las
sesiones con el mismo vendor_data se vinculan al mismo
perfil de usuario en la pestaña Users. (2) **Detección de
duplicados entre sesiones**: al buscar rostros, documentos,
números de teléfono, correos electrónicos, direcciones IP o
huellas de dispositivo duplicados, las sesiones con el mismo
vendor_data se tratan como el mismo usuario y se excluyen de
las coincidencias. Sin vendor_data, cada sesión se trata
como un usuario único y se muestran todos los posibles
duplicados. Recomendamos encarecidamente proporcionar
siempre un vendor_data para reducir el ruido en la detección
de duplicados.
example: user-123
x-readme-id: '0.1'
multi_account_segment:
type: string
maxLength: 64
description: >-
Ámbito opcional de detección de duplicados dentro de tu
organización. Las comprobaciones de rostro duplicado
comparan esta sesión solo con otras sesiones que llevan el
mismo segmento, de modo que las bases de cuentas separadas
(cuentas personales y de empresa, o una por cada subcliente
B2B) no marcan a una persona que legítimamente tiene una
cuenta en cada una. Omítelo para usar el ámbito
predeterminado único, que es el que usan hoy todas las
sesiones. La coincidencia con la lista de bloqueo y la lista
de permitidos ignora este campo.
example: business-accounts
callback:
type: string
description: >-
URL a la que se redirige al usuario cuando finaliza la
verificación. Didit añade automáticamente
`verificationSessionId` y `status` (Approved, Declined, In
Review) como parámetros de consulta. Se admiten esquemas de
URL personalizados (p. ej., `myapp://`) para callbacks en
aplicaciones móviles. Si se omite, se usa el `callback_url`
predeterminado del flujo. Cuando la aplicación tiene
dominios permitidos (`allowed_domains` en `PATCH
/v3/webhook/`), un callback `http` o `https` debe pertenecer
a uno de esos orígenes (mismo esquema, host y puerto); de lo
contrario, la solicitud falla con un error 400 en
`callback`: `callback must be on one of the application's
allowed domains: https://app.example.com`. Los esquemas de
URL personalizados siempre se aceptan.
example: https://example.com/verification/callback
x-readme-id: '0.2'
callback_method:
type: string
description: >-
Determina qué dispositivo debe gestionar la redirección a la
URL de callback proporcionada. Usa `initiator` para
redirigir solo el dispositivo que inició el flujo,
`completer` para el dispositivo que lo finaliza, o `both`
para que cualquiera de los dos dispositivos pueda activar el
callback. Si notas que el callback no se activa de forma
fiable, te recomendamos establecer este valor en `both`.
enum:
- initiator
- completer
- both
default: initiator
example: both
x-readme-id: '0.3'
metadata:
description: >-
JSON arbitrario que se guarda con la sesión y se devuelve en
la respuesta y en los webhooks. Se acepta cualquier valor
JSON (objeto, cadena, número, array), pero se recomienda un
objeto JSON de pares clave/valor. No se muestra al usuario
final. Úsalo para pasar tus propios ids de correlación,
variantes A/B o contexto de negocio.
example:
user_type: premium
account_id: ABC123
x-readme-id: '0.4'
tags:
type: array
items:
type: string
maxLength: 50
maxItems: 10
description: >-
Etiquetas que se añaden a la sesión al crearla, por nombre.
Hasta 10, cada una de hasta 50 caracteres. Los nombres no
distinguen entre mayúsculas y minúsculas y se almacenan en
mayúsculas. Un nombre que todavía no existe en la aplicación
se crea como una etiqueta nueva. Las etiquetas aparecen en
la sesión en la consola, donde puedes filtrar por ellas.
example:
- VIP
- ONBOARDING Q4
language:
type: string
description: >-
Código de idioma (ISO 639-1) para la interfaz del proceso de
verificación. Controla el idioma que ve el usuario final
durante la verificación. Si no se proporciona, se detecta y
se usa automáticamente el idioma del navegador. Consulta
todos los idiomas admitidos
[aquí](/es/integration/supported-languages).
enum:
- en
- ar
- bg
- bn
- bs
- ca
- cnr
- cs
- da
- de
- el
- es
- et
- fa
- fi
- fr
- he
- hi
- hr
- hu
- hy
- id
- it
- ja
- ka
- kk
- ko
- ky
- lt
- lv
- mk
- mn
- ms
- nl
- 'no'
- pl
- pt-BR
- pt
- ro
- ru
- sk
- sl
- so
- sq
- sr
- sv
- th
- tr
- uk
- uz
- vi
- zh-CN
- zh-TW
- zh
example: en
x-readme-id: '0.5'
contact_details:
type: object
description: >-
Información de contacto del usuario que puede usarse para
notificaciones, para rellenar previamente los formularios de
verificación y para la verificación de teléfono. Incluye la
dirección de correo electrónico, el idioma preferido para
las comunicaciones y el número de teléfono.
example:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
properties:
email:
type: string
format: email
description: >-
Dirección de correo electrónico del usuario (p. ej.,
"john.doe@example.com") que se usará durante el paso de
[Verificación de correo
electrónico](/es/core-technology/email-verification/overview).
Si no se proporciona, el usuario debe indicarla durante
el flujo de verificación.
example: john.doe@example.com
x-readme-id: '1.0'
send_notification_emails:
type: boolean
default: false
description: >-
Si es true y se proporciona un correo electrónico, Didit
envía de forma asíncrona el correo inicial "Verifica tu
identidad" al crear la sesión de Verificación de
usuarios (KYC) o Verificación de empresas (KYB). Didit
también envía a la dirección de correo electrónico
proporcionada notificaciones del estado de la
verificación de las sesiones que requieren revisión
manual (p. ej., de 'In Review' a 'Approved' o
'Declined'). Así los usuarios pueden volver a tu
aplicación una vez completada su verificación. Si tienes
activada la marca blanca para la sesión, el correo
enviado será de marca blanca.
example: true
x-readme-id: '1.1'
email_lang:
type: string
description: >-
Código de idioma (ISO 639-1) para las notificaciones por
correo electrónico. Controla el idioma de todas las
comunicaciones por correo electrónico (p. ej., "en",
"es", "fr"). No hay un valor predeterminado almacenado:
si se omite, el correo de invitación a la verificación
usa inglés (`en`) en el momento del envío. El enum
siguiente es una instantánea; la fuente de verdad
actualizada de los valores aceptados es la documentación
de [idiomas
admitidos](/es/integration/supported-languages).
Consúltala siempre antes de depender de un código
concreto.
enum:
- en
- ar
- bg
- bn
- bs
- ca
- cnr
- cs
- da
- de
- el
- es
- et
- fa
- fi
- fr
- he
- hi
- hr
- hu
- hy
- id
- it
- ja
- ka
- kk
- ko
- ky
- lt
- lv
- mk
- mn
- ms
- nl
- 'no'
- pl
- pt-BR
- pt
- ro
- ru
- sk
- sl
- so
- sq
- sr
- sv
- th
- tr
- uk
- uz
- vi
- zh-CN
- zh-TW
- zh
example: en
x-readme-id: '1.2'
phone:
type: string
description: >-
Número de teléfono en formato E.164 (p. ej.,
"+14155552671") que se usará en el paso de [Verificación
de
teléfono](/es/core-technology/phone-verification/overview).
Si no se indica, el usuario debe introducirlo durante el
flujo de verificación. Se ignora en los flujos de
Verificación de empresas (KYB). **Importante:** este
número de teléfono solo se impone si es un número E.164
válido. Si el número indicado no es válido o no se puede
interpretar, se ignorará y el usuario podrá introducir
cualquier número de teléfono válido durante el paso de
Verificación de teléfono.
example: '+14155552671'
x-readme-id: '1.3'
x-readme-id: '0.4'
expected_details:
type: object
description: >-
Datos esperados del usuario que se usan para la validación
cruzada con los datos extraídos del documento de identidad
del usuario, de la Prueba de domicilio y de otros pasos de
verificación. Las discrepancias se muestran como
advertencias en la decisión; algunos campos (p. ej.,
`id_country`, `expected_document_types`) también modifican
el flujo que ve el usuario. En los flujos de Verificación de
empresas (KYB) solo se usan los campos de la empresa
(`company_name`, `registry_country`, `registration_number`),
que rellenan previamente la búsqueda en el registro de
empresas para el usuario, y se ignoran todos los campos de
la persona.
example:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
nationality: USA
id_country: USA
expected_document_types:
- P
- ID
properties:
first_name:
type: string
description: >-
Nombre del usuario. Por ejemplo, `John`. La comparación
es aproximada (fuzzy) y puedes ajustar su rigor
configurando el umbral de puntuación de coincidencia del
nombre en la consola, tanto para los flujos de documento
de identidad como para los de prueba de domicilio.
example: John
x-readme-id: '1.0'
last_name:
type: string
description: >-
Apellido del usuario. Por ejemplo, `Doe`. La comparación
es aproximada (fuzzy) y puedes ajustar su rigor
configurando el umbral de puntuación de coincidencia del
nombre en la consola, tanto para los flujos de documento
de identidad como para los de prueba de domicilio.
example: Doe
x-readme-id: '1.1'
date_of_birth:
type: string
format: date
description: >-
Fecha de nacimiento del usuario con el formato
YYYY-MM-DD. Por ejemplo, `1990-05-15`.
example: '1990-05-15'
x-readme-id: '1.2'
gender:
type: string
nullable: true
enum:
- M
- F
default: null
description: Género del usuario. Debe ser 'M', 'F' o null.
example: M
x-readme-id: '1.3'
nationality:
type: string
description: >-
Código de país ISO 3166-1 alpha-3 que representa el país
de origen del solicitante. Por ejemplo, `USA`. Consulta
la [lista completa de códigos de país
admitidos](https://docs.didit.me/es/core-technology/id-verification/supported-documents-id-verification#documentos-admitidos-por-país).
example: USA
x-readme-id: '1.4'
country:
type: string
description: >-
Código de país ISO 3166-1 alpha-3 que se usa como valor
de respaldo en las comprobaciones de discrepancia de
país tanto de Verificación de identidad como de Prueba
de domicilio. Es obligatorio cuando se proporciona
`address` y no se ha definido ni `id_country` ni
`poa_country`.
example: USA
x-readme-id: 1.4.1
id_country:
type: string
description: >-
Código de país ISO 3166-1 alpha-3 que representa el país
esperado del documento de identidad del solicitante, que
puede diferir de la nacionalidad. Por ejemplo, `GBR`.
Tiene prioridad sobre `country` en las comprobaciones de
discrepancia de país de la verificación de identidad.
Consulta la [lista completa de códigos de país
admitidos](https://docs.didit.me/es/core-technology/id-verification/supported-documents-id-verification#documentos-admitidos-por-país).
example: GBR
x-readme-id: '1.5'
poa_country:
type: string
description: >-
Código de país ISO 3166-1 alpha-3 que representa el país
esperado del documento de prueba de domicilio. Por
ejemplo, `USA`. Tiene prioridad sobre `country` en las
comprobaciones de discrepancia de país de la prueba de
domicilio. Consulta la [lista completa de códigos de
país
admitidos](https://docs.didit.me/es/core-technology/id-verification/supported-documents-id-verification#documentos-admitidos-por-país).
example: USA
x-readme-id: 1.5.1
address:
type: string
description: >-
La dirección en un formato legible, con toda la
información posible. Por ejemplo, `123 Main St, San
Francisco, CA 94105, USA`. Si la proporcionas, también
debes pasar `country` o `poa_country`; de lo contrario,
la solicitud falla con `400`.
example: 123 Main St, San Francisco, CA 94105, USA
x-readme-id: '1.6'
identification_number:
type: string
description: >-
El número de documento, número personal o número fiscal
del usuario. Por ejemplo, `123456789`.
example: '123456789'
x-readme-id: '1.7'
ip_address:
type: string
description: >-
Dirección IP esperada para la sesión, en formato IPv4 o
IPv6. Si la dirección IP real difiere de este valor, se
registrará una advertencia. Por ejemplo, `192.168.1.100`
o `2001:db8::1`.
example: 192.168.1.100
x-readme-id: '1.8'
expected_document_types:
type: array
description: >-
Restringe los tipos de documento que el usuario puede
presentar durante el paso de verificación de identidad
(OCR). Cuando se define, la pantalla de selección de
documentos solo muestra los tipos solicitados y el
`documents_allowed` devuelto se filtra en consecuencia.
Los valores no distinguen mayúsculas y minúsculas y se
eliminan los duplicados; los valores desconocidos se
rechazan con `400`. Códigos permitidos: `P` (pasaporte),
`ID` (documento nacional de identidad), `DL` (licencia
de conducir), `RP` (permiso de residencia), `HIC`
(tarjeta de seguro médico), `TC` (tarjeta fiscal), `SSC`
(tarjeta de seguridad social).
items:
type: string
enum:
- P
- ID
- DL
- RP
- HIC
- TC
- SSC
example:
- P
- ID
x-readme-id: '1.9'
company_name:
type: string
maxLength: 255
description: >-
Razón social esperada de la empresa que se verifica. Por
ejemplo, `Tesco PLC`. Rellena previamente el campo del
nombre de la empresa en la búsqueda del registro en los
flujos de Verificación de empresas (KYB); cuando también
se proporciona `registration_number`, la consulta al
registro combina ambos identificadores. Se ignora en los
flujos KYC.
example: Tesco PLC
x-readme-id: '1.10'
registry_country:
type: string
maxLength: 10
description: >-
Código ISO 3166-1 alfa-2 del país en cuyo registro de
empresas está inscrita la empresa. Por ejemplo, `GB`.
Cuando los registros de empresas funcionan a nivel de
estado o provincia, añade el código de subdivisión ISO
3166-2 con el formato `XX-YY`: `US-CA` corresponde al
registro de California. Mismo formato que `country_code`
en la [API de búsqueda en registros
KYB](https://docs.didit.me/es/standalone-apis/kyb-registry-search).
Preselecciona el país del registro en los flujos de
Verificación de empresas (KYB); se ignora en los flujos
de KYC.
example: US-CA
x-readme-id: '1.11'
registration_number:
type: string
maxLength: 100
description: >-
Número de registro esperado de la empresa en el registro
de empresas. Por ejemplo, `00445790`. Rellena
previamente el campo del número de registro en la
búsqueda del registro en los flujos de Verificación de
empresas (KYB); cuando también se proporciona
`company_name`, la consulta al registro combina ambos
identificadores. Se ignora en los flujos KYC.
example: '00445790'
x-readme-id: '1.12'
x-readme-id: '0.5'
portrait_image:
type: string
format: byte
description: >-
Imagen de retrato del rostro del usuario final codificada en
base64 (máx. 2MB; JPEG, PNG, WebP o TIFF). Se usa como
imagen de referencia para compararla con la captura de
prueba de vida cuando el flujo es un flujo de `Biometric
Authentication` con Coincidencia facial habilitada, o
cualquier flujo de grafo en el que la Coincidencia facial se
ejecute antes de la Verificación de identidad (OCR). Es
opcional cuando el usuario de `vendor_data` ya tiene una
imagen facial almacenada: Didit la reutiliza
automáticamente, resuelta en este orden de prioridad: rostro
de prueba de vida aprobada, foto del chip del pasaporte
electrónico, retrato del documento de identidad, rostro de
perfil registrado manualmente (solo se reutilizan rostros de
sesiones aprobadas o rostros que hayas registrado tú).
Cuando se proporciona, `portrait_image` siempre tiene
prioridad sobre el rostro almacenado. Si se omite y no
existe ningún rostro almacenado (o no se envía
`vendor_data`), la creación de la sesión falla con `400`. Se
ignora para otros tipos de flujo.
example: >-
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=
x-readme-id: '0.6'
sandbox_scenario:
type: string
description: >-
Slug de escenario exclusivo de sandbox. Solo se acepta
cuando la clave de API pertenece a una aplicación en modo
sandbox; se rechaza en aplicaciones de producción. Cuando se
define, el flujo de creación aplica los valores mágicos
incluidos en el escenario a los campos de entrada de la
sesión (contact_details, expected_details), de modo que los
proveedores simulados reproducen el resultado del escenario
a través del pipeline real del flujo. Consulta el catálogo
de escenarios en GET /v1/sandbox/scenarios/ o en [Sandbox y
datos de prueba](/es/integration/sandbox-testing). También
puedes activar (o volver a activar) un escenario después de
la creación mediante POST
/v3/session/{sessionId}/sandbox/arm/, siempre que la sesión
siga en `Not Started`. Para la consulta sin documento, usa
`lookup_partial_match`, `lookup_no_match` o
`lookup_provider_error` para probar el número de intentos
configurado y el mecanismo de respaldo. Para las wallets de
identidad, usa `wallet_cancelled`, `wallet_timeout` o
`wallet_provider_error`; `approve` simula una wallet
verificada. Todas las wallets del catálogo se pueden probar
en sandbox, incluidos los esquemas que no están disponibles
en aplicaciones de producción. Los intentos simulados no se
cobran.
example: decline_document_expired
sign:
type: object
description: >-
Datos de firma electrónica para esta sesión. `documents` son
los documentos que se deben firmar, para un flujo cuyo paso
de Firma electrónica toma los documentos de la sesión
(`signature_documents_source` `session` o `both`): hasta 20
documentos y 50 MB en total. `field_values` rellena los
campos cuyo `prefill` es `api.`, tanto en los
documentos del flujo como en los de la sesión. Si vuelves a
crear una sesión para el mismo `workflow_id` y
`vendor_data`, se devuelve la sesión pendiente; si esa
llamada envía `sign`, sus documentos, campos y valores deben
ser idénticos a los primeros, y cualquier diferencia
devuelve `400` con `{"sign": "signature_document_changed"}`.
Consulta [Documentos de firma
electrónica](/es/sessions-api/create-session#documentos-de-firma-electrónica).
properties:
documents:
type: array
minItems: 1
maxItems: 20
items:
$ref: '#/components/schemas/SessionSignDocument'
field_values:
type: object
description: >-
Valores indexados por la `` de cada fuente de
prellenado `api.`: cadenas de 1 a 500 caracteres
para los campos `text` y `data`, y booleanos para un
`checkbox`. Devuelve `400` con `field_value_unknown`
para una clave que ningún campo usa,
`field_value_missing` para un campo obligatorio sin su
valor y `field_value_invalid` para un valor que no
supera la validación de su campo.
additionalProperties:
oneOf:
- type: string
minLength: 1
maxLength: 500
- type: boolean
example:
credit_limit: 3,000 EUR
user_state:
type: string
maxLength: 16
description: >-
Lugar de residencia de la persona, cuando lo conoces: un
código de subdivisión ISO 3166-2 (`US-IL`, `ES-M`) o un
código o nombre de estado de EE. UU. (`IL`, `Illinois`). Un
estado cuya ley exige consentimiento biométrico explícito
(Illinois, Texas, Colorado) hace que el flujo de
verificación lo solicite antes de capturar un rostro, con el
disparador `declared_state`. Un valor no reconocido devuelve
`400`. Consulta [Consentimiento
biométrico](/es/getting-started/biometric-consent).
example: US-IL
biometric_consent:
type: object
description: >-
Consentimiento biométrico explícito que ya recopilaste de la
persona. Cumple el requisito, por lo que el flujo de
verificación no vuelve a pedirlo, y la decisión lo registra
como `status: "given"` con el disparador
`customer_collected`. Una respuesta que la persona ya dio en
el flujo nunca se reemplaza. Consulta [Consentimiento
biométrico](/es/getting-started/biometric-consent).
required:
- given_at
- text_version
properties:
given_at:
type: string
format: date-time
description: >-
Fecha y hora en que la persona dio su consentimiento
biométrico explícito (ISO 8601). No puede ser una fecha
futura.
text_version:
type: string
maxLength: 64
description: >-
ID de la versión del texto de consentimiento que aceptó
la persona, en tus propios registros.
example:
workflow_id: 11111111-2222-3333-4444-555555555555
vendor_data: user-123
callback: https://example.com/verification/callback
callback_method: both
metadata:
user_type: premium
account_id: ABC123
language: en
contact_details:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
expected_details:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
id_country: USA
expected_document_types:
- P
- ID
examples:
Create KYC session:
summary: >-
Payload completo del flujo sin incidencias de una sesión de
Verificación de usuarios (KYC)
description: >-
Llamada de creación realista que usa todos los campos que se
suelen configurar: selección del flujo, vinculación con datos
de vendor, enrutamiento del callback, metadatos, configuración
regional, datos de contacto precargados y datos esperados del
usuario. Cópiala y pégala directamente en el ejemplo de cURL
de arriba.
value:
workflow_id: 11111111-2222-3333-4444-555555555555
vendor_data: user-123
callback: https://example.com/verification/callback
callback_method: both
metadata:
user_type: premium
account_id: ABC123
language: en
contact_details:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
expected_details:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
nationality: USA
id_country: USA
expected_document_types:
- P
- ID
Create KYB session:
summary: >-
Payload del flujo exitoso para una sesión de Verificación de
empresas (KYB)
description: >-
Misma estructura que la llamada de KYC: el `workflow_id` es lo
que convierte la sesión en KYB. `vendor_data` suele hacer
referencia a la empresa en tu sistema y
`contact_details.email` se dirige al representante legal que
completará el flujo. `expected_details` acepta los campos de
empresa (`company_name`, `registry_country`,
`registration_number`), que rellenan de antemano la búsqueda
en el registro de empresas; los campos de persona y
`contact_details.phone` se ignoran en los flujos de KYB.
value:
workflow_id: 33333333-4444-5555-6666-777777777777
vendor_data: company-acme-001
callback: https://example.com/kyb/callback
callback_method: both
metadata:
tier: enterprise
company_id: ACME-001
expected_details:
company_name: Tesco PLC
registry_country: GB
registration_number: '00445790'
language: en
contact_details:
email: legal-rep@acme.example.com
send_notification_emails: true
email_lang: en
responses:
'201':
description: >-
Sesión creada (o devuelta, si ya existe una sesión sin terminar con
el mismo `vendor_data` en la última versión publicada del flujo). La
respuesta es la sesión serializada, incluida la `url` de la
verificación alojada a la que debes redirigir al usuario.
content:
application/json:
schema:
type: object
required:
- session_id
- session_number
- session_token
- url
- vendor_data
- metadata
- status
- workflow_id
- workflow_version
- callback
properties:
session_id:
type: string
format: uuid
description: >-
Identificador único de la sesión de verificación. Usa este
id al llamar a `GET /v3/session/{sessionId}/decision/`.
example: 11111111-2222-3333-4444-555555555555
session_number:
type: integer
description: >-
Número secuencial y fácil de leer asignado a la sesión
dentro de tu aplicación. Útil para soporte y paneles.
example: 43762
session_token:
type: string
description: >-
Token de 12 caracteres seguro para URL que autoriza al
usuario final a acceder al flujo de verificación alojado
en `url`. Es válido hasta que la sesión expira. Trátalo
como un secreto: cualquiera que lo tenga puede abrir el
flujo de verificación de esta sesión.
example: 3FaJ9wLqX2Mz
url:
type: string
format: uri
description: >-
URL de verificación alojada a la que debes redirigir al
usuario final. La URL incluye el `session_token` y, si
está configurado, usa tu dominio de marca blanca. Cuando
la solicitud incluye `language`, la URL contiene un
segmento de ruta con el idioma:
`https://verify.didit.me/{language}/session/{session_token}`
(p. ej., `/es/session/...`); sin `language`, el segmento
se omite.
example: https://verify.didit.me/session/3FaJ9wLqX2Mz
vendor_data:
type: string
nullable: true
description: >-
Identificador que pasaste en la solicitud para vincular la
sesión con un usuario o una empresa de tu propio sistema.
Se devuelve tal cual. Null si no se proporciona.
example: user-123
metadata:
description: >-
Payload JSON arbitrario que guardaste con la sesión al
crearla. Se devuelve literalmente: cualquier valor JSON
que hayas enviado (objeto, cadena, número, array) se
devuelve tal cual, aunque se recomienda un objeto JSON. No
se muestra al usuario final. Siempre está presente en las
respuestas; es `null` si no se proporcionó al crearla.
example:
user_type: premium
account_id: ABC123
tags:
type: array
items:
type: string
description: Las etiquetas de la sesión, por nombre.
example:
- VIP
- ONBOARDING Q4
status:
type: string
enum:
- Not Started
- In Progress
- Approved
- Declined
- In Review
- Expired
- Abandoned
- Kyc Expired
- Resubmitted
- Awaiting User
description: >-
Estado actual de la sesión. Las sesiones recién creadas
devuelven `Not Started`. Si ya existía una sesión no
finalizada para el mismo `vendor_data` en la última
versión publicada del flujo, el estado devuelto refleja
esa sesión existente.
example: Not Started
callback:
type: string
format: uri
nullable: true
description: >-
URL de redirección final a la que se envía al usuario
después de completar el flujo. Didit añade
`?verificationSessionId={session_id}&status={status}` a
esta URL. Si no se proporciona en la solicitud, se usa la
URL de callback configurada en el flujo; es `null` cuando
no se ha definido ninguna de las dos. Cuando la aplicación
tiene dominios permitidos y esta URL es una URL web fuera
de ellos (por ejemplo, un valor predeterminado del flujo
definido antes de que cambiara la lista), el flujo alojado
no redirige al usuario a ella.
example: https://example.com/verification/callback
workflow_id:
type: string
format: uuid
description: >-
Identificador estable del flujo en el que se ejecuta esta
sesión. Siempre es el identificador de grupo estable del
flujo: aunque en la solicitud hayas indicado el UUID de
una versión concreta del flujo (búsqueda compatible con
versiones anteriores), la respuesta incluye el
`workflow_id` estable. Úsalo para relacionar la sesión con
el flujo que configuraste en la consola.
example: 11111111-2222-3333-4444-555555555555
workflow_version:
type: integer
description: >-
Número de la versión publicada del flujo a la que quedó
fijada la sesión al crearse. Didit resuelve `workflow_id`
a la última versión publicada del flujo cuando se crea la
sesión, y la sesión sigue ejecutando esa versión aunque el
flujo se vuelva a publicar más adelante.
example: 3
examples:
KYC session:
summary: Sesión KYC creada
value:
session_id: 11111111-2222-3333-4444-555555555555
session_number: 43762
session_token: 3FaJ9wLqX2Mz
url: https://verify.didit.me/en/session/3FaJ9wLqX2Mz
vendor_data: user-123
metadata:
user_type: premium
account_id: ABC123
status: Not Started
workflow_id: 11111111-2222-3333-4444-555555555555
workflow_version: 3
callback: https://example.com/verification/callback
KYB session:
summary: Sesión KYB creada
value:
session_id: 22222222-3333-4444-5555-666666666666
session_number: 43763
session_token: Yk7pQ2vN8aBc
url: https://verify.didit.me/en/session/Yk7pQ2vN8aBc
vendor_data: company-acme-001
metadata:
tier: enterprise
status: Not Started
workflow_id: 33333333-4444-5555-6666-777777777777
workflow_version: 1
callback: https://example.com/kyb/callback
'400':
description: >-
Solicitud incorrecta: el payload no superó la validación
(`workflow_id` ausente o desconocido, `language` no válido,
`vendor_data` en la lista de bloqueo, `portrait_image` con formato
incorrecto, `address` sin `country`/`poa_country`,
`sandbox_scenario` no válido, documentos `sign`, campos o valores
que rechaza el paso de Firma electrónica del flujo, como
`signature_document_not_supported`,
`signature_document_conversion_failed`, `field_anchor_not_found` o
`field_value_missing`, etc.) o tu organización no tiene suficientes
créditos para iniciar la sesión.
El cuerpo es un objeto cuyas claves son el nombre del campo
problemático (o `detail` para los errores que no son de un campo).
Los valores son un **array de cadenas** en los fallos de validación
de la entrada (p. ej., falta un campo obligatorio, idioma no válido,
imagen de retrato demasiado grande) y una **cadena simple** en los
fallos detectados al crear la sesión (`workflow_id` desconocido,
`vendor_data` en la lista de bloqueo, ningún rostro de referencia
disponible para un flujo de Coincidencia facial). Gestiona ambas
formas.
content:
application/json:
schema:
type: object
additionalProperties: true
properties:
detail:
type: string
description: >-
Mensaje de error legible para errores no asociados a un
campo (p. ej., créditos insuficientes). En los fallos a
nivel de campo, la clave es el nombre del campo, con un
valor de tipo cadena o array de cadenas.
example: >-
You don't have enough credits to perform this request.
Please top up at https://business.didit.me
examples:
Missing workflow_id:
summary: Campo obligatorio omitido (forma de array de cadenas)
value:
workflow_id:
- This field is required.
Invalid workflow_id:
summary: workflow_id desconocido (formato de cadena simple)
value:
workflow_id: Invalid workflow_id.
Insufficient credits:
summary: La organización no tiene créditos
value:
detail: >-
You don't have enough credits to perform this request.
Please top up at https://business.didit.me
Blocklisted vendor_data:
summary: vendor_data está en la lista de bloqueo
value:
vendor_data: >-
This user or business has been blocked and cannot create
new verification sessions.
Portrait image too large:
summary: portrait_image no supera la validación de tamaño
value:
portrait_image:
- Image size exceeds 2MB.
No stored face for vendor_data:
summary: >-
Flujo de Coincidencia facial sin portrait_image y sin rostro
almacenado para el usuario de vendor_data
value:
portrait_image: >-
No stored face image was found for this user. Send a
portrait_image, or complete an approved verification with
face liveness or an ID document for this vendor_data
first.
Portrait image required without vendor_data:
summary: >-
Flujo de Coincidencia facial sin portrait_image y sin
vendor_data
value:
portrait_image: >-
A portrait image is required to perform face match for
this workflow. Send a portrait_image, or provide the
vendor_data of a user with a previously stored face image
to reuse it.
'403':
description: >-
Falló la autenticación o la autorización. Una clave incorrecta,
revocada o expirada devuelve `401`. El endpoint devuelve `403`
cuando falta el encabezado `x-api-key` o cuando la clave de API es
válida pero el cliente no tiene permiso para crear sesiones en esta
aplicación (por ejemplo, la clave de API pertenece a otra
organización). Estos fallos comparten el cuerpo `{"detail": "You do
not have permission to perform this action."}`. Comprueba que el
encabezado `x-api-key` esté presente y pertenezca a la aplicación
prevista, vuelve a obtener la clave de API de la aplicación mediante
la [API de autenticación](/es/auth-api/get-credentials) si es
necesario y vuelve a intentarlo.
**Aplicación eliminada:** durante unos minutos después de eliminar
una aplicación, una solicitud hecha con una de sus claves de API
puede responder `{"detail": "This application was deleted.", "code":
"application_deleted"}`. No vuelvas a intentarlo: la aplicación y
sus claves de API ya no existen. Pasados esos minutos, la clave se
rechaza como cualquier otra clave no válida.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: You do not have permission to perform this action.
code:
type: string
description: >-
Motivo legible por máquina, presente solo en algunos
fallos. `application_deleted`: la clave de API pertenece a
una aplicación que se eliminó.
example: application_deleted
required:
- detail
examples:
Missing or invalid API key:
summary: >-
Falta el encabezado `x-api-key` o la clave de API no es
válida
value:
detail: You do not have permission to perform this action.
No permission:
summary: El cliente no puede crear sesiones
value:
detail: You do not have permission to perform this action.
Application deleted:
summary: Clave de API de una aplicación eliminada
value:
detail: This application was deleted.
code: application_deleted
'429':
description: >-
Límite de solicitudes superado: más de 600 solicitudes de creación
de sesión en una ventana de 60 segundos desde la misma clave de API
o IP. Consulta `Retry-After` y espera antes de reintentar.
**Nota:** El código fuente también define un
`FREE_SESSION_RATE_LIMIT` de 10 llamadas por minuto junto con
`PAID_SESSION_RATE_LIMIT=600` (`sessions/serializers/session.py`),
pero ese tope del plan gratuito **no se aplica a este endpoint V3**:
el middleware de límite de solicitudes aplica el
`SESSION_CREATE_RATE_LIMIT` de 600 por minuto independientemente del
plan. 600 por minuto es el único límite que puedes alcanzar aquí.
headers:
Retry-After:
description: >-
Segundos que quien llama debe esperar antes de reintentar la
solicitud.
schema:
type: integer
minimum: 1
example: 42
X-RateLimit-Limit:
description: >-
Número máximo de solicitudes permitidas en la ventana actual de
60 segundos para el límite que se superó (600 para la creación
de sesiones). No aparece en la variante de cuota del sandbox.
schema:
type: integer
example: 600
X-RateLimit-Remaining:
description: >-
Número de solicitudes que aún se permiten en la ventana actual
para el límite superado. No aparece en la variante de cuota de
sandbox.
schema:
type: integer
minimum: 0
example: 0
X-RateLimit-Reset:
description: >-
Segundos de época Unix (UTC) en los que se restablece la ventana
actual del límite de solicitudes. Ausente en la variante de
cuota de sandbox.
schema:
type: integer
minimum: 0
example: 1747497600
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
Explicación legible de la superación del límite de
solicitudes. Usa este mensaje para distinguir cuál de los
tres límites se alcanzó.
example: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
examples:
Session-create limit:
summary: Más de 600 solicitudes de creación de sesión por minuto
value:
detail: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
Sandbox session quota:
summary: La aplicación sandbox superó las 500 sesiones en 24 horas
value:
detail: >-
Sandbox session quota exceeded (500 sessions per 24h).
Wait for the window to reset. Expected available in 3600
seconds.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: cURL
source: |-
curl -X POST 'https://verification.didit.me/v3/session/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"workflow_id": "11111111-2222-3333-4444-555555555555",
"vendor_data": "user-123",
"callback": "https://example.com/verification/callback",
"callback_method": "both",
"metadata": {"user_type": "premium", "account_id": "ABC123"},
"language": "en",
"contact_details": {
"email": "john.doe@example.com",
"send_notification_emails": true,
"email_lang": "en",
"phone": "+14155552671"
},
"expected_details": {
"first_name": "John",
"last_name": "Doe",
"date_of_birth": "1990-05-15",
"id_country": "USA",
"expected_document_types": ["P", "ID"]
}
}'
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.sessions.create(
workflow_id="11111111-2222-3333-4444-555555555555",
vendor_data="user-123",
callback="https://example.com/verification/callback",
callback_method="both",
metadata={"user_type": "premium", "account_id": "ABC123"},
language="en",
contact_details={
"email": "john.doe@example.com",
"send_notification_emails": True,
"email_lang": "en",
"phone": "+14155552671",
},
expected_details={
"first_name": "John",
"last_name": "Doe",
"date_of_birth": "1990-05-15",
"nationality": "USA",
"id_country": "USA",
"expected_document_types": ["P", "ID"],
},
)
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.sessions.create({
workflow_id: "11111111-2222-3333-4444-555555555555",
vendor_data: "user-123",
callback: "https://example.com/verification/callback",
callback_method: "both",
metadata: { user_type: "premium", account_id: "ABC123" },
language: "en",
contact_details: {
email: "john.doe@example.com",
send_notification_emails: true,
email_lang: "en",
phone: "+14155552671",
},
expected_details: {
first_name: "John",
last_name: "Doe",
date_of_birth: "1990-05-15",
nationality: "USA",
id_country: "USA",
expected_document_types: ["P", "ID"],
},
});
console.log(result);
- lang: go
label: Go
source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.Create(ctx, didit.SessionsCreateParams{\n\tWorkflowID: \"11111111-2222-3333-4444-555555555555\",\n\tVendorData: didit.String(\"user-123\"),\n\tCallback: didit.String(\"https://example.com/verification/callback\"),\n\tCallbackMethod: didit.Some(didit.SessionsCreateParamsCallbackMethod(\"both\")),\n\tMetadata: didit.Some[any](map[string]any{\"user_type\": \"premium\", \"account_id\": \"ABC123\"}),\n\tLanguage: didit.Some(didit.SessionsCreateParamsLanguage(\"en\")),\n\tContactDetails: didit.Some(didit.SessionsCreateParamsContactDetails{\n\t\tEmail: didit.String(\"john.doe@example.com\"),\n\t\tSendNotificationEmails: didit.Bool(true),\n\t\tEmailLang: didit.Some(didit.SessionsCreateParamsContactDetailsEmailLang(\"en\")),\n\t\tPhone: didit.String(\"+14155552671\"),\n\t}),\n\tExpectedDetails: didit.Some(didit.SessionsCreateParamsExpectedDetails{\n\t\tFirstName: didit.String(\"John\"),\n\t\tLastName: didit.String(\"Doe\"),\n\t\tDateOfBirth: didit.String(\"1990-05-15\"),\n\t\tNationality: didit.String(\"USA\"),\n\t\tIDCountry: didit.String(\"USA\"),\n\t\tExpectedDocumentTypes: didit.Some([]didit.SessionsCreateParamsExpectedDetailsExpectedDocumentTypes{\"P\", \"ID\"}),\n\t}),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)"
- lang: java
label: Java
source: |-
import java.time.LocalDate;
import java.util.List;
import java.util.Map;
import me.didit.Didit;
import me.didit.types.SessionsCreateParams;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result = client.sessions().create(SessionsCreateParams.builder()
.workflowId("11111111-2222-3333-4444-555555555555")
.vendorData("user-123")
.callback("https://example.com/verification/callback")
.callbackMethod(SessionsCreateParams.CallbackMethod.of("both"))
.metadata(Map.of("user_type", "premium", "account_id", "ABC123"))
.language(SessionsCreateParams.Language.of("en"))
.contactDetails(SessionsCreateParams.ContactDetails.builder()
.email("john.doe@example.com")
.sendNotificationEmails(true)
.emailLang(SessionsCreateParams.ContactDetails.EmailLang.of("en"))
.phone("+14155552671")
.build())
.expectedDetails(SessionsCreateParams.ExpectedDetails.builder()
.firstName("John")
.lastName("Doe")
.dateOfBirth(LocalDate.parse("1990-05-15"))
.nationality("USA")
.idCountry("USA")
.expectedDocumentTypes(List.of(SessionsCreateParams.ExpectedDetails.ExpectedDocumentTypes.of("P"), SessionsCreateParams.ExpectedDetails.ExpectedDocumentTypes.of("ID")))
.build())
.build());
System.out.println(result);
- lang: php
label: PHP
source: |-
sessions->create([
'workflow_id' => '11111111-2222-3333-4444-555555555555',
'vendor_data' => 'user-123',
'callback' => 'https://example.com/verification/callback',
'callback_method' => 'both',
'metadata' => ['user_type' => 'premium', 'account_id' => 'ABC123'],
'language' => 'en',
'contact_details' => [
'email' => 'john.doe@example.com',
'send_notification_emails' => true,
'email_lang' => 'en',
'phone' => '+14155552671',
],
'expected_details' => [
'first_name' => 'John',
'last_name' => 'Doe',
'date_of_birth' => '1990-05-15',
'nationality' => 'USA',
'id_country' => 'USA',
'expected_document_types' => ['P', 'ID'],
],
]);
print_r($result->toArray());
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.sessions.create(
workflow_id: "11111111-2222-3333-4444-555555555555",
vendor_data: "user-123",
callback: "https://example.com/verification/callback",
callback_method: "both",
metadata: { user_type: "premium", account_id: "ABC123" },
language: "en",
contact_details: {
email: "john.doe@example.com",
send_notification_emails: true,
email_lang: "en",
phone: "+14155552671",
},
expected_details: {
first_name: "John",
last_name: "Doe",
date_of_birth: "1990-05-15",
nationality: "USA",
id_country: "USA",
expected_document_types: ["P", "ID"],
}
)
puts result.to_h
- lang: csharp
label: .NET
source: >-
using System;
using System.Collections.Generic;
using System.Text.Json;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var result = await client.Sessions.CreateAsync(new
SessionsCreateParams
{
WorkflowId = "11111111-2222-3333-4444-555555555555",
VendorData = "user-123",
Callback = "https://example.com/verification/callback",
CallbackMethod = new SessionsCreateParamsCallbackMethod("both"),
Metadata = new Dictionary { ["user_type"] = "premium", ["account_id"] = "ABC123" },
Language = new SessionsCreateParamsLanguage("en"),
ContactDetails = new SessionsCreateParamsContactDetails
{
Email = "john.doe@example.com",
SendNotificationEmails = true,
EmailLang = new SessionsCreateParamsContactDetailsEmailLang("en"),
Phone = "+14155552671",
},
ExpectedDetails = new SessionsCreateParamsExpectedDetails
{
FirstName = "John",
LastName = "Doe",
DateOfBirth = "1990-05-15",
Nationality = "USA",
IdCountry = "USA",
ExpectedDocumentTypes = new SessionsCreateParamsExpectedDetailsExpectedDocumentTypes[] { "P", "ID" },
},
});
Console.WriteLine(JsonSerializer.Serialize(result));
components:
schemas:
SessionSignDocument:
type: object
required:
- file_name
- content_base64
properties:
title:
type: string
minLength: 1
maxLength: 255
description: >-
Título que se muestra al firmante. Valor predeterminado:
`file_name`.
file_name:
type: string
minLength: 1
maxLength: 255
description: Nombre de archivo, terminado en `.pdf` o `.docx`.
content_base64:
type: string
format: byte
description: >-
El archivo, codificado en base64. Un PDF puede tener hasta 20 MB y
100 páginas, sin contraseña, scripts ni archivos adjuntos. Un
archivo de Word (`.docx`) puede tener hasta 20 MB y se convierte a
PDF mientras se ejecuta la solicitud, en 25 segundos como máximo;
después, el PDF tiene los mismos límites. Hasta 5 archivos de Word
por sesión. Un archivo de Word con macros, control de cambios,
vínculos a contenido externo u objetos incrustados se rechaza con
`signature_document_not_supported`, y uno que no se puede convertir
devuelve `signature_document_conversion_failed`, en ambos casos con
un `reason`.
fields:
type: array
description: >-
Campos opcionales que se colocan en este documento, hasta 200. Las
páginas y posiciones se refieren al PDF o, en el caso de un archivo
Word, al PDF convertido. Sin campos, el firmante lee el documento y
da su conformidad.
items:
$ref: '#/components/schemas/SignatureField'
maxItems: 200
SignatureField:
type: object
description: >-
Un campo que se coloca en un documento de la sesión: qué firmante lo
completa, cómo y dónde. Indica una posición (`page`, `x`, `y`, `width` y
`height`) o un `anchor`. Las posiciones son fracciones de la página tal
como se muestra, desde su esquina superior izquierda, redondeadas a 4
decimales, y el campo debe caber dentro de la página. Un documento
admite hasta 200 campos y un firmante hasta 500, y cada rol con campos
en un documento necesita allí un campo `signature` o `initials`.
Consulta [Campos en el
documento](/es/core-technology/electronic-signature/overview#campos-en-el-documento).
required:
- key
- type
properties:
key:
type: string
pattern: ^[a-z][a-z0-9_]{0,63}$
description: >-
Da nombre al campo en los resultados y en `sign.field_values`. Único
dentro del documento.
type:
type: string
enum:
- signature
- initials
- full_name
- date_signed
- text
- checkbox
- email
- data
description: >-
Qué contiene el campo. El firmante aplica su `signature` e
`initials` adoptadas, escribe en `text`, marca un `checkbox` y
escribe un `email` cuando la sesión no tiene un correo electrónico
verificado. Didit rellena `full_name` (el nombre verificado),
`date_signed` (la fecha de la firma, en la zona horaria del
firmante), `data` (a partir de `prefill`) y un `email` verificado, y
los muestra como de solo lectura. No existe un tipo selector de
fecha: usa `text`.
role:
type: string
enum:
- verified_person
- legal_representative
- key_people
description: >-
Quién rellena el campo, con los valores de `signature_signer`. Un
paso solo rellena y sella los campos de su propio firmante. El valor
predeterminado es el firmante del paso.
page:
type: integer
minimum: 1
description: >-
Número de página, de 1 al número de páginas del documento. En un
documento de Word, una página del PDF convertido.
x:
type: number
minimum: 0
maximum: 1
description: Borde izquierdo, como fracción del ancho de la página.
'y':
type: number
minimum: 0
maximum: 1
description: Borde superior, como fracción de la altura de la página.
width:
type: number
minimum: 0.02
maximum: 1
description: >-
Ancho, como fracción del ancho de la página. Una firma tiene un
ancho mínimo de `0.12`.
height:
type: number
minimum: 0.012
maximum: 1
description: >-
Altura, como fracción de la altura de la página. Una firma tiene una
altura mínima de `0.035`.
anchor:
$ref: '#/components/schemas/SignatureFieldAnchor'
required:
type: boolean
description: >-
`signature` and `initials` are required unless you set `false`.
`full_name`, `date_signed` and `data` are always required. The
signer can't finish a document until its required fields have a
value, and a required checkbox must be ticked.
label:
type: string
minLength: 1
maxLength: 80
description: >-
Se muestra al firmante y en los resultados. El valor predeterminado
depende del tipo.
placeholder:
type: string
nullable: true
maxLength: 80
description: Solo `text` y `email`.
validation:
$ref: '#/components/schemas/SignatureFieldValidation'
prefill:
type: string
nullable: true
description: >-
Origen del valor: `identity.full_name`, `identity.first_name`,
`identity.last_name`, `identity.date_of_birth` (`DD/MM/YYYY`),
`identity.nationality`, `identity.document_number`,
`identity.document_type`, `identity.issuing_country`,
`identity.address`, `contact.email`, `contact.phone`,
`company.name`, `company.registration_number`, `company.address`,
`company.country` (KYB), `session.vendor_data`, `metadata.`
(una clave del `metadata` de la sesión) o `api.` (una clave de
`sign.field_values`). Obligatorio para `data`. `full_name` siempre
usa `identity.full_name` y `email` usa `contact.email`. Los valores
de los campos `data`, `full_name` y `email` verificado quedan
fijados cuando el firmante empieza a firmar.
editable_when_prefilled:
type: boolean
default: false
description: >-
Solo `text` y `email`: el firmante puede cambiar un valor
prellenado.
checked_by_default:
type: boolean
default: false
description: 'Solo `checkbox`: la casilla aparece marcada de inicio.'
date_format:
type: string
enum:
- DD/MM/YYYY
- MM/DD/YYYY
- YYYY-MM-DD
- D MMMM YYYY
default: DD/MM/YYYY
description: Solo `date_signed`.
SignatureFieldAnchor:
type: object
description: >-
Coloca un campo mediante un fragmento de texto del documento en lugar de
en una posición. Didit no elimina el texto del PDF, así que escríbelo
del mismo color que el fondo de la página. Si no se encuentra el texto,
la llamada devuelve `400` con `field_anchor_not_found`. Consulta
[Colocar campos mediante texto de
anclaje](/es/sessions-api/create-session#colocar-campos-por-texto-de-anclaje).
required:
- text
properties:
text:
type: string
minLength: 1
maxLength: 64
description: >-
Texto que se busca en el documento. En un archivo de Word, se busca
en el PDF convertido.
occurrence:
type: string
enum:
- first
- all
default: first
description: >-
`all` coloca un campo por coincidencia; las claves posteriores a la
primera reciben `_2`, `_3`, etc.
offset_x:
type: number
description: >-
Se suma al borde izquierdo del texto, como fracción del ancho de la
página.
offset_y:
type: number
description: >-
Se suma al borde superior del texto, como fracción de la altura de
la página.
width:
type: number
minimum: 0.02
maximum: 1
description: Ancho del campo, como fracción del ancho de la página.
height:
type: number
minimum: 0.012
maximum: 1
description: Altura del campo, como fracción de la altura de la página.
SignatureFieldValidation:
type: object
nullable: true
description: >-
Reglas para el valor de un campo `text`. La vista previa de la consola,
el flujo de firma y la API aplican las mismas reglas.
properties:
kind:
type: string
enum:
- any
- letters
- number
- email
- pattern
description: >-
`letters`: letras de cualquier alfabeto, espacios, guiones y
apóstrofos. `number`: dígitos con un separador decimal opcional.
`pattern`: el valor debe coincidir con `pattern`.
min_length:
type: integer
minimum: 0
maximum: 500
description: Desde `0` hasta `max_length`.
max_length:
type: integer
minimum: 1
maximum: 500
default: 120
pattern:
type: string
nullable: true
minLength: 1
maxLength: 200
description: >-
Obligatorio con `kind: "pattern"`. Una expresión regular con la que
debe coincidir el valor completo. No se admiten lookarounds ni
referencias inversas.
message:
type: string
nullable: true
maxLength: 120
description: Se muestra al firmante en lugar del error predeterminado.
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.