> ## 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 creació de sessions: iniciar verificació KYC o KYB
> Didit: POST /v3/session/ inicia una sessió de verificació KYC o KYB. Pagament per ús, inferència inferior a 2 s i $10 de crèdit gratuït al mes.
Indicació per crear una sessió
Copia el prompt al porta-retalls
\
\`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.`
\
Enganxa a
## Compatibilitat amb KYC i KYBUn únic endpoint crea sessions de Verificació d'usuaris i de Verificació d'empreses. El **tipus del flux de treball** determina quin tipus de sessió es crea:- Si passes un `workflow_id` d'un **flux de treball KYC**, es crea una sessió de Verificació d'usuaris (KYC). Resposta `session_kind: "user"`.
- Si passes un `workflow_id` d'un **flux de treball KYB**, es crea una sessió de Verificació d'empreses (KYB). Resposta `session_kind: "business"`.Configura els fluxos de treball a la consola, a *Workflows → Create workflow*. Un flux de treball és KYC o KYB en el moment de crear-lo; després no es pot canviar el tipus.## Exemples> [tab] Verificació d'usuaris (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] Verificació d'empreses (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"
> }
> ```## Documents de signatura electrònicaQuan el flux de treball té un pas de [Signatura electrònica](https://docs.didit.me/ca/core-technology/electronic-signature/overview.md) que pren els documents de la sessió (`signature_documents_source` amb el valor `session` o `both`), envia'ls a `sign.documents`. Cada document és el fitxer en base64, de manera que Didit no l'ha de descarregar mai des d'una URL.```json theme={null}
{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-42",
"sign": {
"documents": [
{
"title": "Loan agreement",
"file_name": "loan-agreement.pdf",
"content_base64": "JVBERi0xLjcKJc...",
"fields": [
{ "key": "borrower_signature", "type": "signature", "label": "Borrower signature", "page": 3, "x": 0.1, "y": 0.78, "width": 0.32, "height": 0.06 },
{ "key": "date_signed", "type": "date_signed", "label": "Date", "page": 3, "x": 0.6, "y": 0.8, "width": 0.2, "height": 0.03, "date_format": "DD/MM/YYYY" },
{ "key": "loan_amount", "type": "data", "label": "Loan amount", "page": 1, "x": 0.34, "y": 0.31, "width": 0.3, "height": 0.03, "prefill": "api.loan_amount" },
{ "key": "initials", "type": "initials", "anchor": { "text": "[[initials]]", "occurrence": "all", "offset_x": 0, "offset_y": -0.005, "width": 0.12, "height": 0.04 } }
]
}
],
"field_values": { "loan_amount": "12,000 EUR" }
}
}
```| Camp | Regles |
| - | - |
| `title` | Es mostra al signant. De 1 a 255 caràcters. Per defecte, és `file_name`. |
| `file_name` | Obligatori. Acaba en `.pdf` o `.docx`. De 1 a 255 caràcters. |
| `content_base64` | Obligatori. Un PDF pot tenir fins a 20 MB i 100 pàgines, sense contrasenya, scripts ni fitxers adjunts. Un fitxer Word pot tenir fins a 20 MB i es converteix a PDF mentre dura la sol·licitud, en 25 segons com a màxim; el PDF resultant té els mateixos límits. Fins a 5 fitxers Word per sessió. |
| `fields` | Opcional. Fins a 200 [camps](https://docs.didit.me/ca/core-technology/electronic-signature/overview.md#camps-al-document) per col·locar al document, amb la forma de camp sense `id`. Cada camp necessita una `key` i un `type`, i una posició (`page`, `x`, `y`, `width` i `height`) o un [`anchor`](#col·locar-camps-mitjançant-text-d’ancoratge). `role` és per defecte el signant del pas, i `required` i `label` es prenen del tipus. Didit defineix `position` segons on es troba el camp. Les pàgines i les posicions fan referència al PDF, o al PDF convertit en cas d'un fitxer Word. |Sense `fields`, el signant llegeix el document i hi està d'acord.### Col·locar camps mitjançant text d'ancoratgeEn lloc d'una posició, un camp pot portar un `anchor`: un fragment de text del document que marca on va el camp. Els ancoratges són útils per a documents que generes per a cada sessió, per exemple a partir d'una plantilla Word. Per als documents del flux de treball, col·loca els camps a la consola.| Propietat de `anchor` | Regles |
| - | - |
| `text` | De 1 a 64 caràcters, cercats al text del document. En un fitxer Word, al PDF convertit. |
| `occurrence` | `first` (per defecte) col·loca un camp a la primera coincidència. `all` col·loca un camp a cada coincidència, i les claus a partir de la primera reben `_2`, `_3` i així successivament. |
| `offset_x`, `offset_y` | Fraccions de la pàgina. La cantonada superior esquerra del camp és la cantonada superior esquerra del text d'ancoratge, amb aquests desplaçaments afegits. |
| `width`, `height` | La mida del camp, com a fraccions de la pàgina. |Si el text no és al document, la crida retorna `400` amb `field_anchor_not_found` i la clau del camp. Didit no elimina el text d'ancoratge del PDF, de manera que escriu-lo amb el mateix color que el fons de la pàgina.### Valors dels camps`sign.field_values` defineix el valor de cada camp el `prefill` del qual és `api.`, tant als documents del flux de treball com als de la sessió. És un objecte indexat pels noms ``. Els valors són cadenes d'1 a 500 caràcters per als camps `text` i `data`, i booleans per a un `checkbox`.```json theme={null}
{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-42",
"sign": {
"field_values": { "credit_limit": "3,000 EUR", "monthly_fee": "4.90 EUR" }
}
}
```| Error (`400`) | Quan |
| - | - |
| `field_value_unknown` | Una clau que cap camp no utilitza. |
| `field_value_missing` | Un camp obligatori el `api.` del qual no té valor. |
| `field_value_invalid` | Un valor que no supera la [validació](https://docs.didit.me/ca/core-technology/electronic-signature/overview.md#validació) del seu camp. |### Errors i crides repetidesUna sessió admet fins a 20 documents i 50 MB en total. La crida retorna `400` amb un error de `sign` quan:- El flux de treball no té cap pas de Signatura electrònica.
- Has enviat `sign.documents` i el pas només accepta documents del flux de treball.
- El pas només accepta documents de la sessió i no n'has enviat cap, o no té documents del flux de treball i tampoc n'has enviat cap.
- Un document és massa gran, no és base64 vàlid o no és un fitxer admès.
- Un fitxer Word és rebutjat amb `signature_document_not_supported`, o no es pot convertir i retorna `signature_document_conversion_failed`, cadascun amb el `reason` que apareix a [Fitxers admesos](https://docs.didit.me/ca/core-technology/electronic-signature/overview.md#fitxers-compatibles).
- Un camp no és vàlid, el seu ancoratge no es troba (`field_anchor_not_found`), o un [valor de camp](#valors-dels-camps) és rebutjat.Tornar a crear per al mateix `workflow_id` i `vendor_data` retorna la sessió pendent. Si aquesta crida envia `sign`, els seus documents, camps i valors de camp han de ser idèntics als de la primera (mateix ordre, títols, noms de fitxer, contingut, camps i valors). Qualsevol diferència retorna `400` amb `{"sign": "signature_document_changed"}`: utilitza un `vendor_data` diferent o espera que acabi la sessió pendent.## Proves amb escenaris de sandboxEn una aplicació en mode sandbox, passa `sandbox_scenario` per precarregar un resultat determinista (aprovació, un rebuig concret o un escenari en revisió) sense tocar proveïdors reals ni el teu saldo:```json theme={null}
{
"workflow_id": "YOUR_SANDBOX_WORKFLOW_ID",
"sandbox_scenario": "decline_document_expired"
}
````sandbox_scenario` és rebutjat amb `400` a les aplicacions en producció. Si encara no coneixes el resultat en el moment de crear la sessió, pots activar-lo (o tornar-lo a activar) més tard mitjançant `POST /v3/session/{session_id}/sandbox/arm/`, sempre que la sessió encara estigui `Not Started`: el selector d'escenaris previ al flux allotjat utilitza aquest mateix endpoint. Consulta [Sandbox i dades de prova](https://docs.didit.me/ca/integration/sandbox-testing.md) per al catàleg complet d'escenaris, el registre de valors màgics i la forma de la sol·licitud i la resposta de l'endpoint d'activació.## `vendor_data` vincula la sessió a una entitat- En els fluxos de treball KYC, vincula la sessió a una [entitat d'usuari](https://docs.didit.me/ca/entities/users/overview.md). Si l'usuari no existeix, es crea automàticament.
- En els fluxos de treball KYB, vincula la sessió a una [entitat d'empresa](https://docs.didit.me/ca/entities/businesses/overview.md). Es crea automàticament si és nova.Més informació a [vinculació de dades del proveïdor](https://docs.didit.me/ca/entities/vendor-data-linking.md).## Consentiment biomètric a Illinois, Texas i ColoradoEl flux allotjat i el SDK natiu 4.10.0 o posterior poden mostrar un pas de consentiment biomètric explícit abans de la primera captura facial, segons el mode de consentiment de l'aplicació i on es troba la persona. Hi ha dos camps opcionals que alimenten aquesta decisió:- `user_state`: on viu la persona, quan ho saps (`US-IL`, `IL` o `Illinois`). En mode Auto, un estat inclòs en l'àmbit d'aplicació fa que el flux ho demani.
- `biometric_consent`: un objecte amb `given_at` i `text_version`, per al consentiment que ja has recollit. El flux no el torna a demanar.Els SDK natius per sota de 4.10.0 no poden mostrar aquest pas: les seves sessions funcionen com abans i la decisió indica que el consentiment no s'ha recollit. Consulta [Consentiment biomètric](https://docs.didit.me/ca/getting-started/biometric-consent.md).## Important: la comunicació de la informació i l'obtenció del consentiment encara tenen lloc al teu producte`Create Session` genera una URL de verificació i un token de sessió. Per si mateix, **no** demostra que hagis mostrat a l'usuari la informació legal ni que hagis obtingut el consentiment que requereix el teu cas d'ús concret.Si inicies una sessió de Didit des de la teva pròpia aplicació, web, embolcall del SDK o flux de marca blanca, hauries de gestionar la capa legal a la teva pròpia UX abans que l'usuari comenci la captura.## Llista de comprovació recomanada abans de la verificació1. Digues a l'usuari que **la teva empresa** sol·licita la verificació i que **Didit** és el proveïdor de verificació / encarregat del tractament que fa funcionar el flux.
2. Enllaça al **teu avís de privacitat** i a qualsevol terme legal del responsable del tractament que sigui aplicable al recorregut.
3. Enllaça a l'[Avís de privacitat de la verificació](https://didit.me/terms/verification-privacy-notice) de Didit i a les [Condicions d'ús per a usuaris finals de la verificació d'identitat](https://didit.me/terms/identity-verification).
4. Si el teu flux inclou captura de document, captura de selfie, prova de vida o biometria, recull un **consentiment explícit i afirmatiu** sempre que la llei aplicable o la teva posició legal ho exigeixin.
5. Si utilitzes una UI personalitzada, un domini personalitzat o un recorregut només amb API, mostra aquests avisos al teu propi producte abans d'enviar l'usuari al flux de Didit.
6. Guarda el teu propi registre del text de l'avís o del consentiment, la marca de temps i les metadades relacionades si el teu equip legal exigeix un registre d'auditoria.> [!WARNING]
>
> Els requisits legals varien segons la jurisdicció. La marca blanca no elimina el paper de Didit en el flux de verificació. Revisa la implementació amb un assessor legal abans de llançar-la si operes en jurisdiccions amb normes específiques sobre biometria.
## OpenAPI
````yaml ca/openapi-25.json POST /v3/session/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API de verificació d'identitat. Autentica't amb la capçalera x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/session/:
post:
tags:
- Sessions
summary: Crea una sessió de verificació
description: >-
Crea una sessió de Verificació d'usuaris (KYC) o de Verificació
d'empreses (KYB) i rep una `url` de verificació allotjada juntament amb
un `session_token` per redirigir o incrustar per al teu usuari final. El
`workflow_id` selecciona quins passos de verificació s'executen i si la
sessió és de KYC o de KYB.
Crida aquest endpoint des del teu backend (mai des del navegador — la
clau d'API és un secret) sempre que calgui verificar un usuari o una
empresa: en registrar-se, abans d'una acció sensible o quan calgui una
reverificació. Prerequisits: un flux de treball publicat (creat a la
pàgina [Workflows](https://docs.didit.me/ca/console/workflows) de la
consola) i una clau d'API d'aplicació amb crèdits disponibles. Les
aplicacions de sandbox ometen la comprovació de crèdit.
**Idempotència:** quan es proporciona `vendor_data` i ja existeix una
sessió no finalitzada (`Not Started`, `In Progress`, `Resubmitted` o
`Awaiting User`) amb el mateix `vendor_data` a l'**última versió
publicada actual** del flux de treball (i aquesta sessió ja té una URL
de verificació allotjada), es retorna la sessió existent (igualment
`201`) en lloc de crear-ne una de duplicada — amb el seu `callback` i
`metadata` actualitzats als nous valors proporcionats. Una sessió no
finalitzada creada en una versió anterior del flux de treball (que
s'hagi tornat a publicar des de llavors) **no** es reutilitza; en
comptes d'això, es crea una nova sessió vinculada a l'última versió
publicada. Les sessions en estat `Approved`, `Declined`, `In Review`,
`Expired`, `Abandoned` o `Kyc Expired` no es reutilitzen mai.
**Efectes secundaris:** es genera i s'emmagatzema la URL de verificació
allotjada; si `contact_details.send_notification_emails` és `true` i es
facilita un correu electrònic, s'envia un correu d'invitació a la
verificació. La sessió caduca després del temps de caducitat de sessió
configurat al flux de treball. En els fluxos de treball de KYB,
s'ignoren `contact_details.phone` i `expected_details`.
operationId: post_v3_session_create
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- workflow_id
properties:
workflow_id:
type: string
format: uuid
description: >-
Identificador estable del flux de treball que defineix quins
passos de verificació executarà la sessió. Els fluxos de
treball es creen i es gestionen a la pàgina
[Workflows](/ca/console/workflows) de la Console. El
`workflow_id` també selecciona implícitament si la sessió és
de KYC o de KYB.
example: 11111111-2222-3333-4444-555555555555
x-readme-id: '0.0'
vendor_data:
type: string
description: >-
Un identificador únic per a l'usuari que s'està verificant,
com ara un UUID, correu electrònic o ID d'usuari intern.
Aquest camp s'utilitza per a: (1) **Agrupament d'usuaris**:
les sessions amb el mateix vendor_data s'enllacen al mateix
perfil d'usuari a la pestanya Usuaris. (2) **Detecció de
duplicats entre sessions**: quan es cerquen cares,
documents, números de telèfon, correus electrònics, adreces
IP o empremtes digitals de dispositiu duplicades, les
sessions amb el mateix vendor_data es tracten com el mateix
usuari i s'exclouen de les coincidències. Sense vendor_data,
cada sessió es tracta com un usuari únic i es mostren tots
els possibles duplicats. Recomanem fermament proporcionar
sempre un vendor_data per reduir el soroll en la detecció de
duplicats.
example: user-123
x-readme-id: '0.1'
multi_account_segment:
type: string
maxLength: 64
description: >-
Àmbit opcional de detecció de duplicats dins de la teva
organització. Les comprovacions de cares duplicades comparen
aquesta sessió només amb altres sessions que tinguin el
mateix segment, de manera que bases de comptes separades
(comptes personals i d'empresa, o un per cada subclient B2B)
no marquin una persona que legítimament té un compte a
cadascuna. Omet-lo per utilitzar l'únic àmbit per defecte,
que és el que utilitzen totes les sessions actualment. Les
coincidències de llista de bloqueig i de llista d'admesos
ignoren aquest camp.
example: business-accounts
callback:
type: string
description: >-
URL a la qual redirigir l'usuari un cop completada la
verificació. Didit afegeix automàticament
`verificationSessionId` i `status` (Approved, Declined, In
Review) com a paràmetres de consulta. S'admeten esquemes
d'URL personalitzats (p. ex., `myapp://`) per a callbacks
mòbils. Si s'omet, s'utilitza la `callback_url` per defecte
del flux de treball. Quan l'aplicació té dominis permesos
(`allowed_domains` a `PATCH /v3/webhook/`), un callback
`http` o `https` ha de pertànyer a un d'aquests orígens
(mateix esquema, amfitrió i port); en cas contrari, la
sol·licitud falla amb un error 400 a `callback`: `callback
must be on one of the application's allowed domains:
https://app.example.com`. Els esquemes d'URL personalitzats
sempre s'accepten.
example: https://example.com/verification/callback
x-readme-id: '0.2'
callback_method:
type: string
description: >-
Determina quin dispositiu ha de gestionar la redirecció a la
URL de callback proporcionada. Utilitza `initiator` per
redirigir només el dispositiu que ha iniciat el flux,
`completer` per al dispositiu que el finalitza o `both` per
permetre que qualsevol dels dos dispositius activi el
callback. Si mai observes que el callback no s'activa de
manera fiable, et recomanem establir aquest valor a `both`.
enum:
- initiator
- completer
- both
default: initiator
example: both
x-readme-id: '0.3'
metadata:
description: >-
JSON arbitrari emmagatzemat amb la sessió i retornat en la
resposta i als webhooks. S'accepta qualsevol valor JSON
(objecte, cadena, número, matriu), però es recomana un
objecte JSON de parells clau/valor. No es mostra a l'usuari
final. Utilitza'l per passar els teus propis identificadors
de correlació, variants A/B o context empresarial.
example:
user_type: premium
account_id: ABC123
x-readme-id: '0.4'
tags:
type: array
items:
type: string
maxLength: 50
maxItems: 10
description: >-
Etiquetes afegides a la sessió quan es crea, pel seu nom.
Fins a 10, de fins a 50 caràcters cadascuna. Els noms no
distingeixen majúscules de minúscules i s'emmagatzemen en
majúscules. Un nom que encara no existeixi a l'aplicació es
crea com a etiqueta nova. Les etiquetes es mostren a la
sessió a la consola, on pots filtrar-hi.
example:
- VIP
- ONBOARDING Q4
language:
type: string
description: >-
Codi d'idioma (ISO 639-1) per a la interfície del procés de
verificació. Controla l'idioma mostrat a l'usuari final
durant la verificació. Si no s'indica, l'idioma del
navegador es detectarà automàticament i s'utilitzarà.
Consulta tots els idiomes admesos
[aquí](/ca/integration/supported-languages).
enum:
- en
- ar
- bg
- bn
- bs
- ca
- cnr
- cs
- da
- de
- el
- es
- et
- fa
- fi
- fr
- he
- hi
- hr
- hu
- hy
- id
- it
- ja
- ka
- kk
- ko
- ky
- lt
- lv
- mk
- mn
- ms
- nl
- 'no'
- pl
- pt-BR
- pt
- ro
- ru
- sk
- sl
- so
- sq
- sr
- sv
- th
- tr
- uk
- uz
- vi
- zh-CN
- zh-TW
- zh
example: en
x-readme-id: '0.5'
contact_details:
type: object
description: >-
Informació de contacte de l'usuari que es pot utilitzar per
a notificacions, emplenament previ de formularis de
verificació i verificació de telèfon. Això inclou l'adreça
de correu electrònic, l'idioma preferit per a les
comunicacions i el número de telèfon.
example:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
properties:
email:
type: string
format: email
description: >-
Adreça de correu electrònic de l'usuari (p. ex.,
"john.doe@example.com") que s'utilitzarà durant el pas
de [Verificació de correu
electrònic](/ca/core-technology/email-verification/overview).
Si no es proporciona, l'usuari l'haurà d'introduir
durant el flux de verificació.
example: john.doe@example.com
x-readme-id: '1.0'
send_notification_emails:
type: boolean
default: false
description: >-
Si és true i es proporciona un correu electrònic, Didit
envia el correu inicial "Verifica la teva identitat" de
manera asíncrona quan es crea la sessió de Verificació
d'usuaris (KYC) o Verificació d'empreses (KYB). Didit
també envia notificacions sobre l'estat de la
verificació a l'adreça de correu electrònic
proporcionada per a les sessions que requereixen revisió
manual (p. ex., de 'En revisió' a 'Aprovada' o
'Rebutjada'). Això ajuda els usuaris a tornar a la teva
aplicació un cop finalitzada la verificació. Si tens la
marca blanca activada per a la sessió, el correu enviat
serà de marca blanca.
example: true
x-readme-id: '1.1'
email_lang:
type: string
description: >-
Codi d'idioma (ISO 639-1) per a les notificacions per
correu electrònic. Controla l'idioma de totes les
comunicacions per correu electrònic (p. ex., "en", "es",
"fr"). No hi ha cap valor per defecte desat: quan
s'omet, el correu electrònic d'invitació a la
verificació simplement torna a l'anglès (`en`) en el
moment de l'enviament. L'enum següent és una
instantània; la font de referència activa dels valors
acceptats és el document d'[idiomes
admesos](/ca/integration/supported-languages);
consulta'l sempre abans de confiar en un codi específic.
enum:
- en
- ar
- bg
- bn
- bs
- ca
- cnr
- cs
- da
- de
- el
- es
- et
- fa
- fi
- fr
- he
- hi
- hr
- hu
- hy
- id
- it
- ja
- ka
- kk
- ko
- ky
- lt
- lv
- mk
- mn
- ms
- nl
- 'no'
- pl
- pt-BR
- pt
- ro
- ru
- sk
- sl
- so
- sq
- sr
- sv
- th
- tr
- uk
- uz
- vi
- zh-CN
- zh-TW
- zh
example: en
x-readme-id: '1.2'
phone:
type: string
description: >-
Número de telèfon en format E.164 (p. ex.,
"+14155552671") que s'utilitzarà durant el pas de
[Verificació de
telèfon](/ca/core-technology/phone-verification/overview).
Si no es proporciona, l'usuari l'haurà d'introduir
durant el flux de verificació. S'ignora per als fluxos
de treball de Verificació d'empreses (KYB).
**Important:** aquest número de telèfon només s'aplica
si és un número de telèfon E.164 vàlid. Si el número
proporcionat no és vàlid o no es pot analitzar,
s'ignorarà i l'usuari podrà introduir qualsevol número
de telèfon vàlid durant el pas de Verificació de
telèfon.
example: '+14155552671'
x-readme-id: '1.3'
x-readme-id: '0.4'
expected_details:
type: object
description: >-
Detalls d'usuari esperats utilitzats per a la validació
creuada amb les dades extretes del document d'identitat de
l'usuari, el Comprovant de domicili i altres passos de
verificació. Les discrepàncies es mostren com a advertències
a la decisió; alguns camps (p. ex. `id_country`,
`expected_document_types`) també modifiquen el flux visible
per a l'usuari. En fluxos de treball de Verificació
d'empreses (KYB) només s'utilitzen els camps de l'empresa
(`company_name`, `registry_country`, `registration_number`)
—emplenen prèviament la cerca al registre mercantil per a
l'usuari— i s'ignoren tots els camps de nivell de persona.
example:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
nationality: USA
id_country: USA
expected_document_types:
- P
- ID
properties:
first_name:
type: string
description: >-
Nom de pila de l'usuari. Per exemple, `John`. La
coincidència utilitza una comparació aproximada, i pots
ajustar el nivell d'exigència configurant el llindar de
la puntuació de coincidència de noms a la consola tant
per als fluxos de treball de Document d'identitat com de
Comprovant de domicili.
example: John
x-readme-id: '1.0'
last_name:
type: string
description: >-
Cognom de l'usuari. Per exemple, `Doe`. La coincidència
utilitza una comparació aproximada, i pots ajustar el
nivell d'exigència configurant el llindar de la
puntuació de coincidència de noms a la consola tant per
als fluxos de treball de Document d'identitat com de
Comprovant de domicili.
example: Doe
x-readme-id: '1.1'
date_of_birth:
type: string
format: date
description: >-
Data de naixement de l'usuari en format: YYYY-MM-DD. Per
exemple, `1990-05-15`.
example: '1990-05-15'
x-readme-id: '1.2'
gender:
type: string
nullable: true
enum:
- M
- F
default: null
description: Gènere de l'usuari. Ha de ser 'M', 'F' o null.
example: M
x-readme-id: '1.3'
nationality:
type: string
description: >-
Codi de país ISO 3166-1 alpha-3 que representa el país
d'origen del sol·licitant. Per exemple, `USA`. Consulta
la [llista completa de codis de país
admesos](https://docs.didit.me/ca/core-technology/id-verification/supported-documents-id-verification#documents-admesos-per-país).
example: USA
x-readme-id: '1.4'
country:
type: string
description: >-
Codi de país ISO 3166-1 alpha-3 utilitzat com a
alternativa per a les comprovacions de discrepància de
país tant de Verificació d'identitat com de Comprovant
de domicili. Obligatori quan es proporciona `address` i
no s'ha definit ni `id_country` ni `poa_country`.
example: USA
x-readme-id: 1.4.1
id_country:
type: string
description: >-
Codi de país ISO 3166-1 alpha-3 que representa el país
esperat del document d'identitat del sol·licitant, que
pot ser diferent de la nacionalitat. Per exemple, `GBR`.
Té prioritat sobre `country` per a les comprovacions de
discrepància de país de Verificació d'identitat.
Consulta la [llista completa de codis de país
admesos](https://docs.didit.me/ca/core-technology/id-verification/supported-documents-id-verification#documents-admesos-per-país).
example: GBR
x-readme-id: '1.5'
poa_country:
type: string
description: >-
Codi de país ISO 3166-1 alpha-3 que representa el país
esperat del document del comprovant de domicili. Per
exemple, `USA`. Té prioritat sobre `country` per a les
comprovacions de discrepància de país del comprovant de
domicili. Consulta la [llista completa de codis de país
admesos](https://docs.didit.me/ca/core-technology/id-verification/supported-documents-id-verification#documents-admesos-per-país).
example: USA
x-readme-id: 1.5.1
address:
type: string
description: >-
L'adreça en un format llegible per humans, que inclou
tanta informació com sigui possible. Per exemple, `123
Main St, San Francisco, CA 94105, USA`. Quan es
proporciona, també has d'enviar `country` o
`poa_country`, altrament la sol·licitud falla amb un
`400`.
example: 123 Main St, San Francisco, CA 94105, USA
x-readme-id: '1.6'
identification_number:
type: string
description: >-
El número de document, número personal o identificador
fiscal de l'usuari. Per exemple, `123456789`.
example: '123456789'
x-readme-id: '1.7'
ip_address:
type: string
description: >-
Adreça IP esperada per a la sessió, en format IPv4 o
IPv6. Si l'adreça IP real difereix d'aquest valor, es
registrarà una advertència. Per exemple, `192.168.1.100`
o `2001:db8::1`.
example: 192.168.1.100
x-readme-id: '1.8'
expected_document_types:
type: array
description: >-
Restringeix els tipus de document que l'usuari pot
presentar durant el pas de verificació d'identitat
(OCR). Quan s'estableix, la pantalla de selecció de
documents només mostra els tipus sol·licitats i el valor
retornat `documents_allowed` es filtra en conseqüència.
Els valors no distingeixen entre majúscules i minúscules
i es desdupliquen; els valors desconeguts es rebutgen
amb `400`. Codis permesos: `P` (passaport), `ID`
(document d'identitat nacional), `DL` (permís de
conduir), `RP` (permís de residència), `HIC` (targeta
d'assegurança mèdica), `TC` (targeta d'identificació
fiscal), `SSC` (targeta de la seguretat 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: >-
Raó social esperada de l'empresa que s'està verificant.
Per exemple, `Tesco PLC`. Emplena prèviament el camp del
nom de l'empresa de la cerca al registre mercantil en
fluxos de treball de Verificació d'empreses (KYB); quan
també es proporciona `registration_number`, la cerca al
registre mercantil combina tots dos identificadors.
S'ignora en fluxos de treball de KYC.
example: Tesco PLC
x-readme-id: '1.10'
registry_country:
type: string
maxLength: 10
description: >-
Codi ISO 3166-1 alfa-2 del país en el registre mercantil
del qual està inscrita l'empresa. Per exemple, `GB`. On
els registres mercantils operen a escala d'estat o
província, afegeix el codi de subdivisió ISO 3166-2 en
format `XX-YY`: `US-CA` s'adreça al registre de
Califòrnia. El mateix format que `country_code` a la
[KYB Registry Search
API](https://docs.didit.me/ca/standalone-apis/kyb-registry-search).
Preselecciona el país del registre als fluxos de treball
de Verificació d'empreses (KYB); s'ignora per als fluxos
de treball de KYC.
example: US-CA
x-readme-id: '1.11'
registration_number:
type: string
maxLength: 100
description: >-
Número de registre esperat de l'empresa al registre
mercantil. Per exemple, `00445790`. Emplena prèviament
el camp del número de registre de la cerca al registre
mercantil en fluxos de treball de Verificació d'empreses
(KYB); quan també es proporciona `company_name`, la
cerca al registre mercantil combina tots dos
identificadors. S'ignora en fluxos de treball de KYC.
example: '00445790'
x-readme-id: '1.12'
x-readme-id: '0.5'
portrait_image:
type: string
format: byte
description: >-
Imatge de retrat de la cara de l'usuari final codificada en
base64 (màx. 2 MB; JPEG, PNG, WebP o TIFF). S'utilitza com a
imatge de referència per comparar-la amb la captura de prova
de vida quan el flux de treball és de tipus `Biometric
Authentication` amb Coincidència facial activada, o
qualsevol flux de treball en graf on Coincidència facial
s'executi abans de Verificació d'identitat (OCR). Opcional
quan l'usuari de `vendor_data` ja té una imatge facial
emmagatzemada: Didit la reutilitza automàticament, seguint
aquest ordre de prioritat: cara de prova de vida aprovada,
foto del xip de l'ePassport, retrat del document
d'identitat, cara del perfil registrada manualment (només es
reutilitzen cares de sessions aprovades o cares que hagis
registrat tu mateix). Quan es proporciona, `portrait_image`
sempre té prioritat sobre la cara emmagatzemada. Si s'omet i
no existeix cap cara emmagatzemada (o no s'envia
`vendor_data`), la creació de la sessió falla amb `400`.
S'ignora per a altres tipus de flux de treball.
example: >-
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=
x-readme-id: '0.6'
sandbox_scenario:
type: string
description: >-
Slug de l'escenari només per al sandbox. Només s'accepta
quan la clau d'API pertany a una aplicació en mode sandbox;
es rebutja en aplicacions de producció. Quan s'estableix, el
flux de creació desplega els valors màgics inclosos de
l'escenari als camps d'entrada de la sessió
(contact_details, expected_details) perquè els proveïdors
simulats reprodueixin el resultat de l'escenari a través de
la canalització del flux de treball real. Consulta el
catàleg d'escenaris a GET /v1/sandbox/scenarios/ o [Sandbox
i dades de prova](/ca/integration/sandbox-testing). També
pots activar (o reactivar) un escenari després de la creació
mitjançant POST /v3/session/{sessionId}/sandbox/arm/, sempre
que la sessió estigui encara en estat `Not Started`. Per a
cerques sense document, utilitza `lookup_partial_match`,
`lookup_no_match` o `lookup_provider_error` per provar el
pressupost d'intents configurat i l'alternativa. Per a
carteres d'identitat, utilitza `wallet_cancelled`,
`wallet_timeout` o `wallet_provider_error`; `approve` simula
una cartera verificada. Totes les carteres del catàleg es
poden provar al sandbox, inclosos els esquemes no
disponibles en aplicacions de producció. Els intents
simulats no es cobren.
example: decline_document_expired
sign:
type: object
description: >-
Entrada de signatura electrònica per a aquesta sessió.
`documents` són els documents que cal signar, per a un flux
de treball el pas de Signatura electrònica del qual agafa
documents de la sessió (`signature_documents_source`
`session` o `both`): fins a 20 documents i 50 MB en total.
`field_values` emplena els camps el `prefill` dels quals és
`api.`, tant en documents del flux de treball com de la
sessió. Crear una sessió de nou per al mateix `workflow_id`
i `vendor_data` retorna la sessió pendent; si aquesta crida
envia `sign`, els seus documents, camps i valors han de ser
idèntics als primers, i qualsevol diferència retorna `400`
amb `{"sign": "signature_document_changed"}`. Consulta
[Documents de signatura
electrònica](/ca/sessions-api/create-session#documents-de-signatura-electrònica).
properties:
documents:
type: array
minItems: 1
maxItems: 20
items:
$ref: '#/components/schemas/SessionSignDocument'
field_values:
type: object
description: >-
Valors indexats per la `` de cada font
d'emplenament previ `api.`: cadenes d'1 a 500
caràcters per a camps `text` i `data`, booleans per a un
`checkbox`. Retorna `400` amb `field_value_unknown` per
a una clau que cap camp no utilitza,
`field_value_missing` per a un camp obligatori sense el
seu valor i `field_value_invalid` per a un valor que no
supera la validació del seu camp.
additionalProperties:
oneOf:
- type: string
minLength: 1
maxLength: 500
- type: boolean
example:
credit_limit: 3,000 EUR
user_state:
type: string
maxLength: 16
description: >-
On viu la persona, quan es coneix: un codi de subdivisió ISO
3166-2 (`US-IL`, `ES-M`) o un codi o nom d'estat dels EUA
(`IL`, `Illinois`). Un estat la legislació del qual
requereixi el consentiment biomètric explícit (Illinois,
Texas, Colorado) fa que el flux de verificació el sol·liciti
abans de capturar una cara, amb l'activador
`declared_state`. Un valor no reconegut retorna `400`.
Consulta [Consentiment
biomètric](/ca/getting-started/biometric-consent).
example: US-IL
biometric_consent:
type: object
description: >-
Consentiment biomètric explícit que ja has recollit de la
persona. Compleix el requisit, de manera que el flux de
verificació no el torna a demanar, i la decisió el registra
com a `status: "given"` amb l'activador
`customer_collected`. Mai se substitueix una resposta que la
persona ja hagi donat al flux. Consulta [Consentiment
biomètric](/ca/getting-started/biometric-consent).
required:
- given_at
- text_version
properties:
given_at:
type: string
format: date-time
description: >-
Quan la persona va donar el consentiment biomètric
explícit (ISO 8601). No pot ser en el futur.
text_version:
type: string
maxLength: 64
description: >-
Identificador de versió del text de consentiment que la
persona ha acceptat, en els teus propis registres.
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 complet del cas d'èxit per a una sessió de Verificació
d'usuaris (KYC)
description: >-
Crida de creació realista que utilitza tots els camps
habituals: selecció del flux de treball, vinculació del
proveïdor, encaminament de callbacks, metadades, configuració
regional, emplenament previ de contacte i dades esperades de
l'usuari. Copia i enganxa això directament a l'exemple de cURL
superior.
value:
workflow_id: 11111111-2222-3333-4444-555555555555
vendor_data: user-123
callback: https://example.com/verification/callback
callback_method: both
metadata:
user_type: premium
account_id: ABC123
language: en
contact_details:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
expected_details:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
nationality: USA
id_country: USA
expected_document_types:
- P
- ID
Create KYB session:
summary: >-
Payload del cas d'èxit per a una sessió de Verificació
d'empreses (KYB)
description: >-
La mateixa estructura que la crida de KYC; el `workflow_id` és
el que fa que la sessió sigui de KYB. `vendor_data` normalment
fa referència a l'empresa al teu sistema i
`contact_details.email` s'adreça al representant legal que
completarà el flux. `expected_details` accepta els camps
d'empresa (`company_name`, `registry_country`,
`registration_number`), que emplenen prèviament la cerca al
registre mercantil; els camps de persona i
`contact_details.phone` s'ignoren per als fluxos de treball 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: >-
Sessió creada (o retornada, si ja existeix una sessió inacabada amb
el mateix `vendor_data` a l'última versió publicada del flux de
treball). La resposta és la sessió serialitzada, incloent-hi la
`url` de verificació allotjada a la qual redirigir l'usuari.
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 únic de la sessió de verificació. Utilitza
aquest id en cridar `GET
/v3/session/{sessionId}/decision/`.
example: 11111111-2222-3333-4444-555555555555
session_number:
type: integer
description: >-
Número seqüencial i fàcil de llegir assignat a la sessió
dins de la teva aplicació. Útil per a suport i taulers.
example: 43762
session_token:
type: string
description: >-
Token segur per a URL de 12 caràcters que autoritza
l'usuari final a accedir al flux de verificació allotjat a
`url`. Vàlid fins que caduqui la sessió. Tracta'l com un
secret: qualsevol persona que el tingui pot obrir el flux
de verificació d'aquesta sessió.
example: 3FaJ9wLqX2Mz
url:
type: string
format: uri
description: >-
URL de verificació allotjada a la qual redirigir l'usuari
final. L'URL incrusta el `session_token` i, si està
configurat, utilitza el teu domini de marca blanca. Quan
la sol·licitud inclou `language`, l'URL conté un segment
de ruta d'idioma —
`https://verify.didit.me/{language}/session/{session_token}`
(p. ex. `/es/session/...`); sense `language`, el segment
s'omet.
example: https://verify.didit.me/session/3FaJ9wLqX2Mz
vendor_data:
type: string
nullable: true
description: >-
Identificador que has passat a la sol·licitud per vincular
la sessió a un usuari o a una empresa del teu propi
sistema. Es retorna exactament igual. Null quan no s'ha
proporcionat.
example: user-123
metadata:
description: >-
Payload JSON arbitrari que vas emmagatzemar amb la sessió
en el moment de la creació. Es retorna literalment:
qualsevol valor JSON que hagis enviat (objecte, cadena,
número, matriu) es retorna tal qual, tot i que es recomana
un objecte JSON. No es mostra a l'usuari final. Sempre
present a les respostes; `null` quan no s'ha proporcionat
en crear-la.
example:
user_type: premium
account_id: ABC123
tags:
type: array
items:
type: string
description: Les etiquetes de la sessió, per nom.
example:
- VIP
- ONBOARDING Q4
status:
type: string
enum:
- Not Started
- In Progress
- Approved
- Declined
- In Review
- Expired
- Abandoned
- Kyc Expired
- Resubmitted
- Awaiting User
description: >-
Estat actual de la sessió. Les sessions acabades de crear
retornen `Not Started`. Si ja existia una sessió no
finalitzada per al mateix `vendor_data` a l'última versió
publicada del flux de treball, l'estat retornat reflecteix
aquesta sessió existent.
example: Not Started
callback:
type: string
format: uri
nullable: true
description: >-
URL de redirecció final a la qual s'envia l'usuari després
de completar el flux. Didit afegeix
`?verificationSessionId={session_id}&status={status}` a
aquesta URL. Si no s'indica a la sol·licitud, s'utilitza
per defecte la URL de callback configurada al flux de
treball; serà `null` si no se n'ha configurat cap de les
dues. Si l'aplicació té dominis permesos i aquesta URL és
una URL web externa a aquests dominis (per exemple, un
valor per defecte del flux de treball configurat abans que
canviés la llista), el flux allotjat no hi redirigeix
l'usuari.
example: https://example.com/verification/callback
workflow_id:
type: string
format: uuid
description: >-
Identificador estable del flux de treball en què s'executa
aquesta sessió. Sempre és l'identificador de grup estable
del flux de treball: fins i tot si has fet referència a un
UUID de versió de flux de treball específic a la
sol·licitud (cerca compatible amb versions anteriors), la
resposta conté el `workflow_id` estable. Utilitza'l per
correlacionar la sessió amb el flux de treball que hagis
configurat a la Console.
example: 11111111-2222-3333-4444-555555555555
workflow_version:
type: integer
description: >-
Número de versió de la versió publicada del flux de
treball a la qual es va fixar la sessió en crear-se. Didit
resol `workflow_id` a la darrera versió publicada del flux
de treball quan es crea la sessió, i la sessió continua
executant aquesta versió encara que el flux de treball es
torni a publicar més endavant.
example: 3
examples:
KYC session:
summary: Sessió de KYC creada
value:
session_id: 11111111-2222-3333-4444-555555555555
session_number: 43762
session_token: 3FaJ9wLqX2Mz
url: https://verify.didit.me/en/session/3FaJ9wLqX2Mz
vendor_data: user-123
metadata:
user_type: premium
account_id: ABC123
status: Not Started
workflow_id: 11111111-2222-3333-4444-555555555555
workflow_version: 3
callback: https://example.com/verification/callback
KYB session:
summary: Sessió de KYB creada
value:
session_id: 22222222-3333-4444-5555-666666666666
session_number: 43763
session_token: Yk7pQ2vN8aBc
url: https://verify.didit.me/en/session/Yk7pQ2vN8aBc
vendor_data: company-acme-001
metadata:
tier: enterprise
status: Not Started
workflow_id: 33333333-4444-5555-6666-777777777777
workflow_version: 1
callback: https://example.com/kyb/callback
'400':
description: >-
Sol·licitud incorrecta — el payload no ha superat la validació
(`workflow_id` absent o desconegut, `language` no vàlid,
`vendor_data` a la llista de bloqueig, `portrait_image` amb format
incorrecte, `address` sense `country`/`poa_country`,
`sandbox_scenario` no vàlid, documents de `sign`, camps o valors que
el pas de Signatura electrònica del flux de treball rebutja, com ara
`signature_document_not_supported`,
`signature_document_conversion_failed`, `field_anchor_not_found` o
`field_value_missing`, etc.) o la teva organització no té prou
crèdits per iniciar la sessió.
El cos és un objecte indexat pel nom del camp afectat (o `detail`
per a errors no vinculats a un camp). Els valors són una **matriu de
cadenes** per a fallades de validació d'entrada (p. ex., camp
obligatori absent, idioma no vàlid, imatge de retrat massa gran) i
una **cadena simple** per a fallades detectades en crear la sessió
(`workflow_id` desconegut, `vendor_data` a la llista de bloqueig,
cap cara de referència disponible per a un flux de treball de
Coincidència facial). Gestiona ambdós formats.
content:
application/json:
schema:
type: object
additionalProperties: true
properties:
detail:
type: string
description: >-
Missatge d'error fàcil de llegir per a errors no
relacionats amb camps (p. ex., crèdits insuficients). Els
errors a nivell de camp utilitzen el nom del camp com a
clau, amb un valor de tipus cadena o una matriu de
cadenes.
example: >-
You don't have enough credits to perform this request.
Please top up at https://business.didit.me
examples:
Missing workflow_id:
summary: S'ha omès un camp obligatori (format de matriu de cadenes)
value:
workflow_id:
- This field is required.
Invalid workflow_id:
summary: workflow_id desconegut (format de cadena de text plana)
value:
workflow_id: Invalid workflow_id.
Insufficient credits:
summary: L'organització s'ha quedat sense crèdits
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 és a la llista de bloqueig
value:
vendor_data: >-
This user or business has been blocked and cannot create
new verification sessions.
Portrait image too large:
summary: portrait_image no supera la validació de mida
value:
portrait_image:
- Image size exceeds 2MB.
No stored face for vendor_data:
summary: >-
Flux de treball de Coincidència facial sense portrait_image
i sense cara emmagatzemada per a l'usuari 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: >-
Flux de treball de Coincidència facial sense portrait_image
i sense 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: >-
L'autenticació o l'autorització han fallat. Una clau incorrecta,
revocada o caducada retorna `401`. L'endpoint retorna `403` quan
falta la capçalera `x-api-key` o la clau d'API és vàlida però el
client no té permís per crear sessions en aquesta aplicació (per
exemple, la clau d'API pertany a una organització diferent).
Aquestes fallades comparteixen el cos `{"detail": "You do not have
permission to perform this action."}`. Comprova que la capçalera
`x-api-key` estigui present i pertanyi a l'aplicació prevista, torna
a obtenir la clau d'API de l'aplicació mitjançant l'[Auth
API](/ca/auth-api/get-credentials) si cal, i reintenta-ho.
**Aplicació eliminada:** durant uns minuts després d'eliminar una
aplicació, una sol·licitud feta amb una de les seves claus d'API pot
respondre `{"detail": "This application was deleted.", "code":
"application_deleted"}`. No ho reintentis: l'aplicació i les seves
claus d'API ja no existeixen. Després d'aquests minuts, la clau es
rebutja com qualsevol altra clau no vàlida.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: You do not have permission to perform this action.
code:
type: string
description: >-
Motiu llegible per màquina, present només en algunes
fallades. `application_deleted`: la clau d'API pertany a
una aplicació que s'ha suprimit.
example: application_deleted
required:
- detail
examples:
Missing or invalid API key:
summary: Sense capçalera `x-api-key` o clau d'API no vàlida
value:
detail: You do not have permission to perform this action.
No permission:
summary: El client no pot crear sessions
value:
detail: You do not have permission to perform this action.
Application deleted:
summary: Clau d'API d'una aplicació suprimida
value:
detail: This application was deleted.
code: application_deleted
'429':
description: >-
S'ha superat el límit de freqüència: més de 600 sol·licituds de
creació de sessió en una finestra de 60 segons des de la mateixa
clau d'API / IP. Revisa `Retry-After` i redueix la freqüència abans
de reintentar.
**Nota:** El codi font també defineix un `FREE_SESSION_RATE_LIMIT`
de 10 crides/minut juntament amb `PAID_SESSION_RATE_LIMIT=600`
(`sessions/serializers/session.py`), però aquest sostre del pla
gratuït **no s'aplica a aquest endpoint V3**; el middleware de límit
de freqüència aplica el `SESSION_CREATE_RATE_LIMIT` de 600/min
independentment del pla. 600/min és l'únic límit amb què et pots
trobar aquí.
headers:
Retry-After:
description: >-
Segons que el client ha d'esperar abans de reintentar la
sol·licitud.
schema:
type: integer
minimum: 1
example: 42
X-RateLimit-Limit:
description: >-
Nombre màxim de sol·licituds permeses a la finestra actual de 60
segons per al límit superat (600 per a la creació de sessions).
Absent a la variant sandbox-quota.
schema:
type: integer
example: 600
X-RateLimit-Remaining:
description: >-
Nombre de sol·licituds que encara es permeten a la finestra
actual per al límit superat. Absent a la variant sandbox-quota.
schema:
type: integer
minimum: 0
example: 0
X-RateLimit-Reset:
description: >-
Segons d'època UTC en què es reinicia la finestra actual de
límit de freqüència. Absent a la variant de quota de sandbox.
schema:
type: integer
minimum: 0
example: 1747497600
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
Explicació fàcil de llegir de la superació del límit de
freqüència. Utilitza aquest missatge per distingir quin
dels tres límits s'ha assolit.
example: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
examples:
Session-create limit:
summary: Més de 600 sol·licituds de creació de sessió per minut
value:
detail: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
Sandbox session quota:
summary: >-
L'aplicació de sandbox ha superat les 500 sessions en 24
hores
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ítol que es mostra al signant. Per defecte és `file_name`.
file_name:
type: string
minLength: 1
maxLength: 255
description: Nom de fitxer, que acaba en `.pdf` o `.docx`.
content_base64:
type: string
format: byte
description: >-
El fitxer, codificat en base64. Un PDF pot tenir fins a 20 MB i 100
pàgines, sense contrasenya, scripts ni fitxers adjunts. Un fitxer de
Word (`.docx`) pot tenir fins a 20 MB i es converteix a PDF mentre
s'executa la sol·licitud, en un màxim de 25 segons; el PDF té
llavors els mateixos límits. Fins a 5 fitxers de Word per sessió. Un
fitxer de Word amb macros, control de canvis, enllaços a contingut
extern o objectes incrustats es rebutja amb
`signature_document_not_supported`, i un que no es pugui convertir
retorna `signature_document_conversion_failed`, cadascun amb un
`reason`.
fields:
type: array
description: >-
Camps opcionals per col·locar en aquest document, fins a 200. Les
pàgines i posicions fan referència al PDF, o al PDF convertit en el
cas d'un fitxer Word. Sense camps, el signant llegeix el document i
l'accepta.
items:
$ref: '#/components/schemas/SignatureField'
maxItems: 200
SignatureField:
type: object
description: >-
Un camp per col·locar en un document de la sessió: quin signant l'omple,
com i on. Indica una posició (`page`, `x`, `y`, `width` i `height`) o un
`anchor`. Les posicions són fraccions de la pàgina tal com es mostra,
des de la cantonada superior esquerra, arrodonides a 4 decimals, i el
camp ha de cabre dins de la pàgina. Un document admet fins a 200 camps i
un signant fins a 500, i cada rol amb camps en un document necessita un
camp `signature` o `initials`. Consulta [Camps al
document](/ca/core-technology/electronic-signature/overview#camps-al-document).
required:
- key
- type
properties:
key:
type: string
pattern: ^[a-z][a-z0-9_]{0,63}$
description: >-
Dona nom al camp als resultats i a `sign.field_values`. Únic dins
del document.
type:
type: string
enum:
- signature
- initials
- full_name
- date_signed
- text
- checkbox
- email
- data
description: >-
Què conté el camp. El signant aplica la seva `signature` i
`initials` adoptades, escriu `text`, marca una `checkbox` i escriu
un `email` quan la sessió no té cap correu verificat. Didit emplena
`full_name` (el nom verificat), `date_signed` (la data de signatura,
en la zona horària del signant), `data` (a partir de `prefill`) i un
`email` verificat, i els mostra només de lectura. No hi ha cap tipus
de selector de dates: utilitza `text`.
role:
type: string
enum:
- verified_person
- legal_representative
- key_people
description: >-
Qui emplena el camp, amb els valors de `signature_signer`. Un pas
només emplena i segella els camps del seu propi signatari. Per
defecte és el signatari del pas.
page:
type: integer
minimum: 1
description: >-
Número de pàgina, des d'1 fins al total de pàgines del document. Per
a un document de Word, una pàgina del PDF convertit.
x:
type: number
minimum: 0
maximum: 1
description: Vora esquerra, com a fracció de l'amplada de la pàgina.
'y':
type: number
minimum: 0
maximum: 1
description: Vora superior, com a fracció de l'alçada de la pàgina.
width:
type: number
minimum: 0.02
maximum: 1
description: >-
Amplada, com a fracció de l'amplada de la pàgina. Una signatura té
una amplada mínima de `0.12`.
height:
type: number
minimum: 0.012
maximum: 1
description: >-
Alçada, com a fracció de l'alçada de la pàgina. Una signatura fa com
a mínim `0.035` d'alçada.
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: >-
Es mostra al signant i als resultats. Pren el valor per defecte del
tipus.
placeholder:
type: string
nullable: true
maxLength: 80
description: Només `text` i `email`.
validation:
$ref: '#/components/schemas/SignatureFieldValidation'
prefill:
type: string
nullable: true
description: >-
D'on prové el valor: `identity.full_name`, `identity.first_name`,
`identity.last_name`, `identity.date_of_birth` (`DD/MM/YYYY`),
`identity.nationality`, `identity.document_number`,
`identity.document_type`, `identity.issuing_country`,
`identity.address`, `contact.email`, `contact.phone`,
`company.name`, `company.registration_number`, `company.address`,
`company.country` (KYB), `session.vendor_data`, `metadata.`
(una clau de `metadata` de la sessió) o `api.` (una clau de
`sign.field_values`). Obligatori per a `data`. `full_name` sempre
utilitza `identity.full_name` i `email` utilitza `contact.email`.
Els valors dels camps `data`, `full_name` i `email` verificat es
fixen quan el signant comença a signar.
editable_when_prefilled:
type: boolean
default: false
description: >-
Només `text` i `email`: el signant pot canviar un valor emplenat
prèviament.
checked_by_default:
type: boolean
default: false
description: 'Només `checkbox`: la casella comença marcada.'
date_format:
type: string
enum:
- DD/MM/YYYY
- MM/DD/YYYY
- YYYY-MM-DD
- D MMMM YYYY
default: DD/MM/YYYY
description: Només `date_signed`.
SignatureFieldAnchor:
type: object
description: >-
Col·loca un camp mitjançant un fragment de text al document en lloc
d'una posició. Didit no elimina el text del PDF, per la qual cosa
escriu-lo en el mateix color que el fons de la pàgina. Quan el text no
es troba, la crida retorna `400` amb `field_anchor_not_found`. Consulta
[Col·locar camps mitjançant text
d'ancoratge](/ca/sessions-api/create-session#col·locar-camps-mitjançant-text-d’ancoratge).
required:
- text
properties:
text:
type: string
minLength: 1
maxLength: 64
description: Text cercat al document. Per a un fitxer de Word, al PDF convertit.
occurrence:
type: string
enum:
- first
- all
default: first
description: >-
`all` col·loca un camp per coincidència; les claus posteriors a la
primera reben `_2`, `_3`, etc.
offset_x:
type: number
description: >-
Afegit a la vora esquerra del text, com a fracció de l'amplada de la
pàgina.
offset_y:
type: number
description: >-
Afegit a la vora superior del text, com a fracció de l'alçada de la
pàgina.
width:
type: number
minimum: 0.02
maximum: 1
description: Amplada del camp, com a fracció de l'amplada de la pàgina.
height:
type: number
minimum: 0.012
maximum: 1
description: Alçada del camp, com a fracció de l'alçada de la pàgina.
SignatureFieldValidation:
type: object
nullable: true
description: >-
Regles per al valor d'un camp `text`. La previsualització a la consola,
el flux de signatura i l'API apliquen les mateixes regles.
properties:
kind:
type: string
enum:
- any
- letters
- number
- email
- pattern
description: >-
`letters`: lletres en qualsevol sistema d'escriptura, espais, guions
i apòstrofs. `number`: dígits amb un separador decimal opcional.
`pattern`: el valor ha de coincidir amb `pattern`.
min_length:
type: integer
minimum: 0
maximum: 500
description: De `0` fins a `max_length`.
max_length:
type: integer
minimum: 1
maximum: 500
default: 120
pattern:
type: string
nullable: true
minLength: 1
maxLength: 200
description: >-
Obligatori amb `kind: "pattern"`. Una expressió regular amb la qual
ha de coincidir el valor complet. No s'admeten lookarounds ni
referències enrere.
message:
type: string
nullable: true
maxLength: 120
description: Es mostra al signant en lloc de l'error per defecte.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
La clau d'API de la teva aplicació, des de Developers -> API keys a la
Business Console. La clau primària té accés complet. Una clau amb nom
pot tenir l'abast limitat: cap, lectura o escriptura per recurs,
limitada a determinats fluxos de treball o a sessions aprovades, a una
llista d'adreces IP i a una data de caducitat. 401 significa que la clau
és incorrecta, revocada o caducada; 403 significa que no s'ha enviat cap
clau, que la clau no té accés a aquest recurs o acció, o que la
sol·licitud prové d'una adreça fora de la seva llista d'IP; 404 en una
ruta de sessió significa que la sessió està fora dels fluxos de treball
o estats de la clau. Una clau sense accés a fitxers multimèdia rep els
URL d'imatge, vídeo i PDF com a null, i una clau sense permís
d'escriptura de sessions rep els enllaços de sessió i els tokens com a
null. Consulta https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.