> ## 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 de criação de sessão: inicie a verificação KYC ou KYB
> POST /v3/session/ da Didit inicia uma sessão de verificação. Endpoint unificado KYC + KYB, pagamento por uso, inferência sub-2s, $10 de crédito/mês.
Prompt para criar sessão
Copiar o prompt para a área de transferência
\
\`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.`
\
Colar em
## Suporte a KYC e KYBUm único endpoint cria sessões de Verificação de usuários e de Verificação de empresas. O **tipo do fluxo de verificação (workflow)** determina qual delas:- Envie o `workflow_id` de um **fluxo de KYC** → é criada uma sessão de Verificação de usuários (KYC). Resposta `session_kind: "user"`.
- Envie o `workflow_id` de um **fluxo de KYB** → é criada uma sessão de Verificação de empresas (KYB). Resposta `session_kind: "business"`.Configure os fluxos no console em *Workflows → Create workflow*. Um fluxo é definido como KYC ou KYB no momento da criação; não é possível trocar o tipo depois.## Exemplos> [tab] Verificação de usuários (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"
> }'
> ```
>
> **Resposta (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] Verificação 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"
> }'
> ```
>
> **Resposta (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 assinatura eletrônicaQuando o fluxo tem uma etapa de [Assinatura eletrônica](https://docs.didit.me/pt-br/core-technology/electronic-signature/overview.md) que recebe documentos da sessão (`signature_documents_source` definido como `session` ou `both`), envie-os em `sign.documents`. Cada documento é o arquivo em base64, para que a Didit nunca precise buscá-lo em uma 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 | Regras |
| - | - |
| `title` | Exibido para quem assina. De 1 a 255 caracteres. O padrão é `file_name`. |
| `file_name` | Obrigatório. Termina em `.pdf` ou `.docx`. De 1 a 255 caracteres. |
| `content_base64` | Obrigatório. Um PDF pode ter até 20 MB e 100 páginas, sem senha, scripts ou arquivos anexados. Um arquivo Word pode ter até 20 MB e é convertido em PDF durante a requisição, em no máximo 25 segundos; o PDF resultante tem os mesmos limites. Até 5 arquivos Word por sessão. |
| `fields` | Opcional. Até 200 [campos](https://docs.didit.me/pt-br/core-technology/electronic-signature/overview.md#campos-no-documento) para posicionar no documento, no formato de campo sem `id`. Cada campo precisa de um `key` e um `type`, e de uma posição (`page`, `x`, `y`, `width` e `height`) ou de um [`anchor`](#posicionar-campos-por-texto-âncora). O padrão de `role` é o signatário da etapa, e os padrões de `required` e `label` vêm do tipo. A Didit define `position` de acordo com o local onde o campo fica. Páginas e posições se referem ao PDF ou, no caso de um arquivo Word, ao PDF convertido. |Sem `fields`, o signatário lê o documento e concorda com ele.### Posicionar campos por texto âncoraEm vez de uma posição, um campo pode ter um `anchor`: um trecho de texto no documento que marca onde o campo fica. Âncoras são adequadas para documentos que você gera para cada sessão, por exemplo a partir de um modelo do Word. Para documentos do fluxo, posicione os campos no console.| Propriedade de `anchor` | Regras |
| - | - |
| `text` | De 1 a 64 caracteres, buscados no texto do documento. Para um arquivo Word, no PDF convertido. |
| `occurrence` | `first` (padrão) posiciona um campo na primeira ocorrência. `all` posiciona um campo por ocorrência, e as chaves depois da primeira recebem `_2`, `_3` e assim por diante. |
| `offset_x`, `offset_y` | Frações da página. O canto superior esquerdo do campo é o canto superior esquerdo do texto âncora somado a esses deslocamentos. |
| `width`, `height` | O tamanho do campo, em frações da página. |Quando o texto não está no documento, a chamada retorna `400` com `field_anchor_not_found` e a chave do campo. A Didit não remove o texto âncora do PDF, então escreva-o na mesma cor do fundo da página.### Valores dos campos`sign.field_values` define o valor de todo campo cujo `prefill` é `api.`, tanto nos documentos do fluxo quanto nos documentos da sessão. É um objeto indexado por esses nomes ``. Os valores são strings de 1 a 500 caracteres para campos `text` e `data`, e booleanos para um `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" }
}
}
```| Erro (`400`) | Quando |
| - | - |
| `field_value_unknown` | Uma chave que nenhum campo usa. |
| `field_value_missing` | Um campo obrigatório cujo `api.` não tem valor. |
| `field_value_invalid` | Um valor que não passa na [validação](https://docs.didit.me/pt-br/core-technology/electronic-signature/overview.md#validação) do seu campo. |### Erros e chamadas repetidasUma sessão aceita até 20 documentos e 50 MB no total. A chamada retorna `400` com um erro em `sign` quando:- O fluxo não tem etapa de Assinatura eletrônica.
- Você enviou `sign.documents` e a etapa só aceita documentos do fluxo.
- A etapa aceita apenas documentos da sessão e você não enviou nenhum, ou ela não tem documentos do fluxo e você não enviou nenhum.
- Um documento é grande demais, não é base64 válido ou não é um arquivo compatível.
- Um arquivo Word é recusado com `signature_document_not_supported`, ou não pode ser convertido e retorna `signature_document_conversion_failed`, cada um com o `reason` listado em [Arquivos compatíveis](https://docs.didit.me/pt-br/core-technology/electronic-signature/overview.md#arquivos-compatíveis).
- Um campo é inválido, sua âncora não é encontrada (`field_anchor_not_found`) ou um [valor de campo](#valores-dos-campos) é recusado.Fazer outra chamada de criação com o mesmo `workflow_id` e `vendor_data` retorna a sessão pendente. Se essa chamada enviar `sign`, seus documentos, campos e valores de campos devem ser idênticos aos da primeira (mesma ordem, títulos, nomes de arquivo, conteúdo, campos e valores). Qualquer diferença retorna `400` com `{"sign": "signature_document_changed"}`: use outro `vendor_data` ou aguarde até que a sessão pendente seja concluída.## Testes com cenários de sandboxEm uma aplicação em modo sandbox, envie `sandbox_scenario` para pré-carregar um resultado determinístico (aprovação, uma recusa específica ou um cenário em revisão) sem acionar provedores reais nem consumir seu saldo:```json theme={null}
{
"workflow_id": "YOUR_SANDBOX_WORKFLOW_ID",
"sandbox_scenario": "decline_document_expired"
}
````sandbox_scenario` é rejeitado com `400` em aplicações de produção. Se você ainda não souber o resultado no momento da criação, configure-o (ou reconfigure-o) depois via `POST /v3/session/{session_id}/sandbox/arm/`, desde que a sessão ainda esteja em `Not Started`: o seletor de cenários pré-fluxo do fluxo hospedado usa esse mesmo endpoint. Consulte [Sandbox e dados de teste](https://docs.didit.me/pt-br/integration/sandbox-testing.md) para ver o catálogo completo de cenários, o registro de valores mágicos e o formato de requisição e resposta do endpoint de configuração.## `vendor_data` vincula a sessão a uma entidade- Em fluxos de KYC: vincula a uma [entidade de usuário](https://docs.didit.me/pt-br/entities/users/overview.md). Se o usuário não existir, ele é criado automaticamente.
- Em fluxos de KYB: vincula a uma [entidade de empresa](https://docs.didit.me/pt-br/entities/businesses/overview.md). Se a empresa não existir, ela será criada automaticamente.Saiba mais em [vinculação de vendor data](https://docs.didit.me/pt-br/entities/vendor-data-linking.md).## Consentimento biométrico em Illinois, Texas e ColoradoO fluxo hospedado e o SDK nativo 4.10.0 ou posterior podem exibir uma etapa explícita de consentimento biométrico antes da primeira captura facial, de acordo com o modo de consentimento da aplicação e com o local onde a pessoa está. Dois campos opcionais alimentam essa decisão:- `user_state`: onde a pessoa mora, quando você souber (`US-IL`, `IL` ou `Illinois`). No modo Auto, um estado coberto faz o fluxo solicitar o consentimento.
- `biometric_consent`: um objeto com `given_at` e `text_version`, para o consentimento que você já coletou. O fluxo não solicita novamente.SDKs nativos anteriores à versão 4.10.0 não conseguem exibir essa etapa: as sessões deles funcionam como antes e a decisão informa o consentimento como não coletado. Consulte [Consentimento biométrico](https://docs.didit.me/pt-br/getting-started/biometric-consent.md).## Importante: a divulgação de informações e o consentimento continuam acontecendo no seu produto`Create Session` gera uma URL de verificação e um token de sessão. Isso **não** comprova, por si só, que você apresentou ao usuário as informações obrigatórias nem que obteve o consentimento exigido para o seu caso de uso específico.Se você inicia uma sessão da Didit a partir da sua própria aplicação, site, wrapper de SDK ou fluxo de marca própria, você deve tratar a camada jurídica na sua própria UX antes que o usuário comece a captura.## Checklist recomendado antes da verificação1. Informe ao usuário que **a sua empresa** está solicitando a verificação e que a **Didit** é a provedora / operadora de verificação que viabiliza o fluxo.
2. Inclua um link para o **seu aviso de privacidade** e para quaisquer termos jurídicos aplicáveis ao controlador que se apliquem à jornada.
3. Inclua um link para o [Aviso de Privacidade de Verificação](https://didit.me/terms/verification-privacy-notice) e para os [Termos do Usuário Final para Verificação de Identidade](https://didit.me/terms/identity-verification) da Didit.
4. Se o seu fluxo incluir captura de documento, captura de selfie, prova de vida ou biometria, colete um **consentimento explícito e afirmativo** sempre que a legislação aplicável ou o seu posicionamento jurídico exigir.
5. Se você usa uma UI personalizada, um domínio personalizado ou uma jornada somente via API, exiba essas informações no seu próprio produto antes de encaminhar o usuário para o fluxo da Didit.
6. Mantenha o seu próprio registro do texto do aviso / consentimento, do registro de data e hora e dos metadados relacionados, caso a sua equipe jurídica exija uma trilha de auditoria.> [!WARNING]
>
> Os requisitos legais variam conforme a jurisdição. O branding de marca branca não elimina o papel da Didit no fluxo de verificação. Revise a sua implementação com sua assessoria jurídica antes do lançamento se você atua em jurisdições com regras específicas para biometria.
## OpenAPI
````yaml pt-br/openapi-25.json POST /v3/session/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API de verificação de identidade. Autentique-se com o cabeçalho x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/session/:
post:
tags:
- Sessions
summary: Criar uma sessão de verificação
description: >-
Cria uma sessão de Verificação de usuários (KYC) ou de Verificação de
empresas (KYB) e recebe uma `url` de verificação hospedada, além de um
`session_token`, para redirecionar ou incorporar para o seu usuário
final. O `workflow_id` define quais etapas de verificação são executadas
e se a sessão é de KYC ou de KYB.
Chame este endpoint a partir do seu backend (nunca do navegador — a
chave de API é secreta) sempre que um usuário ou uma empresa precisar
ser verificado: no cadastro, antes de uma ação sensível ou quando for
necessária uma reverificação. Pré-requisitos: um fluxo de verificação
(workflow) publicado (criado na página
[Workflows](https://docs.didit.me/pt-br/console/workflows) do Console) e
uma chave de API da aplicação com créditos disponíveis. Aplicações de
sandbox ignoram a verificação de créditos.
**Idempotência:** quando `vendor_data` é informado e já existe uma
sessão não finalizada (`Not Started`, `In Progress`, `Resubmitted` ou
`Awaiting User`) com o mesmo `vendor_data` na **versão publicada mais
recente atual** do fluxo (e essa sessão já tem uma URL de verificação
hospedada), a sessão existente é retornada (ainda com `201`) em vez de
ser criada uma duplicata — com seus `callback` e `metadata` atualizados
para os novos valores informados. Uma sessão não finalizada criada em
uma versão mais antiga do fluxo (que foi republicado desde então)
**não** é reutilizada; em vez disso, é criada uma nova sessão vinculada
à versão publicada mais recente. Sessões em `Approved`, `Declined`, `In
Review`, `Expired`, `Abandoned` ou `Kyc Expired` nunca são reutilizadas.
**Efeitos colaterais:** a URL de verificação hospedada é gerada e
armazenada; se `contact_details.send_notification_emails` for `true` e
um e-mail for informado, um e-mail de convite para verificação é
enviado. A sessão expira após o tempo de expiração de sessão configurado
no fluxo. Em fluxos de KYB, `contact_details.phone` e `expected_details`
são ignorados.
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 estável do fluxo de verificação (workflow) que
define quais etapas de verificação a sessão executará. Os
fluxos são criados e gerenciados na página
[Workflows](/pt-br/console/workflows) do Console. O
`workflow_id` também determina implicitamente se a sessão é
KYC ou KYB.
example: 11111111-2222-3333-4444-555555555555
x-readme-id: '0.0'
vendor_data:
type: string
description: >-
Um identificador exclusivo do usuário que está sendo
verificado, como um UUID, e-mail ou ID interno de usuário.
Este campo é usado para: (1) **Agrupamento de usuários** —
sessões com o mesmo vendor_data são vinculadas ao mesmo
perfil de usuário na aba Usuários. (2) **Detecção de
duplicatas entre sessões** — ao verificar rostos,
documentos, números de telefone, e-mails, endereços IP ou
impressões digitais de dispositivo duplicados, sessões com o
mesmo vendor_data são tratadas como o mesmo usuário e
excluídas das correspondências. Sem vendor_data, cada sessão
é tratada como um usuário único e todas as possíveis
duplicatas são exibidas. Recomendamos fortemente sempre
fornecer um vendor_data para reduzir o ruído na detecção de
duplicatas.
example: user-123
x-readme-id: '0.1'
multi_account_segment:
type: string
maxLength: 64
description: >-
Domínio opcional de detecção de duplicados dentro da sua
organização. As verificações de rosto duplicado comparam
esta sessão apenas com outras sessões que tenham o mesmo
segmento, de modo que bases de contas separadas (contas
pessoais e empresariais, ou uma por subcliente B2B) não
sinalizem uma pessoa que legitimamente tenha uma conta em
cada uma. Omita-o para usar o domínio padrão único, que é o
que todas as sessões usam hoje. As correspondências com a
lista de bloqueio e a lista de permissões ignoram este
campo.
example: business-accounts
callback:
type: string
description: >-
URL para a qual o usuário é redirecionado após a conclusão
da verificação. A Didit acrescenta automaticamente
`verificationSessionId` e `status` (Approved, Declined, In
Review) como parâmetros de consulta. Esquemas de URL
personalizados (por exemplo, `myapp://`) são compatíveis com
callbacks em dispositivos móveis. Se omitida, é usado o
`callback_url` padrão do fluxo de verificação. Quando a
aplicação tem domínios permitidos (`allowed_domains` em
`PATCH /v3/webhook/`), um callback `http` ou `https` deve
estar em uma dessas origens (mesmo esquema, host e porta);
caso contrário, a requisição falha com 400 em `callback`:
`callback must be on one of the application's allowed
domains: https://app.example.com`. Esquemas de URL
personalizados são sempre aceitos.
example: https://example.com/verification/callback
x-readme-id: '0.2'
callback_method:
type: string
description: >-
Determina qual dispositivo deve tratar o redirecionamento
para a URL de retorno informada. Use `initiator` para
redirecionar apenas o dispositivo que iniciou o fluxo,
`completer` para o dispositivo que o conclui ou `both` para
permitir que qualquer um dos dispositivos acione o retorno.
Se você notar que o retorno não é acionado de forma
confiável, recomendamos definir este valor como `both`.
enum:
- initiator
- completer
- both
default: initiator
example: both
x-readme-id: '0.3'
metadata:
description: >-
JSON arbitrário armazenado com a sessão e devolvido na
resposta e nos webhooks. Qualquer valor JSON é aceito
(objeto, string, número, array), mas recomenda-se um objeto
JSON de pares chave/valor. Não é exibido ao usuário final.
Use-o para passar seus próprios IDs de correlação, variantes
de teste A/B ou contexto de negócio.
example:
user_type: premium
account_id: ABC123
x-readme-id: '0.4'
tags:
type: array
items:
type: string
maxLength: 50
maxItems: 10
description: >-
Tags adicionadas à sessão quando ela é criada, pelo nome.
Até 10, cada uma com até 50 caracteres. Os nomes não
diferenciam maiúsculas de minúsculas e são armazenados em
maiúsculas. Um nome que ainda não existe na aplicação é
criado como uma nova tag. As tags aparecem na sessão no
console, onde você pode filtrar por elas.
example:
- VIP
- ONBOARDING Q4
language:
type: string
description: >-
Código de idioma (ISO 639-1) para a interface do processo de
verificação. Controla o idioma exibido ao usuário final
durante a verificação. Se não for informado, o idioma do
navegador será detectado e usado automaticamente. Confira
todos os idiomas suportados
[aqui](/pt-br/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: >-
Informações de contato do usuário que podem ser usadas para
notificações, preenchimento prévio de formulários de
verificação e verificação de telefone. Isso inclui endereço
de e-mail, idioma preferido para comunicações e número de
telefone.
example:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
properties:
email:
type: string
format: email
description: >-
Endereço de e-mail do usuário (por exemplo,
"john.doe@example.com") que será usado na etapa de
[Verificação de
e-mail](/pt-br/core-technology/email-verification/overview).
Se não for informado, o usuário deverá fornecê-lo
durante o fluxo de verificação.
example: john.doe@example.com
x-readme-id: '1.0'
send_notification_emails:
type: boolean
default: false
description: >-
Se true e um e-mail for informado, a Didit envia de
forma assíncrona o e-mail inicial "Verifique sua
identidade" quando a sessão de Verificação de usuários
(KYC) ou Verificação de empresas (KYB) é criada. A Didit
também envia ao endereço de e-mail informado
notificações de status da verificação para sessões que
exigem revisão manual (por exemplo, de 'Em revisão' para
'Aprovado' ou 'Recusado'). Isso ajuda os usuários a
voltar à sua aplicação quando a verificação for
concluída. Se a marca própria estiver ativada para a
sessão, o e-mail enviado será com marca própria.
example: true
x-readme-id: '1.1'
email_lang:
type: string
description: >-
Código de idioma (ISO 639-1) para as notificações por
e-mail. Controla o idioma de todas as comunicações por
e-mail (por exemplo, "en", "es", "fr"). Não há um padrão
armazenado: quando omitido, o e-mail de convite de
verificação simplesmente usa inglês (`en`) no momento do
envio. O enum abaixo é um retrato do momento; a fonte
oficial e atualizada dos valores aceitos é a
documentação de [idiomas
suportados](/pt-br/integration/supported-languages).
Consulte-a sempre antes de depender de um código
específico.
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 telefone no formato E.164 (por exemplo,
"+14155552671") que será usado na etapa de [Verificação
de
telefone](/pt-br/core-technology/phone-verification/overview).
Se não for informado, o usuário deverá fornecê-lo
durante o fluxo de verificação. Ignorado em fluxos de
Verificação de empresas (KYB). **Importante:** este
número de telefone só é aplicado se for um número E.164
válido. Se o número informado for inválido ou não puder
ser interpretado, ele será ignorado e o usuário poderá
inserir qualquer número de telefone válido durante a
etapa de Verificação de telefone.
example: '+14155552671'
x-readme-id: '1.3'
x-readme-id: '0.4'
expected_details:
type: object
description: >-
Dados esperados do usuário, usados para validação cruzada
com os dados extraídos do documento de identidade do
usuário, do Comprovante de endereço e de outras etapas de
verificação. Divergências aparecem como avisos na decisão;
alguns campos (por exemplo, `id_country`,
`expected_document_types`) também alteram o fluxo exibido ao
usuário. Em fluxos de Verificação de empresas (KYB), somente
os campos da empresa (`company_name`, `registry_country`,
`registration_number`) são usados, pois pré-preenchem para o
usuário a busca no registro de empresas, e todos os campos
referentes à pessoa são ignorados.
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: >-
Nome do usuário. Por exemplo, `John`. A correspondência
usa comparação aproximada, e você pode ajustar o rigor
configurando o limiar da pontuação de correspondência de
nome no Console, tanto para fluxos de documento de
identidade quanto de Comprovante de endereço.
example: John
x-readme-id: '1.0'
last_name:
type: string
description: >-
Sobrenome do usuário. Por exemplo, `Doe`. A
correspondência usa comparação aproximada, e você pode
ajustar o rigor configurando o limiar da pontuação de
correspondência de nome no Console, tanto para fluxos de
documento de identidade quanto de Comprovante de
endereço.
example: Doe
x-readme-id: '1.1'
date_of_birth:
type: string
format: date
description: >-
Data de nascimento do usuário no formato YYYY-MM-DD. Por
exemplo, `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 do usuário. Deve ser 'M', 'F' ou null.
example: M
x-readme-id: '1.3'
nationality:
type: string
description: >-
Código ISO 3166-1 alpha-3 que representa o país de
origem do solicitante. Por exemplo, `USA`. Consulte a
[lista completa de códigos de país
compatíveis](https://docs.didit.me/pt-br/core-technology/id-verification/supported-documents-id-verification#documentos-aceitos-por-país).
example: USA
x-readme-id: '1.4'
country:
type: string
description: >-
Código ISO 3166-1 alpha-3 usado como alternativa nas
verificações de divergência de país tanto da Verificação
de identidade quanto do Comprovante de endereço.
Obrigatório quando `address` é informado e nem
`id_country` nem `poa_country` estão definidos.
example: USA
x-readme-id: 1.4.1
id_country:
type: string
description: >-
Código ISO 3166-1 alpha-3 que representa o país esperado
do documento de identidade do solicitante, que pode ser
diferente da nacionalidade. Por exemplo, `GBR`. Tem
prioridade sobre `country` nas verificações de
divergência de país da verificação de identidade.
Consulte a [lista completa de códigos de país
compatíveis](https://docs.didit.me/pt-br/core-technology/id-verification/supported-documents-id-verification#documentos-aceitos-por-país).
example: GBR
x-readme-id: '1.5'
poa_country:
type: string
description: >-
Código ISO 3166-1 alpha-3 que representa o país esperado
do documento de Comprovante de endereço. Por exemplo,
`USA`. Tem prioridade sobre `country` nas verificações
de divergência de país do comprovante de endereço.
Consulte a [lista completa de códigos de país
compatíveis](https://docs.didit.me/pt-br/core-technology/id-verification/supported-documents-id-verification#documentos-aceitos-por-país).
example: USA
x-readme-id: 1.5.1
address:
type: string
description: >-
O endereço em formato legível, com o máximo de
informações possível. Por exemplo, `123 Main St, San
Francisco, CA 94105, USA`. Quando informado, você também
deve enviar `country` ou `poa_country`; caso contrário,
a requisição falha com `400`.
example: 123 Main St, San Francisco, CA 94105, USA
x-readme-id: '1.6'
identification_number:
type: string
description: >-
O número do documento, número pessoal ou número fiscal
do usuário. Por exemplo, `123456789`.
example: '123456789'
x-readme-id: '1.7'
ip_address:
type: string
description: >-
Endereço IP esperado para a sessão, em formato IPv4 ou
IPv6. Se o endereço IP real for diferente desse valor,
um aviso será registrado. Por exemplo, `192.168.1.100`
ou `2001:db8::1`.
example: 192.168.1.100
x-readme-id: '1.8'
expected_document_types:
type: array
description: >-
Restringe os tipos de documento que o usuário pode
apresentar durante a etapa de verificação de identidade
(OCR). Quando definido, a tela de seleção de documento
mostra apenas os tipos solicitados, e o
`documents_allowed` retornado é filtrado de acordo. Os
valores não diferenciam maiúsculas de minúsculas e são
deduplicados; valores desconhecidos são rejeitados com
`400`. Códigos permitidos: `P` (passaporte), `ID`
(documento nacional de identidade), `DL` (carteira de
motorista), `RP` (autorização de residência), `HIC`
(cartão de plano de saúde), `TC` (cartão fiscal), `SSC`
(cartão de seguridade 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ão social esperada da empresa que está sendo
verificada. Por exemplo, `Tesco PLC`. Pré-preenche o
campo de nome da empresa na busca no registro em fluxos
de Verificação de empresas (KYB); quando
`registration_number` também é informado, a consulta ao
registro combina os dois identificadores. Ignorado em
fluxos de KYC.
example: Tesco PLC
x-readme-id: '1.10'
registry_country:
type: string
maxLength: 10
description: >-
Código ISO 3166-1 alpha-2 do país em cujo registro de
empresas a empresa está registrada. Por exemplo, `GB`.
Onde os registros de empresas operam em nível estadual
ou provincial, acrescente o código de subdivisão ISO
3166-2 no formato `XX-YY`: `US-CA` aponta para o
registro da Califórnia. Mesmo formato de `country_code`
na [KYB Registry Search
API](https://docs.didit.me/pt-br/standalone-apis/kyb-registry-search).
Pré-seleciona o país do registro em fluxos de
Verificação de empresas (KYB); é ignorado em fluxos de
KYC.
example: US-CA
x-readme-id: '1.11'
registration_number:
type: string
maxLength: 100
description: >-
Número de registro esperado da empresa no registro de
empresas. Por exemplo, `00445790`. Pré-preenche o campo
de número de registro na busca no registro em fluxos de
Verificação de empresas (KYB); quando `company_name`
também é informado, a consulta ao registro combina os
dois identificadores. Ignorado em fluxos de KYC.
example: '00445790'
x-readme-id: '1.12'
x-readme-id: '0.5'
portrait_image:
type: string
format: byte
description: >-
Imagem de retrato do rosto do usuário final codificada em
Base64 (máx. 2MB; JPEG, PNG, WebP ou TIFF). Usada como
imagem de referência para comparação com a captura de prova
de vida quando o fluxo é um fluxo `Biometric Authentication`
com a Correspondência facial habilitada, ou qualquer fluxo
baseado em grafo em que a Correspondência facial é executada
antes da Verificação de identidade (OCR). Opcional quando o
usuário de `vendor_data` já tem uma imagem facial
armazenada: a Didit a reutiliza automaticamente, escolhida
nesta ordem de prioridade: rosto da prova de vida aprovada,
foto do chip do passaporte eletrônico, retrato do documento
de identidade, rosto de perfil cadastrado manualmente
(somente rostos de sessões aprovadas ou rostos que você
mesmo cadastrou são reutilizados). Quando fornecida,
`portrait_image` sempre tem precedência sobre o rosto
armazenado. Se for omitida e não houver rosto armazenado (ou
se `vendor_data` não for enviado), a criação da sessão falha
com `400`. Ignorada para outros tipos de fluxo.
example: >-
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=
x-readme-id: '0.6'
sandbox_scenario:
type: string
description: >-
Slug de cenário exclusivo do sandbox. É aceito somente
quando a chave de API pertence a uma aplicação em modo
sandbox e é rejeitado em aplicações em produção. Quando
definido, o fluxo de criação aplica os valores mágicos
incluídos no cenário aos campos de entrada da sessão
(contact_details, expected_details), para que os provedores
simulados reproduzam o resultado do cenário por meio do
pipeline real do fluxo. Consulte o catálogo de cenários em
GET /v1/sandbox/scenarios/ ou em [Sandbox e dados de
teste](/pt-br/integration/sandbox-testing). Você também pode
armar (ou rearmar) um cenário após a criação via POST
/v3/session/{sessionId}/sandbox/arm/, desde que a sessão
ainda esteja `Not Started`. Para consultas sem documento,
use `lookup_partial_match`, `lookup_no_match` ou
`lookup_provider_error` para testar o limite de tentativas
configurado e o fallback. Para carteiras de identidade, use
`wallet_cancelled`, `wallet_timeout` ou
`wallet_provider_error`; `approve` simula uma carteira
verificada. Todas as carteiras do catálogo podem ser
testadas no sandbox, inclusive esquemas indisponíveis em
aplicações em produção. Tentativas simuladas não são
cobradas.
example: decline_document_expired
sign:
type: object
description: >-
Entrada de assinatura eletrônica para esta sessão.
`documents` são os documentos a assinar, para um fluxo de
verificação (workflow) cuja etapa de Assinatura eletrônica
recebe documentos da sessão (`signature_documents_source`
`session` ou `both`): até 20 documentos e 50 MB no total.
`field_values` preenche os campos cujo `prefill` é
`api.`, tanto nos documentos do fluxo quanto nos da
sessão. Criar novamente uma sessão para o mesmo
`workflow_id` e `vendor_data` retorna a sessão pendente; se
essa chamada enviar `sign`, seus documentos, campos e
valores devem ser idênticos aos da primeira, e qualquer
diferença retorna `400` com `{"sign":
"signature_document_changed"}`. Consulte [Documentos de
assinatura
eletrônica](/pt-br/sessions-api/create-session#documentos-de-assinatura-eletrônica).
properties:
documents:
type: array
minItems: 1
maxItems: 20
items:
$ref: '#/components/schemas/SessionSignDocument'
field_values:
type: object
description: >-
Valores indexados pela `` de cada fonte de
preenchimento prévio `api.`: strings de 1 a 500
caracteres para campos `text` e `data`, booleanos para
um `checkbox`. Retorna `400` com `field_value_unknown`
para uma chave que nenhum campo usa,
`field_value_missing` para um campo obrigatório sem
valor e `field_value_invalid` para um valor que não
passa na validação do seu campo.
additionalProperties:
oneOf:
- type: string
minLength: 1
maxLength: 500
- type: boolean
example:
credit_limit: 3,000 EUR
user_state:
type: string
maxLength: 16
description: >-
Onde a pessoa mora, quando você souber: um código de
subdivisão ISO 3166-2 (`US-IL`, `ES-M`) ou um código ou nome
de estado dos EUA (`IL`, `Illinois`). Um estado cuja lei
exige consentimento biométrico explícito (Illinois, Texas,
Colorado) faz o fluxo de verificação solicitá-lo antes de
capturar um rosto, com o gatilho `declared_state`. Um valor
não reconhecido retorna `400`. Consulte [Consentimento
biométrico](/pt-br/getting-started/biometric-consent).
example: US-IL
biometric_consent:
type: object
description: >-
Consentimento biométrico explícito que você já coletou da
pessoa. Ele atende ao requisito, de modo que o fluxo de
verificação não o solicita novamente, e a decisão o registra
como `status: "given"` com o gatilho `customer_collected`.
Uma resposta que a pessoa já deu no fluxo nunca é
substituída. Consulte [Consentimento
biométrico](/pt-br/getting-started/biometric-consent).
required:
- given_at
- text_version
properties:
given_at:
type: string
format: date-time
description: >-
Quando a pessoa deu consentimento biométrico explícito
(ISO 8601). Não pode estar no futuro.
text_version:
type: string
maxLength: 64
description: >-
Id da versão do texto de consentimento que a pessoa
aceitou, nos seus próprios 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 do fluxo bem-sucedido de uma sessão de
Verificação de usuários (KYC)
description: >-
Chamada de criação realista que usa todos os campos definidos
com frequência: seleção do fluxo de verificação (workflow),
vínculo com o fornecedor, roteamento de callback, metadados,
localidade, preenchimento prévio de contato e dados esperados
do usuário. Copie e cole diretamente no exemplo de cURL acima.
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 do cenário de sucesso para uma sessão de Verificação
de empresas (KYB)
description: >-
Mesmo formato da chamada de KYC: é o `workflow_id` que torna a
sessão KYB. `vendor_data` normalmente referencia a empresa no
seu sistema e `contact_details.email` se destina ao
representante legal que concluirá o fluxo. `expected_details`
aceita os campos da empresa (`company_name`,
`registry_country`, `registration_number`), que preenchem
previamente a busca no registro de empresas; campos de pessoa
e `contact_details.phone` são ignorados em fluxos 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: >-
Sessão criada (ou retornada, se já existir uma sessão não concluída
com o mesmo `vendor_data` na versão publicada mais recente do
fluxo). A resposta é a sessão serializada, incluindo a `url` da
verificação hospedada para a qual o usuário deve ser redirecionado.
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 da sessão de verificação. Use este id
ao chamar `GET /v3/session/{sessionId}/decision/`.
example: 11111111-2222-3333-4444-555555555555
session_number:
type: integer
description: >-
Número sequencial e fácil de ler atribuído à sessão dentro
da sua aplicação. Útil para suporte e painéis.
example: 43762
session_token:
type: string
description: >-
Token seguro para URL de 12 caracteres que autoriza o
usuário final a acessar o fluxo de verificação hospedado
em `url`. Válido até a sessão expirar. Trate-o como um
segredo: qualquer pessoa que o tenha pode abrir o fluxo de
verificação desta sessão.
example: 3FaJ9wLqX2Mz
url:
type: string
format: uri
description: >-
URL de verificação hospedada para a qual o usuário final
deve ser redirecionado. A URL incorpora o `session_token`
e, se configurado, usa seu domínio de marca própria.
Quando a requisição inclui `language`, a URL contém um
segmento de caminho com o idioma:
`https://verify.didit.me/{language}/session/{session_token}`
(por exemplo, `/es/session/...`); sem `language`, o
segmento é omitido.
example: https://verify.didit.me/session/3FaJ9wLqX2Mz
vendor_data:
type: string
nullable: true
description: >-
Identificador que você passou na requisição para vincular
a sessão a um usuário ou empresa no seu próprio sistema.
Retornado exatamente como enviado. Null quando não
informado.
example: user-123
metadata:
description: >-
Payload JSON arbitrário que você armazenou com a sessão no
momento da criação. Devolvido literalmente — qualquer
valor JSON que você enviou (objeto, string, número, array)
é retornado como está, embora um objeto JSON seja
recomendado. Não é exibido ao usuário final. Sempre
presente nas respostas; `null` quando não fornecido no
momento da criação.
example:
user_type: premium
account_id: ABC123
tags:
type: array
items:
type: string
description: As tags da sessão, por nome.
example:
- VIP
- ONBOARDING Q4
status:
type: string
enum:
- Not Started
- In Progress
- Approved
- Declined
- In Review
- Expired
- Abandoned
- Kyc Expired
- Resubmitted
- Awaiting User
description: >-
Status atual da sessão. Sessões recém-criadas retornam
`Not Started`. Se já existia uma sessão não finalizada
para o mesmo `vendor_data` na versão publicada mais
recente do fluxo, o status retornado reflete essa sessão
existente.
example: Not Started
callback:
type: string
format: uri
nullable: true
description: >-
URL de redirecionamento final para a qual o usuário é
enviado após concluir o fluxo. A Didit acrescenta
`?verificationSessionId={session_id}&status={status}` a
essa URL. Quando não é informada na requisição, usa a URL
de retorno configurada no fluxo de verificação (workflow);
`null` quando nenhuma das duas está definida. Quando a
aplicação tem domínios permitidos e essa URL é uma URL web
fora deles (por exemplo, um padrão do fluxo definido antes
de a lista mudar), o fluxo hospedado não redireciona o
usuário para ela.
example: https://example.com/verification/callback
workflow_id:
type: string
format: uuid
description: >-
Identificador estável do fluxo em que esta sessão é
executada. É sempre o identificador estável de grupo do
fluxo: mesmo que você tenha referenciado o UUID de uma
versão específica do fluxo na requisição (busca
retrocompatível), a resposta traz o `workflow_id` estável.
Use-o para correlacionar a sessão com o fluxo que você
configurou no Console.
example: 11111111-2222-3333-4444-555555555555
workflow_version:
type: integer
description: >-
Número da versão publicada do fluxo à qual a sessão foi
fixada na criação. A Didit resolve o `workflow_id` para a
versão publicada mais recente do fluxo quando a sessão é
criada, e a sessão continua executando essa versão mesmo
que o fluxo seja republicado depois.
example: 3
examples:
KYC session:
summary: Sessão KYC criada
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: Sessão KYB criada
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: >-
Requisição inválida: o payload não passou na validação
(`workflow_id` ausente ou desconhecido, `language` inválido,
`vendor_data` na lista de bloqueio, `portrait_image` malformado,
`address` sem `country`/`poa_country`, `sandbox_scenario` inválido,
documentos `sign`, campos ou valores que a etapa de Assinatura
eletrônica do fluxo recusa, como `signature_document_not_supported`,
`signature_document_conversion_failed`, `field_anchor_not_found` ou
`field_value_missing` etc.) ou sua organização não tem créditos
suficientes para iniciar a sessão.
O corpo é um objeto cujas chaves são os nomes dos campos com
problema (ou `detail` para erros que não são de campo). Os valores
são um **array de strings** para falhas de validação de entrada (por
exemplo, campo obrigatório ausente, idioma inválido, imagem de
retrato grande demais) e uma **string simples** para falhas
detectadas durante a criação da sessão (`workflow_id` desconhecido,
`vendor_data` na lista de bloqueio, nenhuma face de referência
disponível para um fluxo de Correspondência facial). Trate os dois
formatos.
content:
application/json:
schema:
type: object
additionalProperties: true
properties:
detail:
type: string
description: >-
Mensagem de erro legível para erros que não são de campo
(por exemplo, créditos insuficientes). Falhas no nível do
campo usam o nome do campo como chave, com um valor de
string ou array de strings.
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 obrigatório omitido (formato de array de strings)
value:
workflow_id:
- This field is required.
Invalid workflow_id:
summary: workflow_id desconhecido (formato de string simples)
value:
workflow_id: Invalid workflow_id.
Insufficient credits:
summary: A organização está sem 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á na lista de bloqueio
value:
vendor_data: >-
This user or business has been blocked and cannot create
new verification sessions.
Portrait image too large:
summary: portrait_image falha na validação de tamanho
value:
portrait_image:
- Image size exceeds 2MB.
No stored face for vendor_data:
summary: >-
Fluxo de Correspondência facial sem portrait_image e sem
rosto armazenado para o usuário 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: >-
Fluxo de Correspondência facial sem portrait_image e sem
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: >-
Falha de autenticação ou autorização. Uma chave incorreta, revogada
ou expirada retorna `401`. O endpoint retorna `403` quando o
cabeçalho `x-api-key` está ausente ou quando a chave de API é
válida, mas o cliente não tem permissão para criar sessões nesta
aplicação (por exemplo, a chave de API pertence a uma organização
diferente). Essas falhas compartilham o corpo `{"detail": "You do
not have permission to perform this action."}`. Verifique se o
cabeçalho `x-api-key` está presente e pertence à aplicação
pretendida, obtenha novamente a chave de API da aplicação pela [Auth
API](/pt-br/auth-api/get-credentials), se necessário, e tente
novamente.
**Aplicação excluída:** durante alguns minutos após a exclusão de
uma aplicação, uma requisição feita com uma de suas chaves de API
pode responder `{"detail": "This application was deleted.", "code":
"application_deleted"}`. Não tente novamente: a aplicação e suas
chaves de API não existem mais. Passados esses minutos, a chave é
recusada como qualquer outra chave invá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 legível por máquina, presente apenas em algumas
falhas. `application_deleted`: a chave de API pertence a
uma aplicação que foi excluída.
example: application_deleted
required:
- detail
examples:
Missing or invalid API key:
summary: Nenhum cabeçalho `x-api-key` ou chave de API inválida
value:
detail: You do not have permission to perform this action.
No permission:
summary: O cliente não pode criar sessões
value:
detail: You do not have permission to perform this action.
Application deleted:
summary: Chave de API de uma aplicação excluída
value:
detail: This application was deleted.
code: application_deleted
'429':
description: >-
Limite de requisições excedido: mais de 600 requisições de criação
de sessão em uma janela de 60 segundos vindas da mesma chave de API
/ IP. Verifique `Retry-After` e aguarde antes de tentar novamente.
**Observação:** o código-fonte também define um
`FREE_SESSION_RATE_LIMIT` de 10 chamadas/minuto junto com
`PAID_SESSION_RATE_LIMIT=600` (`sessions/serializers/session.py`),
mas esse teto do plano gratuito **não é aplicado a este endpoint
V3**: o middleware de limite de requisições aplica o
`SESSION_CREATE_RATE_LIMIT` de 600/min independentemente do plano.
600/min é o único limite que você pode atingir aqui.
headers:
Retry-After:
description: >-
Segundos que o chamador deve aguardar antes de tentar novamente
a requisição.
schema:
type: integer
minimum: 1
example: 42
X-RateLimit-Limit:
description: >-
Número máximo de requisições permitidas na janela atual de 60
segundos para o limite que foi excedido (600 para criação de
sessão). Ausente na variante de cota do sandbox.
schema:
type: integer
example: 600
X-RateLimit-Remaining:
description: >-
Número de requisições ainda permitidas na janela atual para o
limite excedido. Ausente na variante de cota do sandbox.
schema:
type: integer
minimum: 0
example: 0
X-RateLimit-Reset:
description: >-
Segundos desde a época Unix (UTC) em que a janela atual do
limite de requisições é reiniciada. Ausente na variante de cota
do sandbox.
schema:
type: integer
minimum: 0
example: 1747497600
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
Explicação legível da violação do limite de requisições.
Use esta mensagem para identificar qual dos três limites
foi atingido.
example: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
examples:
Session-create limit:
summary: Mais de 600 requisições de criação de sessão por minuto
value:
detail: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
Sandbox session quota:
summary: A aplicação de sandbox excedeu 500 sessões em 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 exibido ao signatário. O padrão é `file_name`.
file_name:
type: string
minLength: 1
maxLength: 255
description: Nome do arquivo, terminando em `.pdf` ou `.docx`.
content_base64:
type: string
format: byte
description: >-
O arquivo, codificado em base64. Um PDF pode ter até 20 MB e 100
páginas, sem senha, scripts ou arquivos anexados. Um arquivo Word
(`.docx`) pode ter até 20 MB e é convertido em PDF durante a
requisição, em no máximo 25 segundos; o PDF então tem os mesmos
limites. Até 5 arquivos Word por sessão. Um arquivo Word com macros,
controle de alterações, links para conteúdo externo ou objetos
incorporados é recusado com `signature_document_not_supported`, e um
que não pode ser convertido retorna
`signature_document_conversion_failed`, cada um com um `reason`.
fields:
type: array
description: >-
Campos opcionais a serem posicionados neste documento, até 200. As
páginas e posições se referem ao PDF ou, no caso de um arquivo Word,
ao PDF convertido. Sem campos, o signatário lê o documento e
concorda com ele.
items:
$ref: '#/components/schemas/SignatureField'
maxItems: 200
SignatureField:
type: object
description: >-
Um campo a ser colocado em um documento da sessão: qual signatário o
preenche, como e onde. Informe uma posição (`page`, `x`, `y`, `width` e
`height`) ou um `anchor`. As posições são frações da página conforme ela
é exibida, a partir do canto superior esquerdo, arredondadas para 4
casas decimais, e o campo deve caber dentro da página. Um documento
aceita até 200 campos e um signatário até 500, e toda função com campos
em um documento precisa de um campo `signature` ou `initials` nele.
Consulte [Campos no
documento](/pt-br/core-technology/electronic-signature/overview#campos-no-documento).
required:
- key
- type
properties:
key:
type: string
pattern: ^[a-z][a-z0-9_]{0,63}$
description: >-
Dá nome ao campo nos resultados e em `sign.field_values`. Único
dentro do documento.
type:
type: string
enum:
- signature
- initials
- full_name
- date_signed
- text
- checkbox
- email
- data
description: >-
O que o campo contém. O signatário aplica a `signature` e as
`initials` que adotou, digita em `text`, marca uma `checkbox` e
digita um `email` quando a sessão não tem e-mail verificado. A Didit
preenche `full_name` (o nome verificado), `date_signed` (a data da
assinatura, no fuso horário do signatário), `data` (a partir de
`prefill`) e um `email` verificado, e os exibe como somente leitura.
Não há um tipo seletor de data: use `text`.
role:
type: string
enum:
- verified_person
- legal_representative
- key_people
description: >-
Quem preenche o campo, com os valores de `signature_signer`. Uma
etapa preenche e carimba apenas os campos do seu próprio signatário.
O padrão é o signatário da etapa.
page:
type: integer
minimum: 1
description: >-
Número da página, de 1 até o total de páginas do documento. Para um
documento Word, uma página do PDF convertido.
x:
type: number
minimum: 0
maximum: 1
description: Borda esquerda, como fração da largura da página.
'y':
type: number
minimum: 0
maximum: 1
description: Borda superior, como fração da altura da página.
width:
type: number
minimum: 0.02
maximum: 1
description: >-
Largura, como fração da largura da página. Uma assinatura tem pelo
menos `0.12` de largura.
height:
type: number
minimum: 0.012
maximum: 1
description: >-
Altura, como fração da altura da página. Uma assinatura tem pelo
menos `0.035` de altura.
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: Exibido ao signatário e nos resultados. O valor padrão vem do tipo.
placeholder:
type: string
nullable: true
maxLength: 80
description: Somente `text` e `email`.
validation:
$ref: '#/components/schemas/SignatureFieldValidation'
prefill:
type: string
nullable: true
description: >-
De onde vem o 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.`
(uma chave do `metadata` da sessão) ou `api.` (uma chave de
`sign.field_values`). Obrigatório para `data`. `full_name` sempre
usa `identity.full_name` e `email` usa `contact.email`. Os valores
dos campos `data`, `full_name` e `email` verificado ficam fixos
quando o signatário começa a assinar.
editable_when_prefilled:
type: boolean
default: false
description: >-
Somente `text` e `email`: o signatário pode alterar um valor
pré-preenchido.
checked_by_default:
type: boolean
default: false
description: 'Somente `checkbox`: a caixa começa marcada.'
date_format:
type: string
enum:
- DD/MM/YYYY
- MM/DD/YYYY
- YYYY-MM-DD
- D MMMM YYYY
default: DD/MM/YYYY
description: Somente `date_signed`.
SignatureFieldAnchor:
type: object
description: >-
Posiciona um campo por um trecho de texto no documento em vez de uma
posição. A Didit não remove o texto do PDF, então escreva-o na mesma cor
do fundo da página. Quando o texto não é encontrado, a chamada retorna
`400` com `field_anchor_not_found`. Consulte [Posicionar campos por
texto
âncora](/pt-br/sessions-api/create-session#posicionar-campos-por-texto-âncora).
required:
- text
properties:
text:
type: string
minLength: 1
maxLength: 64
description: Texto buscado no documento. Para um arquivo Word, no PDF convertido.
occurrence:
type: string
enum:
- first
- all
default: first
description: >-
`all` coloca um campo por correspondência; as chaves após a primeira
recebem `_2`, `_3` e assim por diante.
offset_x:
type: number
description: Somado à borda esquerda do texto, como fração da largura da página.
offset_y:
type: number
description: Somado à borda superior do texto, como fração da altura da página.
width:
type: number
minimum: 0.02
maximum: 1
description: Largura do campo, como fração da largura da página.
height:
type: number
minimum: 0.012
maximum: 1
description: Altura do campo, como fração da altura da página.
SignatureFieldValidation:
type: object
nullable: true
description: >-
Regras para o valor de um campo `text`. A pré-visualização do console, o
fluxo de assinatura e a API aplicam as mesmas regras.
properties:
kind:
type: string
enum:
- any
- letters
- number
- email
- pattern
description: >-
`letters`: letras de qualquer alfabeto, espaços, hífens e
apóstrofos. `number`: dígitos com um separador decimal opcional.
`pattern`: o valor deve corresponder a `pattern`.
min_length:
type: integer
minimum: 0
maximum: 500
description: De `0` até `max_length`.
max_length:
type: integer
minimum: 1
maximum: 500
default: 120
pattern:
type: string
nullable: true
minLength: 1
maxLength: 200
description: >-
Obrigatório com `kind: "pattern"`. Uma expressão regular à qual o
valor inteiro deve corresponder. Lookarounds e referências
retroativas (backreferences) não são suportados.
message:
type: string
nullable: true
maxLength: 120
description: Exibido ao signatário no lugar do erro padrão.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
Chave de API da sua aplicação, em Developers -> API keys no Business
Console. A chave principal tem acesso total. Uma chave nomeada pode ter
escopo restrito: nenhum acesso, leitura ou escrita por recurso, limitada
a alguns fluxos ou a sessões aprovadas, a uma lista de endereços IP e a
uma data de validade. 401 significa que a chave está errada, revogada ou
expirada; 403 significa que nenhuma chave foi enviada, que a chave não
tem acesso a este recurso ou ação, ou que a requisição veio de um
endereço fora da sua lista de IPs; 404 em uma rota de sessão significa
que a sessão está fora dos fluxos ou status da chave. Uma chave sem
acesso a mídia recebe URLs de imagem, vídeo e PDF como null, e uma chave
sem permissão de escrita em sessões recebe links e tokens de sessão como
null. Consulte https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.