> ## 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 Create Session : lancer une vérification KYC ou KYB
> Démarrez une vérification avec Didit via POST /v3/session/. KYC + KYB unifié, paiement à l'usage, inférence < 2 s, $10 offerts/mois.
Prompt de création de session
Copier le prompt dans le presse-papiers
\
\`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.`
\
Coller dans
## Prise en charge KYC et KYBUn seul endpoint crée à la fois des sessions de vérification des utilisateurs et des sessions de vérification d'entreprise. Le **type du workflow** détermine le type de session :- Transmettez un `workflow_id` de **workflow KYC** → une session de vérification d'identité (KYC) est créée. Réponse `session_kind: "user"`.
- Transmettez un `workflow_id` de **workflow KYB** → une session de vérification d'entreprise (KYB) est créée. Réponse `session_kind: "business"`.Configurez les workflows dans la console, à l'adresse *Workflows → Create workflow*. Un workflow est soit KYC, soit KYB, dès sa création ; vous ne pouvez pas changer ensuite son type.## Exemples> [tab] Vérification des utilisateurs (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"
> }'
> ```
>
> **Réponse (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] Vérification d'entreprise (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"
> }'
> ```
>
> **Réponse (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 signature électroniqueLorsque le workflow comporte une étape [Signature électronique](https://docs.didit.me/fr/core-technology/electronic-signature/overview.md) qui reprend des documents de la session (`signature_documents_source` défini sur `session` ou `both`), envoyez-les dans `sign.documents`. Chaque document est le fichier encodé en base64, afin que Didit n'ait jamais besoin de le récupérer depuis une 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" }
}
}
```| Champ | Règles |
| - | - |
| `title` | Affiché au signataire. De 1 à 255 caractères. Prend par défaut la valeur de `file_name`. |
| `file_name` | Obligatoire. Se termine par `.pdf` ou `.docx`. De 1 à 255 caractères. |
| `content_base64` | Obligatoire. Un PDF peut atteindre 20 Mo et 100 pages, sans mot de passe, script ni fichier joint. Un fichier Word peut atteindre 20 Mo et est converti en PDF pendant le traitement de la requête, en 25 secondes au maximum ; le PDF obtenu est alors soumis aux mêmes limites. Jusqu'à 5 fichiers Word par session. |
| `fields` | Facultatif. Jusqu'à 200 [champs](https://docs.didit.me/fr/core-technology/electronic-signature/overview.md#champs-sur-le-document) à placer sur le document, au format d'un champ sans `id`. Chaque champ requiert une `key` et un `type`, ainsi qu'une position (`page`, `x`, `y`, `width` et `height`) ou une [`anchor`](#placer-les-champs-par-texte-d’ancrage). `role` prend par défaut le signataire de l'étape, et `required` et `label` prennent leurs valeurs par défaut selon le type. Didit définit `position` à partir de l'emplacement du champ. Les pages et les positions se rapportent au PDF, ou au PDF converti pour un fichier Word. |Sans `fields`, le signataire lit le document et l'accepte.### Placer les champs par texte d'ancrageAu lieu d'une position, un champ peut porter une `anchor` : un extrait de texte du document qui indique où le champ doit être placé. Les ancres conviennent aux documents que vous générez pour chaque session, par exemple à partir d'un modèle Word. Pour les documents du workflow, placez les champs dans la console.| Propriété de `anchor` | Règles |
| - | - |
| `text` | De 1 à 64 caractères, recherché dans le texte du document. Pour un fichier Word, la recherche s'effectue dans le PDF converti. |
| `occurrence` | `first` (par défaut) place un champ à la première occurrence. `all` place un champ à chaque occurrence, et les clés après la première reçoivent `_2`, `_3`, et ainsi de suite. |
| `offset_x`, `offset_y` | Fractions de la page. Le coin supérieur gauche du champ correspond au coin supérieur gauche du texte d'ancrage, auquel s'ajoutent ces décalages. |
| `width`, `height` | La taille du champ, en fractions de la page. |Lorsque le texte est absent du document, l'appel renvoie `400` avec `field_anchor_not_found` et la clé du champ. Didit ne supprime pas le texte d'ancrage du PDF ; écrivez-le donc dans la même couleur que le fond de la page.### Valeurs des champs`sign.field_values` définit la valeur de chaque champ dont `prefill` est `api.`, qu'il s'agisse de documents du workflow ou de documents de session. Il s'agit d'un objet indexé par ces noms ``. Les valeurs sont des chaînes de 1 à 500 caractères pour les champs `text` et `data`, et des booléens pour une `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" }
}
}
```| Erreur (`400`) | Cas |
| - | - |
| `field_value_unknown` | Une clé qu'aucun champ n'utilise. |
| `field_value_missing` | Un champ obligatoire dont `api.` n'a pas de valeur. |
| `field_value_invalid` | Une valeur qui ne respecte pas la [validation](https://docs.didit.me/fr/core-technology/electronic-signature/overview.md#validation) de son champ. |### Erreurs et appels répétésUne session accepte jusqu'à 20 documents et 50 Mo au total. L'appel renvoie `400` avec une erreur `sign` lorsque :- Le workflow ne comporte aucune étape de signature électronique.
- Vous avez envoyé `sign.documents` alors que l'étape n'accepte que les documents du workflow.
- L'étape n'accepte que les documents de session et vous n'en avez envoyé aucun, ou elle ne comporte aucun document de workflow et vous n'en avez envoyé aucun.
- Un document est trop volumineux, n'est pas du base64 valide ou n'est pas un fichier pris en charge.
- Un fichier Word est refusé avec `signature_document_not_supported`, ou ne peut pas être converti et renvoie `signature_document_conversion_failed`, chacun avec le `reason` indiqué dans [Fichiers pris en charge](https://docs.didit.me/fr/core-technology/electronic-signature/overview.md#fichiers-pris-en-charge).
- Un champ est invalide, son ancre est introuvable (`field_anchor_not_found`), ou une [valeur de champ](#valeurs-des-champs) est refusée.Un nouvel appel de création pour le même `workflow_id` et le même `vendor_data` renvoie la session en attente. Si cet appel envoie `sign`, ses documents, ses champs et ses valeurs de champs doivent être identiques à ceux du premier appel (même ordre, mêmes titres, noms de fichiers, contenus, champs et valeurs). Toute différence renvoie `400` avec `{"sign": "signature_document_changed"}` : utilisez un autre `vendor_data`, ou attendez que la session en attente soit terminée.## Tester avec les scénarios sandboxSur une application en mode sandbox, transmettez `sandbox_scenario` pour précharger un résultat déterministe (approbation, un refus spécifique ou un scénario En cours d'examen) sans solliciter de vrais fournisseurs ni toucher à votre solde :```json theme={null}
{
"workflow_id": "YOUR_SANDBOX_WORKFLOW_ID",
"sandbox_scenario": "decline_document_expired"
}
````sandbox_scenario` est rejeté avec `400` sur les applications en production. Si vous ne connaissez pas encore le résultat au moment de la création, configurez-le (ou reconfigurez-le) plus tard via `POST /v3/session/{session_id}/sandbox/arm/`, tant que la session est toujours `Not Started` : le sélecteur de scénario préalable du parcours hébergé utilise ce même endpoint. Consultez [Sandbox et données de test](https://docs.didit.me/fr/integration/sandbox-testing.md) pour le catalogue complet des scénarios, le registre des valeurs magiques et la structure de requête et de réponse de l'endpoint d'armement.## `vendor_data` rattache la session à une entité- Pour les workflows KYC : rattache la session à une [entité utilisateur](https://docs.didit.me/fr/entities/users/overview.md). Si l'utilisateur n'existe pas, il est créé automatiquement.
- Pour les workflows KYB : rattache la session à une [entité entreprise](https://docs.didit.me/fr/entities/businesses/overview.md). Créée automatiquement si elle est nouvelle.Pour en savoir plus, consultez [liaison des données fournisseur](https://docs.didit.me/fr/entities/vendor-data-linking.md).## Consentement biométrique dans l'Illinois, le Texas et le ColoradoLe parcours hébergé et le SDK natif 4.10.0 ou ultérieur peuvent afficher une étape de consentement biométrique explicite avant la première capture du visage, selon le mode de consentement de l'application et le lieu où se trouve la personne. Deux champs facultatifs alimentent cette décision :- `user_state` : le lieu de résidence de la personne, lorsque vous le connaissez (`US-IL`, `IL` ou `Illinois`). En mode Auto, un État concerné déclenche l'affichage de l'étape.
- `biometric_consent` : un objet contenant `given_at` et `text_version`, pour un consentement que vous avez déjà recueilli. Le parcours ne le redemande pas.Les SDK natifs antérieurs à 4.10.0 ne peuvent pas afficher cette étape : leurs sessions se déroulent comme auparavant, et la décision indique que le consentement n'a pas été recueilli. Voir [Consentement biométrique](https://docs.didit.me/fr/getting-started/biometric-consent.md).## Important : la communication des informations et le recueil du consentement ont toujours lieu dans votre produit`Create Session` génère une URL de vérification et un token de session. Cet appel ne prouve **pas**, à lui seul, que vous avez communiqué à l'utilisateur les informations légales ou recueilli le consentement requis pour votre cas d'usage précis.Si vous démarrez une session Didit depuis votre propre application, votre site web, un wrapper de SDK ou un parcours en marque blanche, vous devriez gérer la couche juridique dans votre propre expérience utilisateur, avant que l'utilisateur ne commence la capture.## Liste de contrôle recommandée avant la vérification1. Indiquez à l'utilisateur que **votre entreprise** demande la vérification et que **Didit** est le prestataire de vérification / sous-traitant qui assure le fonctionnement du parcours.
2. Renvoyez vers **votre avis de confidentialité** et vers toutes les conditions juridiques applicables côté responsable du traitement pour ce parcours.
3. Renvoyez vers l'[Avis de confidentialité de la vérification](https://didit.me/terms/verification-privacy-notice) et les [Conditions d'utilisation pour l'utilisateur final de la vérification d'identité](https://didit.me/terms/identity-verification) de Didit.
4. Si votre workflow comprend une capture de document, une capture de selfie, une détection du vivant ou des données biométriques, recueillez un **consentement explicite et affirmatif** partout où la loi applicable ou votre position juridique l'exige.
5. Si vous utilisez une interface personnalisée, un domaine personnalisé ou un parcours uniquement via l'API, affichez ces informations dans votre propre produit avant d'envoyer l'utilisateur vers le parcours Didit.
6. Conservez votre propre trace de l'avis d'information ou du texte de consentement, de l'horodatage et des métadonnées associées, si votre service juridique exige une piste d'audit.> [!WARNING]
>
> Les exigences légales varient selon les juridictions. Le marquage en marque blanche ne retire pas à Didit son rôle dans le parcours de vérification. Faites relire votre implémentation par un conseil juridique avant le lancement si vous opérez dans des juridictions soumises à des règles spécifiques à la biométrie.
## OpenAPI
````yaml fr/openapi-25.json POST /v3/session/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API de vérification d'identité. Authentifiez-vous avec l'en-tête x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/session/:
post:
tags:
- Sessions
summary: Créer une session de vérification
description: >-
Créez une session de vérification des utilisateurs (KYC) ou de
vérification d'entreprise (KYB) et recevez une `url` de vérification
hébergée ainsi qu'un `session_token` pour rediriger votre utilisateur
final vers cette page ou l'intégrer directement. Le `workflow_id`
détermine les étapes de vérification exécutées et si la session est de
type KYC ou KYB.
Appelez cet endpoint depuis votre backend (jamais depuis le navigateur —
la clé API est secrète) chaque fois qu'un utilisateur ou une entreprise
doit être vérifié : lors de l'inscription, avant une action sensible ou
lorsqu'une revérification est requise. Prérequis : un workflow publié
(créé sur la page
[Workflows](https://docs.didit.me/fr/console/workflows) de la Console)
et une clé API d'application disposant de crédits. Les applications
sandbox contournent la vérification des crédits.
**Idempotence :** lorsque `vendor_data` est fourni et qu'une session
inachevée (`Not Started`, `In Progress`, `Resubmitted` ou `Awaiting
User`) avec le même `vendor_data` existe déjà sur la **dernière version
publiée actuelle** du workflow (et que cette session dispose déjà d'une
URL de vérification hébergée), la session existante est renvoyée
(toujours en `201`) au lieu de créer un doublon — avec son `callback` et
ses `metadata` mis à jour selon les nouvelles valeurs fournies. Une
session inachevée créée sur une version antérieure du workflow (qui a
été republiée depuis) n'est **pas** réutilisée ; une nouvelle session
rattachée à la dernière version publiée est créée à la place. Les
sessions avec le statut `Approved`, `Declined`, `In Review`, `Expired`,
`Abandoned` ou `Kyc Expired` ne sont jamais réutilisées.
**Effets secondaires :** l'URL de vérification hébergée est générée et
stockée ; si `contact_details.send_notification_emails` est défini sur
`true` et qu'une adresse e-mail est fournie, un e-mail d'invitation à la
vérification est envoyé. La session expire après la durée d'expiration
configurée pour le workflow. Pour les workflows KYB,
`contact_details.phone` et `expected_details` sont ignorés.
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: >-
Identifiant stable du workflow définissant les étapes de
vérification que la session exécutera. Les workflows sont
créés et gérés sur la page
[Workflows](/fr/console/workflows) de la Console. Le
paramètre `workflow_id` détermine également implicitement si
la session relève du KYC ou du KYB.
example: 11111111-2222-3333-4444-555555555555
x-readme-id: '0.0'
vendor_data:
type: string
description: >-
Un identifiant unique pour l'utilisateur en cours de
vérification, tel qu'un UUID, une adresse e-mail ou un
identifiant utilisateur interne. Ce champ sert à : (1)
**Regroupement d'utilisateurs** — les sessions ayant le même
vendor_data sont associées au même profil utilisateur dans
l'onglet Utilisateurs. (2) **Détection de doublons entre
sessions** — lors de la vérification de visages, documents,
numéros de téléphone, e-mails, adresses IP ou empreintes
d'appareils dupliqués, les sessions avec le même vendor_data
sont traitées comme étant le même utilisateur et exclues des
correspondances. Sans vendor_data, chaque session est
traitée comme un utilisateur unique et tous les doublons
potentiels sont signalés. Nous recommandons vivement de
toujours fournir un vendor_data afin de réduire le bruit
dans la détection des doublons.
example: user-123
x-readme-id: '0.1'
multi_account_segment:
type: string
maxLength: 64
description: >-
Domaine optionnel de détection de doublons au sein de votre
organisation. Les vérifications de visages en double
comparent cette session uniquement avec d'autres sessions
portant le même segment, afin que des bases de comptes
distinctes (comptes personnels et professionnels, ou une par
sous-client B2B) ne signalent pas une personne détenant
légitimement un compte dans chacune. Omettez-le pour
utiliser le domaine unique par défaut, qui est celui utilisé
par chaque session actuellement. La mise en correspondance
avec la liste de blocage et la liste d'autorisation ignore
ce champ.
example: business-accounts
callback:
type: string
description: "URL vers laquelle rediriger l'utilisateur une fois la vérification terminée. Didit ajoute automatiquement `verificationSessionId` et `status` (Approved, Declined, In Review) en tant que paramètres de requête. Les schémas d'URL personnalisés (par exemple `myapp://`) sont pris en charge pour les rappels mobiles. En cas d'omission, le `callback_url` par défaut du workflow est utilisé. Lorsque l'application a des domaines autorisés (`allowed_domains` sur `PATCH /v3/webhook/`), un rappel `http` ou `https` doit appartenir à l'une de ces origines (le même schéma, le même hôte et le même port), sinon la requête échoue avec 400 sur `callback`\_: `callback must be on one of the application's allowed domains: https://app.example.com`. Les schémas d'URL personnalisés sont toujours acceptés."
example: https://example.com/verification/callback
x-readme-id: '0.2'
callback_method:
type: string
description: >-
Détermine quel appareil doit gérer la redirection vers l'URL
de rappel fournie. Utilisez `initiator` pour rediriger
uniquement l'appareil qui a démarré le flux, `completer`
pour l'appareil qui le termine, ou `both` pour autoriser
l'un ou l'autre appareil à déclencher le rappel. Si vous
constatez que le rappel ne se déclenche pas de manière
fiable, nous vous recommandons de définir cette valeur sur
`both`.
enum:
- initiator
- completer
- both
default: initiator
example: both
x-readme-id: '0.3'
metadata:
description: >-
JSON arbitraire stocké avec la session et renvoyé dans la
réponse et les webhooks. Toute valeur JSON est acceptée
(objet, chaîne, nombre, tableau), mais un objet JSON de
paires clé/valeur est recommandé. Non visible par
l'utilisateur final. Utilisez-le pour transmettre vos
propres identifiants de corrélation, variantes d'A/B testing
ou contexte métier.
example:
user_type: premium
account_id: ABC123
x-readme-id: '0.4'
tags:
type: array
items:
type: string
maxLength: 50
maxItems: 10
description: >-
Tags ajoutés à la session lors de sa création, par leur nom.
Jusqu'à 10, de 50 caractères maximum chacun. Les noms sont
insensibles à la casse et stockés en majuscules. Un nom qui
n'existe pas encore dans l'application est créé en tant que
nouveau tag. Les tags s'affichent sur la session dans la
console, où vous pouvez filtrer selon ces derniers.
example:
- VIP
- ONBOARDING Q4
language:
type: string
description: >-
Code de langue (ISO 639-1) pour l'interface du processus de
vérification. Contrôle la langue affichée à l'utilisateur
final pendant la vérification. S'il n'est pas fourni, la
langue du navigateur sera automatiquement détectée et
utilisée. Consultez toutes les langues prises en charge
[ici](/fr/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: >-
Coordonnées de l'utilisateur pouvant être utilisées pour les
notifications, le préremplissage des formulaires de
vérification et la vérification du téléphone. Cela comprend
l'adresse e-mail, la langue préférée pour les communications
et le numéro de téléphone.
example:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
properties:
email:
type: string
format: email
description: >-
Adresse e-mail de l'utilisateur (par exemple, «
john.doe@example.com ») qui sera utilisée lors de
l'étape de [Vérification de
l'e-mail](/fr/core-technology/email-verification/overview).
Si elle n'est pas fournie, l'utilisateur doit la
renseigner pendant le flux de vérification.
example: john.doe@example.com
x-readme-id: '1.0'
send_notification_emails:
type: boolean
default: false
description: >-
Si true et qu'un e-mail est fourni, Didit envoie
l'e-mail initial « Vérifiez votre identité » de manière
asynchrone lors de la création de la session de
vérification des utilisateurs (KYC) ou de vérification
d'entreprise (KYB). Didit envoie également les
notifications de statut de vérification pour les
sessions nécessitant un examen manuel à l'adresse e-mail
fournie (par exemple, de « In Review » à « Approved » ou
« Declined »). Cela aide les utilisateurs à revenir sur
votre application une fois leur vérification terminée.
Si la marque blanche est activée pour la session,
l'e-mail envoyé sera en marque blanche.
example: true
x-readme-id: '1.1'
email_lang:
type: string
description: >-
Code de langue (ISO 639-1) pour les notifications par
e-mail. Contrôle la langue de toutes les communications
par e-mail (par exemple, "en", "es", "fr"). Aucune
valeur par défaut n'est stockée — en cas d'omission,
l'e-mail d'invitation à la vérification bascule
simplement sur l'anglais (`en`) au moment de l'envoi.
L'enum ci-dessous est un aperçu ; la source de référence
en temps réel pour les valeurs acceptées est la
documentation des [langues prises en
charge](/fr/integration/supported-languages) —
consultez-la systématiquement avant de vous fier à un
code spécifique.
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: >-
Numéro de téléphone au format E.164 (par ex.
"+14155552671") qui sera utilisé lors de l'étape de
[Vérification du
téléphone](/fr/core-technology/phone-verification/overview).
S'il n'est pas fourni, l'utilisateur doit le fournir
pendant le flux de vérification. Ignoré pour les
workflows de Vérification d'entreprise (KYB).
**Important :** Ce numéro de téléphone n'est appliqué
que s'il s'agit d'un numéro de téléphone E.164 valide.
Si le numéro fourni est invalide ou ne peut pas être
analysé, il sera ignoré et l'utilisateur pourra saisir
n'importe quel numéro de téléphone valide lors de
l'étape de vérification du téléphone.
example: '+14155552671'
x-readme-id: '1.3'
x-readme-id: '0.4'
expected_details:
type: object
description: >-
Informations attendues sur l'utilisateur utilisées pour la
validation croisée avec les données extraites de sa pièce
d'identité, du Justificatif de domicile et d'autres étapes
de vérification. Les discordances apparaissent sous forme
d'avertissements sur la décision ; certains champs (par ex.
`id_country`, `expected_document_types`) modifient également
le parcours côté utilisateur. Pour les workflows de
Vérification d'entreprise (KYB), seuls les champs relatifs à
l'entreprise (`company_name`, `registry_country`,
`registration_number`) sont utilisés — ils préremplissent la
recherche dans le registre des sociétés pour l'utilisateur —
et tous les champs relatifs aux personnes physiques sont
ignorés.
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: >-
Prénom de l'utilisateur. Par exemple, `John`. La
correspondance utilise une comparaison approximative, et
vous pouvez ajuster la rigueur en configurant le seuil
de score de correspondance du nom dans la Console pour
les workflows Justificatif d'identité et Justificatif de
domicile.
example: John
x-readme-id: '1.0'
last_name:
type: string
description: >-
Nom de famille de l'utilisateur. Par exemple, `Doe`. La
correspondance utilise une comparaison approximative, et
vous pouvez ajuster la rigueur en configurant le seuil
de score de correspondance du nom dans la Console pour
les workflows Justificatif d'identité et Justificatif de
domicile.
example: Doe
x-readme-id: '1.1'
date_of_birth:
type: string
format: date
description: "Date de naissance de l'utilisateur au format\_: YYYY-MM-DD. Par exemple, `1990-05-15`."
example: '1990-05-15'
x-readme-id: '1.2'
gender:
type: string
nullable: true
enum:
- M
- F
default: null
description: Genre de l'utilisateur. Doit être 'M', 'F' ou null.
example: M
x-readme-id: '1.3'
nationality:
type: string
description: >-
Code pays ISO 3166-1 alpha-3 représentant le pays
d'origine du candidat. Par exemple, `USA`. Voir la
[liste complète des codes pays pris en
charge](https://docs.didit.me/fr/core-technology/id-verification/supported-documents-id-verification#documents-pris-en-charge-par-pays).
example: USA
x-readme-id: '1.4'
country:
type: string
description: >-
Code pays ISO 3166-1 alpha-3 utilisé comme solution de
repli pour les vérifications de non-concordance de pays
de la Vérification d'identité et du Justificatif de
domicile. Requis lorsque `address` est fournie et que ni
`id_country` ni `poa_country` ne sont définis.
example: USA
x-readme-id: 1.4.1
id_country:
type: string
description: >-
Code pays ISO 3166-1 alpha-3 représentant le pays
attendu du document d'identité du candidat, qui peut
différer de la nationalité. Par exemple, `GBR`.
Prévaudra sur `country` pour les vérifications de
non-concordance de pays de la vérification d'identité.
Voir la [liste complète des codes pays pris en
charge](https://docs.didit.me/fr/core-technology/id-verification/supported-documents-id-verification#documents-pris-en-charge-par-pays).
example: GBR
x-readme-id: '1.5'
poa_country:
type: string
description: >-
Code pays ISO 3166-1 alpha-3 représentant le pays
attendu du document de Justificatif de domicile. Par
exemple, `USA`. Prévaudra sur `country` pour les
vérifications de non-concordance de pays du justificatif
de domicile. Voir la [liste complète des codes pays pris
en
charge](https://docs.didit.me/fr/core-technology/id-verification/supported-documents-id-verification#documents-pris-en-charge-par-pays).
example: USA
x-readme-id: 1.5.1
address:
type: string
description: >-
L'adresse dans un format lisible par un humain,
comprenant autant d'informations que possible. Par
exemple, `123 Main St, San Francisco, CA 94105, USA`.
Lorsqu'elle est fournie, vous devez également
transmettre `country` ou `poa_country`, sinon la requête
échoue avec `400`.
example: 123 Main St, San Francisco, CA 94105, USA
x-readme-id: '1.6'
identification_number:
type: string
description: >-
Le numéro de document, le numéro personnel ou
l'identifiant fiscal de l'utilisateur. Par exemple,
`123456789`.
example: '123456789'
x-readme-id: '1.7'
ip_address:
type: string
description: >-
Adresse IP attendue pour la session, au format IPv4 ou
IPv6. Si l'adresse IP réelle diffère de cette valeur, un
avertissement sera consigné. Par exemple,
`192.168.1.100` ou `2001:db8::1`.
example: 192.168.1.100
x-readme-id: '1.8'
expected_document_types:
type: array
description: >-
Restreint les types de documents que l'utilisateur peut
présenter lors de l'étape de vérification d'identité
(OCR). Lorsqu'il est défini, l'écran de sélection de
document affiche uniquement les types demandés et le
`documents_allowed` renvoyé est filtré en conséquence.
Les valeurs sont insensibles à la casse et dédupliquées
; les valeurs inconnues sont rejetées avec `400`. Codes
autorisés : `P` (passeport), `ID` (carte d'identité
nationale), `DL` (permis de conduire), `RP` (titre de
séjour), `HIC` (carte d'assurance maladie), `TC` (carte
fiscale), `SSC` (carte de sécurité sociale).
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: >-
Raison sociale attendue de l'entreprise en cours de
vérification. Par exemple, `Tesco PLC`. Préremplit le
champ du nom de l'entreprise lors de la recherche dans
le registre pour les workflows de Vérification
d'entreprise (KYB) ; lorsque `registration_number` est
également fourni, la recherche dans le registre combine
les deux identifiants. Ignoré pour les workflows KYC.
example: Tesco PLC
x-readme-id: '1.10'
registry_country:
type: string
maxLength: 10
description: >-
Code ISO 3166-1 alpha-2 du pays dans le registre des
sociétés duquel l'entreprise est enregistrée. Par
exemple, `GB`. Lorsque les registres des sociétés
fonctionnent au niveau de l'État ou de la province,
ajoutez le code de subdivision ISO 3166-2 sous la forme
`XX-YY` : `US-CA` cible le registre de Californie. Même
format que `country_code` sur l'[API de recherche dans
le registre
KYB](https://docs.didit.me/fr/standalone-apis/kyb-registry-search).
Présélectionne le pays du registre dans les workflows de
vérification d'entreprise (KYB) ; ignoré pour les
workflows KYC.
example: US-CA
x-readme-id: '1.11'
registration_number:
type: string
maxLength: 100
description: >-
Numéro d'immatriculation attendu de l'entreprise dans le
registre des sociétés. Par exemple, `00445790`.
Préremplit le champ du numéro d'immatriculation lors de
la recherche dans le registre pour les workflows de
Vérification d'entreprise (KYB) ; lorsque `company_name`
est également fourni, la recherche dans le registre
combine les deux identifiants. Ignoré pour les workflows
KYC.
example: '00445790'
x-readme-id: '1.12'
x-readme-id: '0.5'
portrait_image:
type: string
format: byte
description: "Image portrait du visage de l'utilisateur final encodée en Base64 (max 2 Mo\_; JPEG, PNG, WebP ou TIFF). Utilisée comme image de référence à comparer à la capture de détection du vivant lorsque le workflow est un workflow `Biometric Authentication` avec la Correspondance faciale activée, ou tout workflow en graphe où la Correspondance faciale s'exécute avant la vérification d'identité (OCR). Facultatif lorsque l'utilisateur identifié par `vendor_data` possède déjà une image de visage enregistrée\_: Didit la réutilise automatiquement, en appliquant l'ordre de priorité suivant\_: visage issu d'une détection du vivant approuvée, photo de puce d'ePassport, portrait de document d'identité, visage de profil enrôlé manuellement (seuls les visages issus de sessions approuvées ou les visages que vous avez vous-même enrôlés sont réutilisés). Lorsqu'elle est fournie, `portrait_image` prévaut toujours sur le visage enregistré. Si elle est omise et qu'aucun visage enregistré n'existe (ou que `vendor_data` n'est pas envoyé), la création de la session échoue avec une erreur `400`. Ignoré pour les autres types de workflow."
example: >-
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=
x-readme-id: '0.6'
sandbox_scenario:
type: string
description: >-
Slug de scénario réservé à la sandbox. Uniquement accepté
lorsque la clé API appartient à une application en mode
sandbox ; rejeté sur les applications en production.
Lorsqu'il est défini, le flux de création applique les
valeurs magiques associées au scénario sur les champs
d'entrée de la session (contact_details, expected_details)
afin que les fournisseurs simulés reproduisent le résultat
du scénario à travers le véritable pipeline de workflow.
Consultez le catalogue de scénarios via GET
/v1/sandbox/scenarios/ ou [Sandbox et données de
test](/fr/integration/sandbox-testing). Vous pouvez
également armer (ou réarmer) un scénario après la création
via POST /v3/session/{sessionId}/sandbox/arm/, tant que la
session est toujours à l'état `Not Started`. Pour la
recherche sans document, utilisez `lookup_partial_match`,
`lookup_no_match` ou `lookup_provider_error` afin de tester
le budget de tentatives configuré et le mécanisme de
secours. Pour les portefeuilles d'identité, utilisez
`wallet_cancelled`, `wallet_timeout` ou
`wallet_provider_error` ; `approve` simule un portefeuille
vérifié. Tous les portefeuilles du catalogue peuvent être
testés dans la sandbox, y compris les schémas non
disponibles sur les applications en production. Les
tentatives simulées ne sont pas facturées.
example: decline_document_expired
sign:
type: object
description: >-
Données d'entrée de Signature électronique pour cette
session. `documents` correspond aux documents à signer, pour
un workflow dont l'étape de Signature électronique extrait
les documents de la session (`signature_documents_source`
`session` ou `both`) : jusqu'à 20 documents et 50 Mo au
total. `field_values` renseigne les champs dont le `prefill`
est `api.`, aussi bien sur les documents du workflow
que de la session. Créer à nouveau une session pour les
mêmes `workflow_id` et `vendor_data` renvoie la session en
attente ; si cet appel transmet `sign`, ses documents,
champs et valeurs doivent être identiques aux premiers, et
toute différence renvoie `400` avec `{"sign":
"signature_document_changed"}`. Voir [Documents de signature
électronique](/fr/sessions-api/create-session#documents-de-signature-électronique).
properties:
documents:
type: array
minItems: 1
maxItems: 20
items:
$ref: '#/components/schemas/SessionSignDocument'
field_values:
type: object
description: >-
Valeurs indexées par la `` de chaque source de
préremplissage `api.` : chaînes de 1 à 500
caractères pour les champs `text` et `data`, booléens
pour une `checkbox`. `400` avec `field_value_unknown`
pour une clé qu'aucun champ n'utilise,
`field_value_missing` pour un champ obligatoire sans sa
valeur, et `field_value_invalid` pour une valeur qui
échoue à la validation de son champ.
additionalProperties:
oneOf:
- type: string
minLength: 1
maxLength: 500
- type: boolean
example:
credit_limit: 3,000 EUR
user_state:
type: string
maxLength: 16
description: >-
Lieu de résidence de la personne, lorsqu'il est connu : un
code de subdivision ISO 3166-2 (`US-IL`, `ES-M`) ou un code
ou nom d'État américain (`IL`, `Illinois`). Un État dont la
législation impose un consentement biométrique explicite
(Illinois, Texas, Colorado) amène le flux de vérification à
le demander avant de capturer un visage, avec le déclencheur
`declared_state`. Une valeur non reconnue renvoie `400`.
Voir [Consentement
biométrique](/fr/getting-started/biometric-consent).
example: US-IL
biometric_consent:
type: object
description: >-
Consentement biométrique explicite que vous avez déjà
recueilli auprès de la personne. Il satisfait à l'exigence,
de sorte que le flux de vérification ne le redemande pas, et
la décision l'enregistre avec `status: "given"` et le
déclencheur `customer_collected`. Une réponse déjà donnée
par la personne au cours du parcours n'est jamais remplacée.
Voir [Consentement
biométrique](/fr/getting-started/biometric-consent).
required:
- given_at
- text_version
properties:
given_at:
type: string
format: date-time
description: >-
Moment où la personne a donné son consentement
biométrique explicite (ISO 8601). Ne peut pas être dans
le futur.
text_version:
type: string
maxLength: 64
description: >-
Identifiant de version du texte de consentement que la
personne a accepté, dans vos propres dossiers.
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 du scénario nominal pour une session de
Vérification des utilisateurs (KYC)
description: >-
Appel de création réaliste utilisant chaque champ fréquemment
configuré : sélection du workflow, liaison du fournisseur,
routage de rappel, métadonnées, paramètres régionaux,
pré-remplissage des contacts et informations attendues sur
l'utilisateur. Copiez-collez ceci directement dans l'exemple
cURL ci-dessus.
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 de cas nominal pour une session de Vérification
d'entreprise (KYB)
description: >-
Même format que l'appel KYC — c'est le `workflow_id` qui fait
de la session une session KYB. `vendor_data` fait généralement
référence à l'entreprise dans votre système et
`contact_details.email` cible le représentant légal qui
effectuera le flux. `expected_details` accepte les champs
relatifs à l'entreprise (`company_name`, `registry_country`,
`registration_number`), qui préremplissent la recherche dans
le registre des sociétés ; les champs au niveau de la personne
et `contact_details.phone` sont ignorés pour les workflows
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: >-
Session créée (ou renvoyée, si une session non terminée avec les
mêmes `vendor_data` existe déjà sur la dernière version publiée du
workflow). La réponse est la session sérialisée, incluant l'`url` de
vérification hébergée vers laquelle rediriger l'utilisateur.
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: >-
Identifiant unique de la session de vérification. Utilisez
cet identifiant lors de l'appel à `GET
/v3/session/{sessionId}/decision/`.
example: 11111111-2222-3333-4444-555555555555
session_number:
type: integer
description: >-
Numéro séquentiel et lisible attribué à la session au sein
de votre application. Utile pour le support et les
tableaux de bord.
example: 43762
session_token:
type: string
description: >-
Token de 12 caractères compatible avec les URL autorisant
l'utilisateur final à accéder au flux de vérification
hébergé à `url`. Valide jusqu'à l'expiration de la
session. Traitez-le comme un secret — toute personne en sa
possession peut ouvrir le flux de vérification pour cette
session.
example: 3FaJ9wLqX2Mz
url:
type: string
format: uri
description: >-
URL de vérification hébergée vers laquelle rediriger
l'utilisateur final. L'URL intègre le `session_token` et,
si configuré, utilise votre domaine en marque blanche.
Lorsque la requête comprend `language`, l'URL contient un
segment de chemin de langue —
`https://verify.didit.me/{language}/session/{session_token}`
(par exemple `/es/session/...`) ; sans `language`, ce
segment est omis.
example: https://verify.didit.me/session/3FaJ9wLqX2Mz
vendor_data:
type: string
nullable: true
description: >-
Identifiant que vous avez transmis dans la requête pour
lier la session à un utilisateur ou une entreprise dans
votre propre système. Renvoyé textuellement. Null
lorsqu'il n'est pas fourni.
example: user-123
metadata:
description: >-
Payload JSON arbitraire que vous avez stocké avec la
session au moment de sa création. Renvoyé textuellement —
quelle que soit la valeur JSON envoyée (objet, chaîne,
nombre, tableau), elle est retournée telle quelle, bien
qu'un objet JSON soit recommandé. Non visible par
l'utilisateur final. Toujours présent dans les réponses ;
`null` lorsqu'il n'a pas été fourni lors de la création.
example:
user_type: premium
account_id: ABC123
tags:
type: array
items:
type: string
description: Les étiquettes sur la session, par 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: >-
Statut actuel de la session. Les sessions nouvellement
créées renvoient `Not Started`. Si une session non
terminée existait déjà pour le même `vendor_data` sur la
dernière version publiée du workflow, le statut renvoyé
reflète cette session existante.
example: Not Started
callback:
type: string
format: uri
nullable: true
description: >-
URL de redirection finale vers laquelle l'utilisateur est
renvoyé après avoir terminé le flux. Didit ajoute
`?verificationSessionId={session_id}&status={status}` à
cette URL. Se rabat sur l'URL de rappel configurée du
workflow si elle n'est pas fournie dans la requête ;
`null` si aucune n'est définie. Lorsque l'application a
des domaines autorisés et que cette URL est une URL web en
dehors de ceux-ci (par exemple une valeur par défaut de
workflow définie avant la modification de la liste), le
flux hébergé n'y redirige pas l'utilisateur.
example: https://example.com/verification/callback
workflow_id:
type: string
format: uuid
description: >-
Identifiant stable du workflow sur lequel s'exécute cette
session. Il s'agit toujours de l'identifiant de groupe
stable du workflow — même si vous avez référencé un UUID
de version de workflow spécifique dans la requête
(recherche rétrocompatible), la réponse contient le
`workflow_id` stable. Utilisez-le pour corréler la session
avec le workflow que vous avez configuré dans la Console.
example: 11111111-2222-3333-4444-555555555555
workflow_version:
type: integer
description: >-
Numéro de version de la version publiée du workflow à
laquelle la session a été associée lors de sa création.
Didit résout `workflow_id` vers la dernière version
publiée du workflow lorsque la session est créée, et la
session continue d'exécuter cette version même si le
workflow est republié ultérieurement.
example: 3
examples:
KYC session:
summary: Session KYC créée
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: Session KYB créée
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: >-
Requête incorrecte — le payload a échoué à la validation
(`workflow_id` manquant ou inconnu, `language` non valide,
`vendor_data` sur liste de blocage, `portrait_image` mal formée,
`address` sans `country`/`poa_country`, `sandbox_scenario` non
valide, documents, champs ou valeurs `sign` que l'étape de Signature
électronique du workflow refuse, tels que
`signature_document_not_supported`,
`signature_document_conversion_failed`, `field_anchor_not_found` ou
`field_value_missing`, etc.) ou votre organisation n'a pas assez de
crédits pour démarrer la session.
Le corps est un objet indexé par le nom du champ en cause (ou
`detail` pour les erreurs non liées à un champ précis). Les valeurs
sont un **tableau de chaînes** pour les échecs de validation des
entrées (par ex. champ obligatoire manquant, langue non valide,
image de portrait trop volumineuse) et une **chaîne simple** pour
les erreurs détectées lors de la création de la session
(`workflow_id` inconnu, `vendor_data` sur liste de blocage, aucun
visage de référence disponible pour un workflow de Correspondance
faciale). Gérez les deux formats.
content:
application/json:
schema:
type: object
additionalProperties: true
properties:
detail:
type: string
description: >-
Message d'erreur lisible par l'humain pour les erreurs non
liées à un champ (par ex. crédits insuffisants). Les
échecs au niveau d'un champ utilisent plutôt le nom du
champ comme clé, avec une valeur sous forme de chaîne ou
de tableau de chaînes.
example: >-
You don't have enough credits to perform this request.
Please top up at https://business.didit.me
examples:
Missing workflow_id:
summary: Champ obligatoire omis (format tableau de chaînes)
value:
workflow_id:
- This field is required.
Invalid workflow_id:
summary: workflow_id inconnu (format chaîne brute)
value:
workflow_id: Invalid workflow_id.
Insufficient credits:
summary: L'organisation n'a plus de 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 est sur liste de blocage
value:
vendor_data: >-
This user or business has been blocked and cannot create
new verification sessions.
Portrait image too large:
summary: portrait_image ne passe pas la validation de la taille
value:
portrait_image:
- Image size exceeds 2MB.
No stored face for vendor_data:
summary: >-
Workflow de Correspondance faciale sans portrait_image et
sans visage enregistré pour l'utilisateur 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: >-
Workflow de Correspondance faciale sans portrait_image et
sans 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: >-
Échec d'authentification ou d'autorisation. Une clé incorrecte,
révoquée ou expirée renvoie `401`. L'endpoint renvoie `403` lorsque
l'en-tête `x-api-key` est manquant ou que la clé API est valide mais
que le client n'a pas l'autorisation de créer des sessions dans
cette application (par exemple, la clé API appartient à une autre
organisation). Ces échecs partagent le corps `{"detail": "You do not
have permission to perform this action."}`. Vérifiez que l'en-tête
`x-api-key` est présent et appartient à l'application visée,
récupérez à nouveau la clé API de l'application via l'[API
Auth](/fr/auth-api/get-credentials) si nécessaire, puis réessayez.
**Application supprimée :** pendant quelques minutes après la
suppression d'une application, une requête effectuée avec l'une de
ses clés API peut répondre `{"detail": "This application was
deleted.", "code": "application_deleted"}`. Ne réessayez pas :
l'application et ses clés API n'existent plus. Après ces quelques
minutes, la clé est refusée comme n'importe quelle autre clé non
valide.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: You do not have permission to perform this action.
code:
type: string
description: >-
Raison lisible par machine, présente uniquement lors de
certains échecs. `application_deleted` : la clé API
appartient à une application qui a été supprimée.
example: application_deleted
required:
- detail
examples:
Missing or invalid API key:
summary: Aucun en-tête `x-api-key` ou clé API non valide
value:
detail: You do not have permission to perform this action.
No permission:
summary: Le client ne peut pas créer de sessions
value:
detail: You do not have permission to perform this action.
Application deleted:
summary: Clé API d'une application supprimée
value:
detail: This application was deleted.
code: application_deleted
'429':
description: >-
Limite de débit dépassée — plus de 600 requêtes de création de
session dans une fenêtre de 60 secondes depuis la même clé API / IP.
Examinez `Retry-After` et temporisez avant de réessayer.
**Remarque :** Le code source définit également une limite
`FREE_SESSION_RATE_LIMIT` de 10 appels/minute aux côtés de
`PAID_SESSION_RATE_LIMIT=600` (`sessions/serializers/session.py`),
mais ce plafond de l'offre gratuite n'est **pas appliqué à cet
endpoint V3** — le middleware de limitation de débit applique la
limite de 600/min `SESSION_CREATE_RATE_LIMIT` quel que soit le
forfait. 600/min est la seule limite que vous pouvez atteindre ici.
headers:
Retry-After:
description: >-
Nombre de secondes que l'appelant doit attendre avant de
réessayer la requête.
schema:
type: integer
minimum: 1
example: 42
X-RateLimit-Limit:
description: >-
Nombre maximal de requêtes autorisées dans la fenêtre actuelle
de 60 secondes pour la limite qui a été dépassée (600 pour
session-create). Absent sur la variante de quota sandbox.
schema:
type: integer
example: 600
X-RateLimit-Remaining:
description: >-
Nombre de requêtes encore autorisées dans la fenêtre actuelle
pour la limite dépassée. Absent sur la variante de quota
sandbox.
schema:
type: integer
minimum: 0
example: 0
X-RateLimit-Reset:
description: >-
Secondes epoch UTC auxquelles la fenêtre actuelle de limite de
débit est réinitialisée. Absent sur la variante de quota
sandbox.
schema:
type: integer
minimum: 0
example: 1747497600
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
Explication lisible par l'humain du dépassement de la
limite de débit. Utilisez ce message pour identifier
laquelle des trois limites a été atteinte.
example: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
examples:
Session-create limit:
summary: Plus de 600 requêtes de création de session par minute
value:
detail: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
Sandbox session quota:
summary: L'application en sandbox a dépassé 500 sessions en 24 heures
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: Titre affiché au signataire. Prend la valeur par défaut `file_name`.
file_name:
type: string
minLength: 1
maxLength: 255
description: Nom de fichier, se terminant par `.pdf` ou `.docx`.
content_base64:
type: string
format: byte
description: >-
Le fichier, encodé en base64. Un PDF peut faire jusqu'à 20 MB et 100
pages, sans mot de passe, scripts ou fichiers joints. Un fichier
Word (`.docx`) peut faire jusqu'à 20 MB et est converti en PDF
pendant l'exécution de la requête, en 25 secondes au maximum ; le
PDF a ensuite les mêmes limites. Jusqu'à 5 fichiers Word par
session. Un fichier Word contenant des macros, des modifications
suivies, des liens vers du contenu externe ou des objets incorporés
est refusé avec `signature_document_not_supported`, et un fichier
qui ne peut pas être converti renvoie
`signature_document_conversion_failed`, chacun avec une `reason`.
fields:
type: array
description: >-
Champs optionnels à placer sur ce document, jusqu'à 200. Les pages
et les positions font référence au PDF, ou au PDF converti pour un
fichier Word. Sans champs, le signataire lit le document et
l'accepte.
items:
$ref: '#/components/schemas/SignatureField'
maxItems: 200
SignatureField:
type: object
description: >-
Un champ à placer sur un document de session : quel signataire le
remplit, comment et où. Indiquez soit une position (`page`, `x`, `y`,
`width` et `height`), soit un `anchor`. Les positions sont des fractions
de la page telle qu'elle est affichée, depuis son coin supérieur gauche,
arrondies à 4 décimales, et le champ doit s'insérer dans la page. Un
document accepte jusqu'à 200 champs et un signataire jusqu'à 500, et
chaque rôle ayant des champs sur un document nécessite un champ
`signature` ou `initials` sur celui-ci. Consultez [Champs sur le
document](/fr/core-technology/electronic-signature/overview#champs-sur-le-document).
required:
- key
- type
properties:
key:
type: string
pattern: ^[a-z][a-z0-9_]{0,63}$
description: >-
Indique le nom du champ dans les résultats et dans
`sign.field_values`. Unique au sein du document.
type:
type: string
enum:
- signature
- initials
- full_name
- date_signed
- text
- checkbox
- email
- data
description: "Le contenu du champ. Le signataire applique sa `signature` et ses `initials` adoptées, saisit du texte dans un champ `text`, coche une case `checkbox` et saisit une adresse e-mail dans un champ `email` lorsque la session ne comporte aucun e-mail vérifié. Didit renseigne `full_name` (le nom vérifié), `date_signed` (la date de signature, dans le fuseau horaire du signataire), `data` (issu de `prefill`) ainsi qu'un `email` vérifié, et les affiche en lecture seule. Il n'existe pas de type sélecteur de date\_: utilisez `text`."
role:
type: string
enum:
- verified_person
- legal_representative
- key_people
description: >-
Qui remplit le champ, avec les valeurs `signature_signer`. Une étape
ne remplit et n'estampille que les champs de son propre signataire.
Vaut par défaut le signataire de l'étape.
page:
type: integer
minimum: 1
description: >-
Numéro de page, de 1 au nombre total de pages du document. Pour un
document Word, page du PDF converti.
x:
type: number
minimum: 0
maximum: 1
description: Bord gauche, sous forme de fraction de la largeur de la page.
'y':
type: number
minimum: 0
maximum: 1
description: Bord supérieur, sous forme de fraction de la hauteur de la page.
width:
type: number
minimum: 0.02
maximum: 1
description: >-
Largeur, exprimée en fraction de la largeur de la page. Une
signature a une largeur d'au moins `0.12`.
height:
type: number
minimum: 0.012
maximum: 1
description: >-
Hauteur, sous forme de fraction de la hauteur de la page. Une
signature a une hauteur minimale de `0.035`.
anchor:
$ref: '#/components/schemas/SignatureFieldAnchor'
required:
type: boolean
description: >-
`signature` and `initials` are required unless you set `false`.
`full_name`, `date_signed` and `data` are always required. The
signer can't finish a document until its required fields have a
value, and a required checkbox must be ticked.
label:
type: string
minLength: 1
maxLength: 80
description: >-
Affiché au signataire et dans les résultats. Défini par défaut à
partir du type.
placeholder:
type: string
nullable: true
maxLength: 80
description: '`text` et `email` uniquement.'
validation:
$ref: '#/components/schemas/SignatureFieldValidation'
prefill:
type: string
nullable: true
description: >-
Provenance de la valeur : `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.` (une clé des `metadata` de la session) ou
`api.` (une clé de `sign.field_values`). Requis pour `data`.
`full_name` utilise toujours `identity.full_name` et `email` utilise
`contact.email`. Les valeurs des champs `data`, `full_name` et
`email` vérifié sont figées dès que le signataire commence à signer.
editable_when_prefilled:
type: boolean
default: false
description: >-
`text` et `email` uniquement : le signataire peut modifier une
valeur préremplie.
checked_by_default:
type: boolean
default: false
description: '`checkbox` uniquement : la case est initialement cochée.'
date_format:
type: string
enum:
- DD/MM/YYYY
- MM/DD/YYYY
- YYYY-MM-DD
- D MMMM YYYY
default: DD/MM/YYYY
description: '`date_signed` uniquement.'
SignatureFieldAnchor:
type: object
description: >-
Positionne un champ d'après un extrait de texte dans le document plutôt
que par des coordonnées. Didit ne supprime pas le texte du PDF,
écrivez-le donc de la même couleur que l'arrière-plan de la page. Si le
texte n'est pas trouvé, l'appel renvoie `400` avec
`field_anchor_not_found`. Voir [Positionner des champs par texte
d'ancrage](/fr/sessions-api/create-session#placer-les-champs-par-texte-d’ancrage).
required:
- text
properties:
text:
type: string
minLength: 1
maxLength: 64
description: >-
Texte recherché dans le document. Pour un fichier Word, dans le PDF
converti.
occurrence:
type: string
enum:
- first
- all
default: first
description: >-
`all` place un champ par correspondance ; les clés suivant la
première reçoivent `_2`, `_3` et ainsi de suite.
offset_x:
type: number
description: >-
Ajouté au bord gauche du texte, sous forme de fraction de la largeur
de la page.
offset_y:
type: number
description: >-
Ajouté au bord supérieur du texte, sous forme de fraction de la
hauteur de la page.
width:
type: number
minimum: 0.02
maximum: 1
description: Largeur du champ, exprimée en fraction de la largeur de la page.
height:
type: number
minimum: 0.012
maximum: 1
description: Hauteur du champ, sous forme de fraction de la hauteur de la page.
SignatureFieldValidation:
type: object
nullable: true
description: >-
Règles applicables à la valeur d'un champ `text`. La prévisualisation
dans la console, le flux de signature et l'API appliquent les mêmes
règles.
properties:
kind:
type: string
enum:
- any
- letters
- number
- email
- pattern
description: >-
`letters` : lettres dans tout système d'écriture, espaces, traits
d'union et apostrophes. `number` : chiffres avec un séparateur
décimal facultatif. `pattern` : la valeur doit correspondre à
`pattern`.
min_length:
type: integer
minimum: 0
maximum: 500
description: De `0` jusqu'à `max_length`.
max_length:
type: integer
minimum: 1
maximum: 500
default: 120
pattern:
type: string
nullable: true
minLength: 1
maxLength: 200
description: >-
Requis avec `kind: "pattern"`. Une expression régulière à laquelle
la valeur entière doit correspondre. Les assertions avant/arrière
(lookarounds) et les références arrière ne sont pas prises en
charge.
message:
type: string
nullable: true
maxLength: 120
description: Affiché au signataire à la place de l'erreur par défaut.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
La clé API de votre application, issue de Développeurs -> Clés API dans
la Business Console. La clé principale dispose d'un accès complet. Une
clé nommée peut être restreinte : aucun, lecture ou écriture par
ressource, limitée à certains workflows ou aux sessions approuvées, à
une liste d'adresses IP et à une date d'expiration. 401 signifie que la
clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a
été envoyée, que la clé n'a pas accès à cette ressource ou action, ou
que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur
une route de session signifie que la session est hors des workflows ou
des statuts de la clé. Une clé sans accès aux médias reçoit les URL
d'images, de vidéos et de PDF à null, et une clé sans accès en écriture
aux sessions reçoit les liens et tokens de session à null. Voir
https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.