> ## 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: iniciar verificação KYC ou KYB
> POST /v3/session/ inicia a verificação. Endpoint KYC e KYB unificado da Didit, pago por utilização, inferência abaixo de 2s, $10 grátis/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 utilizadores e de Verificação de empresas. O **tipo do fluxo** determina qual delas é criada:- Passe o `workflow_id` de um **fluxo de KYC** → é criada uma sessão de Verificação de utilizadores (KYC). Resposta `session_kind: "user"`.
- Passe 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 na consola em *Workflows → Create workflow*. Um fluxo é de KYC ou de KYB no momento da criação; depois não é possível mudar de tipo.## Exemplos> [tab] Verificação de utilizadores (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 um passo de [Assinatura eletrónica](https://docs.didit.me/pt/core-technology/electronic-signature/overview.md) que recebe os documentos da sessão (`signature_documents_source` definido como `session` ou `both`), envie-os em `sign.documents`. Cada documento é o ficheiro em base64, para que a Didit nunca tenha de o obter a partir de um 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` | Apresentado ao signatário. 1 a 255 caracteres. Predefinido como `file_name`. |
| `file_name` | Obrigatório. Termina em `.pdf` ou `.docx`. 1 a 255 caracteres. |
| `content_base64` | Obrigatório. Um PDF pode ter até 20 MB e 100 páginas, sem palavra-passe, scripts nem ficheiros anexados. Um ficheiro Word pode ter até 20 MB e é convertido em PDF durante o pedido, em no máximo 25 segundos; o PDF tem depois os mesmos limites. Até 5 ficheiros Word por sessão. |
| `fields` | Opcional. Até 200 [campos](https://docs.didit.me/pt/core-technology/electronic-signature/overview.md#campos-no-documento) a colocar no documento, na estrutura de campo sem `id`. Cada campo precisa de um `key` e de um `type`, e de uma posição (`page`, `x`, `y`, `width` e `height`) ou de uma [`anchor`](#colocar-campos-por-texto-de-âncora). `role` predefine-se para o signatário do passo, e `required` e `label` predefinem-se a partir do tipo. A Didit define `position` a partir do local onde o campo se encontra. As páginas e as posições referem-se ao PDF, ou ao PDF convertido no caso de um ficheiro Word. |Sem `fields`, o signatário lê o documento e concorda com ele.### Colocar campos por texto de âncoraEm vez de uma posição, um campo pode ter uma `anchor`: um trecho de texto no documento que marca onde o campo fica. As âncoras são indicadas para documentos que gera para cada sessão, por exemplo a partir de um modelo Word. Nos documentos do fluxo, coloque os campos na consola.| Propriedade de `anchor` | Regras |
| - | - |
| `text` | 1 a 64 caracteres, pesquisados no texto do documento. No caso de um ficheiro Word, no PDF convertido. |
| `occurrence` | `first` (predefinido) coloca um campo na primeira correspondência. `all` coloca um campo por correspondência, e as chaves a seguir à 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 da âncora somado a estes deslocamentos. |
| `width`, `height` | O tamanho do campo, como frações da página. |Quando o texto não existe no documento, a chamada devolve `400` com `field_anchor_not_found` e a chave do campo. A Didit não remove o texto da âncora do PDF, por isso escreva-o na mesma cor do fundo da página.### Valores dos campos`sign.field_values` define o valor de cada campo cujo `prefill` é `api.`, tanto nos documentos do fluxo como nos documentos da sessão. É um objeto indexado por esses nomes ``. Os valores são cadeias de 1 a 500 caracteres para os 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 ocorre |
| - | - |
| `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 cumpre a [validação](https://docs.didit.me/pt/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 devolve `400` com um erro de `sign` quando:- O fluxo não tem passo de Assinatura eletrónica.
- Enviou `sign.documents` e o passo só aceita documentos do fluxo.
- O passo aceita apenas documentos da sessão e não enviou nenhum, ou não tem documentos do fluxo e não enviou nenhum.
- Um documento é demasiado grande, não é base64 válido ou não é um ficheiro suportado.
- Um ficheiro Word é recusado com `signature_document_not_supported`, ou não pode ser convertido e devolve `signature_document_conversion_failed`, cada um com o `reason` indicado em [Ficheiros suportados](https://docs.didit.me/pt/core-technology/electronic-signature/overview.md#ficheiros-suportados).
- Um campo é inválido, a sua âncora não é encontrada (`field_anchor_not_found`), ou um [valor de campo](#valores-dos-campos) é recusado.Voltar a chamar a operação de criação para o mesmo `workflow_id` e `vendor_data` devolve a sessão pendente. Se essa chamada enviar `sign`, os seus documentos, campos e valores de campos têm de ser idênticos aos da primeira (mesma ordem, títulos, nomes de ficheiros, conteúdo, campos e valores). Qualquer diferença devolve `400` com `{"sign": "signature_document_changed"}`: use um `vendor_data` diferente ou aguarde até que a sessão pendente termine.## Testes com cenários de sandboxNuma 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 análise), sem contactar fornecedores reais nem tocar no 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 ainda não conhecer o resultado no momento da criação, configure (ou volte a configurar) o cenário mais tarde através de `POST /v3/session/{session_id}/sandbox/arm/`, desde que a sessão ainda esteja no estado `Not Started`: o seletor de cenários pré-fluxo do fluxo alojado usa este mesmo endpoint. Consulte [Sandbox e dados de teste](https://docs.didit.me/pt/integration/sandbox-testing.md) para o catálogo completo de cenários, o registo de valores mágicos e o formato do pedido e da resposta do endpoint de configuração.## O `vendor_data` associa a sessão a uma entidade- Para fluxos de KYC: associa-se a uma [entidade de utilizador](https://docs.didit.me/pt/entities/users/overview.md). Se o utilizador não existir, é criado automaticamente.
- Para fluxos de KYB: associa-se a uma [entidade empresarial](https://docs.didit.me/pt/entities/businesses/overview.md). Criada automaticamente se for nova.Saiba mais em [associação de dados do fornecedor](https://docs.didit.me/pt/entities/vendor-data-linking.md).## Consentimento biométrico em Illinois, no Texas e no ColoradoO fluxo alojado e o SDK nativo 4.10.0 ou posterior podem mostrar um passo de consentimento biométrico explícito antes da primeira captura facial, consoante o modo de consentimento da aplicação e o local onde a pessoa se encontra. Dois campos opcionais alimentam essa decisão:- `user_state`: onde a pessoa reside, quando o souber (`US-IL`, `IL` ou `Illinois`). No modo Automático, um estado abrangido faz com que o fluxo peça o consentimento.
- `biometric_consent`: um objeto com `given_at` e `text_version`, para consentimento que já recolheu. O fluxo não volta a pedir.Os SDK nativos anteriores à versão 4.10.0 não conseguem mostrar este passo: as respetivas sessões funcionam como antes e a decisão indica que o consentimento não foi recolhido. Consulte [Consentimento biométrico](https://docs.didit.me/pt/getting-started/biometric-consent.md).## Importante: a divulgação e o consentimento continuam a ser feitos no seu produto`Create Session` gera um URL de verificação e um token de sessão. Por si só, **não** prova que mostrou ao utilizador as informações fornecidas ao utilizador ou que obteve o consentimento exigido pelo seu caso de utilização específico.Se iniciar uma sessão Didit a partir da sua própria aplicação, website, wrapper de SDK ou fluxo com marca branca, deve tratar da componente jurídica na sua própria experiência de utilização antes de o utilizador iniciar a captura.## Lista de verificação recomendada antes da verificação1. Informe o utilizador de que **a sua empresa** está a pedir a verificação e de que a **Didit** é o fornecedor de verificação / subcontratante que suporta o fluxo.
2. Ligue ao **seu aviso de privacidade** e a quaisquer termos jurídicos do responsável pelo tratamento que se apliquem ao percurso.
3. Ligue ao [Aviso de Privacidade de Verificação](https://didit.me/terms/verification-privacy-notice) da Didit e aos [Termos do Utilizador Final para Verificação de Identidade](https://didit.me/terms/identity-verification).
4. Se o seu fluxo incluir captura de documento, captura de selfie, prova de vida ou dados biométricos, recolha **consentimento explícito e afirmativo** sempre que a lei aplicável ou a sua posição jurídica o exija.
5. Se utilizar uma interface personalizada, um domínio próprio ou um percurso apenas por API, apresente estas informações no seu próprio produto antes de enviar o utilizador para o fluxo da Didit.
6. Guarde o seu próprio registo do texto do aviso ou do consentimento, da data e hora e dos metadados relacionados, se a sua equipa jurídica exigir um rasto de auditoria.> [!WARNING]
>
> As exigências legais variam consoante a jurisdição. A personalização com marca branca não elimina o papel da Didit no fluxo de verificação. Reveja a sua implementação com um advogado antes do lançamento se operar em jurisdições com regras específicas para dados biométricos.
## OpenAPI
````yaml pt/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: >-
Crie uma sessão de Verificação de utilizadores (KYC) ou de Verificação
de empresas (KYB) e receba um `url` de verificação alojado juntamente
com um `session_token` para redirecionar o seu utilizador final ou
incorporar a página para esse utilizador. O `workflow_id` seleciona
quais os passos de verificação a executar e se a sessão é de KYC ou de
KYB.
Chame este endpoint a partir do seu backend (nunca a partir do navegador
— a chave de API é um segredo) sempre que for necessário verificar um
utilizador ou empresa: no registo, antes de uma ação sensível ou quando
for necessária uma reverificação. Pré-requisitos: um fluxo publicado
(criado na página
[Workflows](https://docs.didit.me/pt/console/workflows) da Consola) e
uma chave de API da aplicação com créditos disponíveis. As aplicações em
sandbox ignoram a verificação de créditos.
**Idempotência:** quando `vendor_data` é fornecido e já existe uma
sessão não concluída (`Not Started`, `In Progress`, `Resubmitted` ou
`Awaiting User`) com o mesmo `vendor_data` na **versão publicada mais
recente do fluxo** (e essa sessão já possui um URL de verificação
alojado), a sessão existente é devolvida (ainda `201`) em vez de criar
uma duplicada — com o seu `callback` e `metadata` atualizados para os
novos valores fornecidos. Uma sessão não concluída criada numa versão
mais antiga do fluxo (uma que tenha sido entretanto republicada) **não**
é reutilizada; em vez disso, é criada uma nova sessão associada à versão
publicada mais recente. Sessões em `Approved`, `Declined`, `In Review`,
`Expired`, `Abandoned` ou `Kyc Expired` nunca são reutilizadas.
**Efeitos secundários:** o URL de verificação alojado é gerado e
armazenado; se `contact_details.send_notification_emails` for `true` e
for fornecido um e-mail, é enviado um e-mail de convite para
verificação. A sessão expira após o tempo de expiração da sessão
configurado no fluxo. Para 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 que define quais os passos de
verificação que a sessão irá executar. Os fluxos são criados
e geridos na página [Fluxos](/pt/console/workflows) da
Consola. O `workflow_id` também seleciona 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 para o utilizador a ser
verificado, como um UUID, e-mail ou ID de utilizador
interno. Este campo é utilizado para: (1) **Agrupamento de
utilizadores** — as sessões com o mesmo vendor_data são
associadas ao mesmo perfil de utilizador no separador
Utilizadores. (2) **Deteção de duplicados entre sessões** —
ao verificar rostos, documentos, números de telefone,
e-mails, endereços IP ou impressões digitais de dispositivos
duplicados, as sessões com o mesmo vendor_data são tratadas
como o mesmo utilizador e excluídas das correspondências.
Sem vendor_data, cada sessão é tratada como um utilizador
único e todos os potenciais duplicados são apresentados.
Recomendamos vivamente fornecer sempre um vendor_data para
reduzir o ruído na deteção de duplicados.
example: user-123
x-readme-id: '0.1'
multi_account_segment:
type: string
maxLength: 64
description: >-
Domínio de deteção de duplicados opcional dentro da sua
organização. As verificações de rostos duplicados comparam
esta sessão apenas com outras sessões que tenham o mesmo
segmento, para que bases de contas separadas (contas
pessoais e empresariais, ou uma por subcliente B2B) não
sinalizem uma pessoa que detenha legitimamente uma conta em
cada uma. Omita este campo para utilizar o domínio
predefinido único, que é o que todas as sessões utilizam
atualmente. A correspondência com a lista de bloqueio e a
lista de permissões ignora este campo.
example: business-accounts
callback:
type: string
description: >-
URL para redirecionar o utilizador após a conclusão da
verificação. A Didit anexa automaticamente
`verificationSessionId` e `status` (Approved, Declined, In
Review) como parâmetros de consulta. Esquemas de URL
personalizados (por exemplo, `myapp://`) são suportados para
callbacks móveis. Se omitido, é utilizado o `callback_url`
predefinido do fluxo. Quando a aplicação tem domínios
permitidos (`allowed_domains` em `PATCH /v3/webhook/`), um
callback `http` ou `https` deve pertencer a uma dessas
origens (mesmo esquema, anfitrião e porta), caso contrário o
pedido 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 aceites.
example: https://example.com/verification/callback
x-readme-id: '0.2'
callback_method:
type: string
description: >-
Determina que dispositivo deve processar o redirecionamento
para o URL de retorno fornecido. Utilize `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 callback.
Se alguma vez notar que o callback não está a ser acionado
de forma fiá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 guardado com a sessão e devolvido na
resposta e nos webhooks. Qualquer valor JSON é aceite
(objeto, string, número, array), mas recomenda-se um objeto
JSON de pares chave/valor. Não visível para o utilizador
final. Utilize-o para passar os seus próprios IDs de
correlação, variantes 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: >-
Etiquetas adicionadas à sessão quando esta é criada, por
nome. Até 10, cada uma com até 50 carateres. Os nomes não
diferenciam maiúsculas de minúsculas e são guardados em
maiúsculas. Um nome que ainda não exista na aplicação é
criado como uma nova etiqueta. As etiquetas são apresentadas
na sessão na consola, onde 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 apresentado ao utilizador
final durante a verificação. Se não for fornecido, o idioma
do navegador será detetado e utilizado automaticamente.
Consulte todos os idiomas suportados
[aqui](/pt/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 contacto do utilizador que podem ser
utilizadas para notificações, pré-preenchimento de
formulários de verificação e verificação de telefone. Isto
inclui o endereço de e-mail, o idioma preferido para
comunicações e o 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 utilizador (ex.:
"john.doe@example.com") que será utilizado durante o
passo de [Verificação de
e-mail](/pt/core-technology/email-verification/overview).
Se não for fornecido, o utilizador terá de o indicar
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 for verdadeiro e um e-mail for fornecido, a Didit
envia o e-mail inicial "Verifique a sua identidade" de
forma assíncrona quando a sessão de Verificação de
utilizadores (KYC) ou Verificação de empresas (KYB) for
criada. A Didit também envia notificações sobre o estado
da verificação de sessões que necessitam de revisão
manual para o endereço de e-mail fornecido (por exemplo,
de 'In Review' para 'Approved' ou 'Declined'). Isto
ajuda os utilizadores a regressarem à sua aplicação
assim que a verificação for concluída. Se tiver a marca
branca ativada para a sessão, o e-mail enviado terá
marca branca.
example: true
x-readme-id: '1.1'
email_lang:
type: string
description: >-
Código de idioma (ISO 639-1) para notificações por
e-mail. Controla o idioma de todas as comunicações por
e-mail (por exemplo, "en", "es", "fr"). Não existe um
valor predefinido guardado — quando omitido, o e-mail de
convite de verificação simplesmente reverte para inglês
(`en`) no momento do envio. O enum abaixo é um
instantâneo; a fonte de referência em tempo real para os
valores aceites é o documento de [idiomas
suportados](/pt/integration/supported-languages) —
consulte-o 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á utilizado durante o passo de
[Verificação de
telefone](/pt/core-technology/phone-verification/overview).
Se não for fornecido, o utilizador tem de o introduzir
durante o fluxo de verificação. Ignorado para fluxos de
Verificação de empresas (KYB). **Importante:** Este
número de telefone só é aplicado se for um número de
telefone E.164 válido. Se o número fornecido for
inválido ou não puder ser analisado, será ignorado e o
utilizador poderá introduzir qualquer número de telefone
válido durante o passo 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 utilizador utilizados para validação
cruzada com os dados extraídos do documento de identificação
do utilizador, Comprovativo de morada e outros passos de
verificação. As discrepâncias são apresentadas como avisos
na decisão; alguns campos (por exemplo, `id_country`,
`expected_document_types`) também alteram o fluxo
apresentado ao utilizador. Para fluxos de Verificação de
empresas (KYB), apenas os campos da empresa (`company_name`,
`registry_country`, `registration_number`) são utilizados —
pré-preenchem a pesquisa no registo de empresas para o
utilizador — e todos os campos a nível de 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: >-
Primeiro nome do utilizador. Por exemplo, `John`. A
correspondência utiliza comparação difusa (fuzzy) e pode
ajustar o nível de exigência configurando o limiar da
pontuação de correspondência de nomes na consola para os
fluxos de Documento de identificação e Comprovativo de
morada.
example: John
x-readme-id: '1.0'
last_name:
type: string
description: >-
Apelido do utilizador. Por exemplo, `Doe`. A
correspondência utiliza comparação difusa (fuzzy) e pode
ajustar o nível de exigência configurando o limiar da
pontuação de correspondência de nomes na consola para os
fluxos de Documento de identificação e Comprovativo de
morada.
example: Doe
x-readme-id: '1.1'
date_of_birth:
type: string
format: date
description: >-
Data de nascimento do utilizador 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 utilizador. Deve ser 'M', 'F' ou null.
example: M
x-readme-id: '1.3'
nationality:
type: string
description: >-
Código de país ISO 3166-1 alfa-3 que representa o país
de origem do requerente. Por exemplo, `USA`. Consulte a
[lista completa de códigos de país
suportados](https://docs.didit.me/pt/core-technology/id-verification/supported-documents-id-verification#documentos-suportados-por-país).
example: USA
x-readme-id: '1.4'
country:
type: string
description: >-
Código de país ISO 3166-1 alfa-3 utilizado como recurso
para as verificações de discrepância de país tanto de
Verificação de identidade como de Comprovativo de
morada. Obrigatório quando `address` é fornecido 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 de país ISO 3166-1 alfa-3 que representa o país
esperado do documento de identificação do requerente,
que pode diferir da nacionalidade. Por exemplo, `GBR`.
Tem prioridade sobre `country` para verificações de
discrepância de país de verificação de identidade.
Consulte a [lista completa de códigos de país
suportados](https://docs.didit.me/pt/core-technology/id-verification/supported-documents-id-verification#documentos-suportados-por-país).
example: GBR
x-readme-id: '1.5'
poa_country:
type: string
description: >-
Código de país ISO 3166-1 alfa-3 que representa o país
esperado do documento de Comprovativo de morada. Por
exemplo, `USA`. Tem prioridade sobre `country` para
verificações de discrepância de país de POA. Consulte a
[lista completa de códigos de país
suportados](https://docs.didit.me/pt/core-technology/id-verification/supported-documents-id-verification#documentos-suportados-por-país).
example: USA
x-readme-id: 1.5.1
address:
type: string
description: >-
A morada num formato legível por humanos, incluindo o
máximo de informação possível. Por exemplo, `123 Main
St, San Francisco, CA 94105, USA`. Quando fornecida,
também deve passar `country` ou `poa_country`, caso
contrário o pedido 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 de documento, número de identificação pessoal
ou número de identificação fiscal do utilizador. Por
exemplo, `123456789`.
example: '123456789'
x-readme-id: '1.7'
ip_address:
type: string
description: >-
Endereço IP previsto para a sessão, no formato IPv4 ou
IPv6. Se o endereço IP real diferir deste valor, será
registado um aviso. 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 utilizador pode
apresentar durante o passo de verificação de identidade
(OCR). Quando definido, o ecrã de seleção de documentos
apresenta apenas os tipos solicitados e o
`documents_allowed` retornado é filtrado em
conformidade. 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 de identificação
nacional), `DL` (carta de condução), `RP` (título de
residência), `HIC` (cartão de saúde), `TC` (cartão
fiscal), `SSC` (cartão de segurança 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: >-
Nome legal esperado da empresa que está a ser
verificada. Por exemplo, `Tesco PLC`. Pré-preenche o
campo do nome da empresa na pesquisa no registo de
empresas em fluxos de Verificação de empresas (KYB);
quando `registration_number` também é fornecido, a
pesquisa no registo combina ambos os identificadores.
Ignorado para 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 registo de
empresas a empresa está registada. Por exemplo, `GB`.
Onde os registos de empresas operam a nível estadual ou
provincial, anexe o código de subdivisão ISO 3166-2 como
`XX-YY`: `US-CA` visa o registo da Califórnia. Mesmo
formato que `country_code` na [KYB Registry Search
API](https://docs.didit.me/pt/standalone-apis/kyb-registry-search).
Pré-seleciona o país do registo nos 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 registo esperado da empresa no registo de
empresas. Por exemplo, `00445790`. Pré-preenche o campo
do número de registo da pesquisa no registo de empresas
em fluxos de Verificação de empresas (KYB); quando
`company_name` também é fornecido, a pesquisa no registo
de empresas combina ambos os identificadores. Ignorado
para 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 utilizador final codificada em
base64 (máx. 2MB; JPEG, PNG, WebP ou TIFF). Usada como
imagem de referência para comparar com a captura de prova de
vida quando o fluxo é um fluxo de `Biometric Authentication`
com a Correspondência facial ativada, ou qualquer fluxo em
grafo onde a Correspondência facial seja executada antes da
Verificação de identidade (OCR). Opcional quando o
utilizador em `vendor_data` já possui uma imagem de rosto
guardada: a Didit reutiliza-a automaticamente, resolvida
pela seguinte ordem de prioridade: rosto de prova de vida
aprovado, fotografia do chip de ePassport, retrato do
documento de identificação, rosto de perfil registado
manualmente (apenas rostos de sessões aprovadas ou rostos
registados por si são reutilizados). Quando fornecida,
`portrait_image` tem sempre precedência sobre o rosto
guardado. Se for omitida e não existir nenhum rosto guardado
(ou `vendor_data` não for enviado), a criação da sessão
falha com `400`. Ignorado para outros tipos de fluxo.
example: >-
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=
x-readme-id: '0.6'
sandbox_scenario:
type: string
description: >-
Slug de cenário exclusivo da sandbox. Só é aceite quando a
chave de API pertence a uma aplicação em modo sandbox; é
rejeitado em aplicações de produção. Quando definido, o
fluxo de criação expande os valores mágicos incluídos no
cenário para os campos de entrada da sessão
(contact_details, expected_details) para que os fornecedores
simulados reproduzam o resultado do cenário através do
pipeline real do fluxo. Consulte o catálogo de cenários em
GET /v1/sandbox/scenarios/ ou [Sandbox e dados de
teste](/pt/integration/sandbox-testing). Também pode armar
(ou rearmar) um cenário após a criação através de POST
/v3/session/{sessionId}/sandbox/arm/, desde que a sessão
ainda esteja em `Not Started`. Para pesquisas que não sejam
de documentos, utilize `lookup_partial_match`,
`lookup_no_match` ou `lookup_provider_error` para testar o
orçamento de tentativas configurado e o fallback. Para
carteiras de identidade, utilize `wallet_cancelled`,
`wallet_timeout` ou `wallet_provider_error`; `approve`
simula uma carteira verificada. Todas as carteiras do
catálogo podem ser testadas na sandbox, incluindo esquemas
indisponíveis em aplicações de produção. As 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 cujo
passo de Assinatura eletrónica obtém documentos da sessão
(`signature_documents_source` como `session` ou `both`): até
20 documentos e 50 MB no total. `field_values` preenche os
campos cujo `prefill` seja `api.`, tanto em documentos
do fluxo como da sessão. Criar novamente uma sessão para o
mesmo `workflow_id` e `vendor_data` devolve a sessão
pendente; se essa chamada enviar `sign`, os seus documentos,
campos e valores têm de ser idênticos aos primeiros, e
qualquer diferença devolve `400` com `{"sign":
"signature_document_changed"}`. Consulte [Documentos de
assinatura
eletrónica](/pt/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
pré-preenchimento `api.`: strings de 1 a 500
carateres para campos `text` e `data`, booleanos para um
`checkbox`. `400` com `field_value_unknown` para uma
chave que nenhum campo utiliza, `field_value_missing`
para um campo obrigatório sem o respetivo valor e
`field_value_invalid` para um valor que falhe a
validação do respetivo 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 reside, quando for do seu conhecimento: 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 legislação exija consentimento biométrico
explícito (Illinois, Texas, Colorado) faz com que o fluxo de
verificação o solicite antes de capturar um rosto, com o
acionador `declared_state`. Um valor não reconhecido devolve
`400`. Consulte [Consentimento
biométrico](/pt/getting-started/biometric-consent).
example: US-IL
biometric_consent:
type: object
description: >-
Consentimento biométrico explícito que já recolheu da
pessoa. Cumpre o requisito, pelo que o fluxo de verificação
não volta a pedir, e a decisão regista-o como `status:
"given"` com o acionador `customer_collected`. Uma resposta
que a pessoa já tenha dado no fluxo nunca é substituída.
Consulte [Consentimento
biométrico](/pt/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 ser 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 registos.
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 de caso de sucesso para uma sessão de
Verificação de utilizadores (KYC)
description: >-
Chamada de criação realista que utiliza todos os campos
habitualmente definidos: seleção de fluxo, associação a
fornecedor, encaminhamento de retorno, metadados,
idioma/região, pré-preenchimento de contacto e dados esperados
do utilizador. Copie e cole diretamente no exemplo 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 ideal para uma sessão de Verificação de
empresas (KYB)
description: >-
O mesmo formato da chamada KYC — o `workflow_id` é o que torna
a sessão KYB. `vendor_data` referencia habitualmente a empresa
no seu sistema e `contact_details.email` destina-se ao
representante legal que concluirá o fluxo. `expected_details`
aceita os campos da empresa (`company_name`,
`registry_country`, `registration_number`), que pré-preenchem
a pesquisa no registo de empresas; os campos ao nível da
pessoa e `contact_details.phone` são ignorados em fluxos 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 devolvida, se já existir uma sessão não finalizada
com o mesmo `vendor_data` na versão publicada mais recente do
fluxo). A resposta é a sessão serializada, incluindo o `url` de
verificação alojada para o qual redirecionar o utilizador.
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. Utilize este
id ao chamar `GET /v3/session/{sessionId}/decision/`.
example: 11111111-2222-3333-4444-555555555555
session_number:
type: integer
description: >-
Número sequencial e de fácil leitura atribuído à sessão
dentro da sua aplicação. Útil para suporte e painéis.
example: 43762
session_token:
type: string
description: >-
Token de 12 carateres seguro para URL que autoriza o
utilizador final a aceder ao fluxo de verificação alojado
em `url`. Válido até a sessão expirar. Trate-o como um
segredo — qualquer pessoa que o possua pode abrir o fluxo
de verificação para esta sessão.
example: 3FaJ9wLqX2Mz
url:
type: string
format: uri
description: >-
URL de verificação alojado para o qual redirecionar o
utilizador final. O URL incorpora o `session_token` e, se
configurado, utiliza o seu domínio de marca branca. Quando
o pedido inclui `language`, o URL contém um segmento de
caminho de idioma —
`https://verify.didit.me/{language}/session/{session_token}`
(ex.: `/es/session/...`); sem `language`, o segmento é
omitido.
example: https://verify.didit.me/session/3FaJ9wLqX2Mz
vendor_data:
type: string
nullable: true
description: >-
Identificador transmitido no pedido para associar a sessão
a um utilizador ou empresa no seu próprio sistema.
Devolvido tal como foi enviado. Nulo quando não fornecido.
example: user-123
metadata:
description: >-
Payload JSON arbitrário que guardou com a sessão no
momento da criação. Devolvido tal como enviado — qualquer
valor JSON que enviou (objeto, string, número, array) é
devolvido inalterado, embora se recomende um objeto JSON.
Não visível para o utilizador 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 etiquetas na 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: >-
Estado atual da sessão. Sessões recém-criadas devolvem
`Not Started`. Se já existia uma sessão não terminada para
os mesmos `vendor_data` na versão mais recente publicada
do fluxo, o estado devolvido reflete essa sessão
existente.
example: Not Started
callback:
type: string
format: uri
nullable: true
description: >-
URL de redirecionamento final para onde o utilizador é
enviado após concluir o fluxo. O Didit anexa
`?verificationSessionId={session_id}&status={status}` a
este URL. Recai para o URL de retorno configurado no fluxo
quando não for fornecido no pedido; `null` quando nenhum
estiver definido. Quando a aplicação tem domínios
permitidos e este URL for um URL web fora deles (por
exemplo, uma predefinição do fluxo definida antes da
alteração da lista), o fluxo alojado não redireciona o
utilizador para ele.
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 de grupo estável do
fluxo — mesmo que tenha referenciado o UUID de uma versão
específica do fluxo no pedido (pesquisa compatível com
versões anteriores), a resposta contém o `workflow_id`
estável. Utilize-o para correlacionar a sessão com o fluxo
configurado na Consola.
example: 11111111-2222-3333-4444-555555555555
workflow_version:
type: integer
description: >-
Número da versão publicada do fluxo à qual a sessão ficou
associada no momento da criação. O Didit resolve o
`workflow_id` para a versão publicada mais recente do
fluxo quando a sessão é criada, e a sessão continua a
executar essa versão mesmo que o fluxo seja republicado
mais tarde.
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: >-
Pedido incorreto — a validação do payload falhou (`workflow_id` em
falta ou desconhecido, `language` inválido, `vendor_data` na lista
de bloqueio, `portrait_image` malformada, `address` sem
`country`/`poa_country`, `sandbox_scenario` inválido, documentos
`sign`, campos ou valores recusados pelo passo de Assinatura
eletrónica do fluxo, tais como `signature_document_not_supported`,
`signature_document_conversion_failed`, `field_anchor_not_found` ou
`field_value_missing`, etc.) ou a sua organização não tem créditos
suficientes para iniciar a sessão.
O corpo é um objeto cuja chave é o nome do campo com erro (ou
`detail` para erros que não são de campos). Os valores são um
**array de strings** para falhas de validação de entrada (por
exemplo, campo obrigatório em falta, idioma inválido, imagem de
retrato demasiado grande) e uma **string simples** para falhas
detetadas 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). Processe ambos
os formatos.
content:
application/json:
schema:
type: object
additionalProperties: true
properties:
detail:
type: string
description: >-
Mensagem de erro legível para erros não associados a
campos (por exemplo, créditos insuficientes). Em vez
disso, as falhas ao nível dos campos utilizam o nome do
campo como chave, com um valor de string ou de 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 plain-string)
value:
workflow_id: Invalid workflow_id.
Insufficient credits:
summary: A organização não tem 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 a 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 guardado para o utilizador 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 devolve `401`. O endpoint devolve `403` quando o
cabeçalho `x-api-key` está em falta ou 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). Estas
falhas partilham 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 através da [API de
autenticação](/pt/auth-api/get-credentials) se necessário e tente
novamente.
**Aplicação eliminada:** durante alguns minutos após a eliminação de
uma aplicação, um pedido efetuado com uma das suas chaves de API
pode responder `{"detail": "This application was deleted.", "code":
"application_deleted"}`. Não tente novamente: a aplicação e as suas
chaves de API já não existem. Decorridos 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 eliminada.
example: application_deleted
required:
- detail
examples:
Missing or invalid API key:
summary: Sem 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 eliminada
value:
detail: This application was deleted.
code: application_deleted
'429':
description: >-
Limite de pedidos excedido — mais de 600 pedidos de criação de
sessão numa janela de 60 segundos a partir da mesma chave de API /
IP. Inspecione o `Retry-After` e aguarde antes de tentar novamente.
**Nota:** O código-fonte também define um `FREE_SESSION_RATE_LIMIT`
de 10 chamadas/minuto a par de `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
pedidos aplica o `SESSION_CREATE_RATE_LIMIT` de 600/min
independentemente do plano. 600/min é o único limite que pode
atingir aqui.
headers:
Retry-After:
description: >-
Segundos que o autor da chamada deve aguardar antes de tentar
novamente o pedido.
schema:
type: integer
minimum: 1
example: 42
X-RateLimit-Limit:
description: >-
Número máximo de pedidos permitidos na janela atual de 60
segundos para o limite que foi ultrapassado (600 para
session-create). Ausente na variante de quota de sandbox.
schema:
type: integer
example: 600
X-RateLimit-Remaining:
description: >-
Número de pedidos ainda permitidos na janela atual para o limite
ultrapassado. Ausente na variante de quota da sandbox.
schema:
type: integer
minimum: 0
example: 0
X-RateLimit-Reset:
description: >-
Segundos da época UTC em que a janela atual de limite de pedidos
é reiniciada. Ausente na variante de quota de 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 pedidos.
Utilize esta mensagem para distinguir 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 pedidos 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: Aplicação em 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 apresentado ao signatário. O valor predefinido é `file_name`.
file_name:
type: string
minLength: 1
maxLength: 255
description: Nome do ficheiro, a terminar em `.pdf` ou `.docx`.
content_base64:
type: string
format: byte
description: >-
O ficheiro, codificado em base64. Um PDF pode ter até 20 MB e 100
páginas, sem palavra-passe, scripts ou ficheiros anexados. Um
ficheiro Word (`.docx`) pode ter até 20 MB e é convertido para PDF
durante a execução do pedido, em no máximo 25 segundos; o PDF fica
então com os mesmos limites. Até 5 ficheiros Word por sessão. Um
ficheiro Word com macros, alterações registadas, ligações para
conteúdo externo ou objetos incorporados é recusado com
`signature_document_not_supported`, e um que não possa ser
convertido devolve `signature_document_conversion_failed`, cada um
com um `reason`.
fields:
type: array
description: >-
Campos opcionais a colocar neste documento, até 200. As páginas e
posições referem-se ao PDF, ou ao PDF convertido no caso de um
ficheiro Word. Sem campos, o signatário lê o documento e aceita-o.
items:
$ref: '#/components/schemas/SignatureField'
maxItems: 200
SignatureField:
type: object
description: >-
Um campo a colocar num documento de sessão: qual o signatário que o
preenche, como e onde. Indique uma posição (`page`, `x`, `y`, `width` e
`height`) ou um `anchor`. As posições são frações da página conforme é
apresentada, a partir do seu canto superior esquerdo, arredondadas a 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 cada função com campos
num documento necessita de um campo `signature` ou `initials` no mesmo.
Consulte [Campos no
documento](/pt/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, introduz `text`, marca uma `checkbox` e
introduz um `email` quando a sessão não tem um e-mail verificado. O
Didit preenche `full_name` (o nome verificado), `date_signed` (a
data de assinatura, no fuso horário do signatário), `data` (a partir
de `prefill`) e um `email` verificado, apresentando-os apenas para
leitura. Não existe um tipo de seletor de data: utilize `text`.
role:
type: string
enum:
- verified_person
- legal_representative
- key_people
description: >-
Quem preenche o campo, com os valores de `signature_signer`. Um
passo preenche e carimba apenas os campos do seu próprio signatário.
A predefinição é o signatário do passo.
page:
type: integer
minimum: 1
description: >-
Número da página, de 1 até ao número total de páginas do documento.
Para um documento Word, uma página do PDF convertido.
x:
type: number
minimum: 0
maximum: 1
description: Margem esquerda, como fração da largura da página.
'y':
type: number
minimum: 0
maximum: 1
description: Limite superior, como uma fração da altura da página.
width:
type: number
minimum: 0.02
maximum: 1
description: >-
Largura, como uma 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: >-
Apresentado ao signatário e nos resultados. Predefinido com base no
tipo.
placeholder:
type: string
nullable: true
maxLength: 80
description: apenas `text` e `email`.
validation:
$ref: '#/components/schemas/SignatureFieldValidation'
prefill:
type: string
nullable: true
description: >-
De onde o valor provém: `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 dos `metadata` da sessão) ou `api.` (uma chave de
`sign.field_values`). Obrigatório para `data`. `full_name` utiliza
sempre `identity.full_name` e `email` utiliza `contact.email`. Os
valores dos campos `data`, `full_name` e `email` verificado são
fixados quando o signatário inicia a assinatura.
editable_when_prefilled:
type: boolean
default: false
description: >-
apenas `text` e `email`: o signatário pode alterar um valor
pré-preenchido.
checked_by_default:
type: boolean
default: false
description: 'Apenas `checkbox`: a caixa começa assinalada.'
date_format:
type: string
enum:
- DD/MM/YYYY
- MM/DD/YYYY
- YYYY-MM-DD
- D MMMM YYYY
default: DD/MM/YYYY
description: '`date_signed` apenas.'
SignatureFieldAnchor:
type: object
description: >-
Posiciona um campo com base num excerto de texto no documento em vez de
uma posição. O Didit não remove o texto do PDF, pelo que deve escrevê-lo
com a mesma cor do fundo da página. Quando o texto não é encontrado, a
chamada devolve `400` com `field_anchor_not_found`. Consulte [Posicionar
campos por
texto-âncora](/pt/sessions-api/create-session#colocar-campos-por-texto-de-âncora).
required:
- text
properties:
text:
type: string
minLength: 1
maxLength: 64
description: >-
Texto pesquisado no documento. No caso de um ficheiro Word, no PDF
convertido.
occurrence:
type: string
enum:
- first
- all
default: first
description: >-
`all` coloca um campo por correspondência; as chaves a seguir à
primeira recebem `_2`, `_3` e assim sucessivamente.
offset_x:
type: number
description: >-
Adicionado à margem esquerda do texto, como fração da largura da
página.
offset_y:
type: number
description: >-
Adicionado à margem superior do texto, como fração da altura da
página.
width:
type: number
minimum: 0.02
maximum: 1
description: Largura do campo, como uma 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 da consola, o
fluxo de assinatura e a API aplicam as mesmas regras.
properties:
kind:
type: string
enum:
- any
- letters
- number
- email
- pattern
description: >-
`letters`: letras em qualquer sistema de escrita, espaços, hífenes e
apóstrofos. `number`: dígitos com um separador decimal opcional.
`pattern`: o valor tem de 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 completo deve corresponder. Asserções de contexto e
retroreferências não são suportadas.
message:
type: string
nullable: true
maxLength: 120
description: Apresentado ao signatário em vez do erro predefinido.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
A chave de API da sua aplicação, a partir de Programadores -> Chaves de
API na Business Console. A chave principal tem acesso total. Uma chave
nomeada pode ter o âmbito definido: nenhum, 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á
incorreta, 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 o
pedido veio de um endereço fora da sua lista de IP; 404 numa rota de
sessão significa que a sessão está fora dos fluxos ou estados da chave.
Uma chave sem acesso a multimédia recebe URLs de imagens, vídeos e PDFs
como nulos, e uma chave sem permissão de escrita em sessões recebe
ligações de sessão e tokens como nulos. Consulte
https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.