> ## 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.
# Create Session API: запуск KYC и KYB верификации в Didit
> POST /v3/session/ запускает сессию верификации Didit: единый KYC и KYB, оплата за использование, инференс до 2 с, $10 кредитов в месяц.
Промпт для создания сессии
Скопировать промпт в буфер обмена
\
\`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.`
\
Вставьте в
## Поддержка KYC и KYBОдин эндпоинт создаёт и сессии Проверки пользователей, и сессии Верификации бизнеса. **Тип сценария** определяет, какая именно сессия создаётся:- Передайте `workflow_id` **сценария KYC**: создаётся сессия Проверки пользователей (KYC). Ответ содержит `session_kind: "user"`.
- Передайте `workflow_id` **сценария KYB**: создаётся сессия Верификации бизнеса (KYB). Ответ содержит `session_kind: "business"`.Сценарии настраиваются в консоли: *Workflows → Create workflow*. Сценарий создаётся либо как KYC, либо как KYB, и тип нельзя изменить после создания.## Примеры> [tab] Проверка пользователей (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"
> }'
> ```
>
> **Ответ (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] Верификация бизнеса (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"
> }'
> ```
>
> **Ответ (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"
> }
> ```## Документы для электронной подписиЕсли в сценарии есть шаг [Электронная подпись](https://docs.didit.me/ru/core-technology/electronic-signature/overview.md), который берёт документы из сессии (`signature_documents_source` имеет значение `session` или `both`), передайте их в `sign.documents`. Каждый документ представляет собой файл в base64, поэтому Didit не нужно загружать его по 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" }
}
}
```| Поле | Правила |
| - | - |
| `title` | Показывается подписанту. От 1 до 255 символов. По умолчанию равно `file_name`. |
| `file_name` | Обязательно. Оканчивается на `.pdf` или `.docx`. От 1 до 255 символов. |
| `content_base64` | Обязательно. PDF может быть размером до 20 МБ и содержать до 100 страниц, без пароля, скриптов и вложенных файлов. Файл Word может быть размером до 20 МБ; он конвертируется в PDF во время выполнения запроса, не дольше 25 секунд. Затем PDF подчиняется тем же ограничениям. До 5 файлов Word на сессию. |
| `fields` | Необязательно. До 200 [полей](https://docs.didit.me/ru/core-technology/electronic-signature/overview.md#поля-на-документе), которые размещаются в документе, в формате объекта поля без `id`. Каждое поле требует `key` и `type`, а также либо позицию (`page`, `x`, `y`, `width` и `height`), либо [`anchor`](#размещение-полей-по-тексту-якорю). `role` по умолчанию равен подписанту шага, а `required` и `label` берутся из типа. Didit задаёт `position` по месту, где находится поле. Страницы и позиции указываются для PDF или, для файла Word, для сконвертированного PDF. |Без `fields` подписант читает документ и соглашается с ним.### Размещение полей по тексту-якорюВместо позиции поле может содержать `anchor`: фрагмент текста в документе, который отмечает место поля. Якоря подходят для документов, которые вы формируете для каждой сессии, например из шаблона Word. Для документов сценария размещайте поля в консоли.| Свойство `anchor` | Правила |
| - | - |
| `text` | От 1 до 64 символов, ищется в тексте документа. Для файла Word: в сконвертированном PDF. |
| `occurrence` | `first` (по умолчанию) размещает одно поле у первого совпадения. `all` размещает одно поле у каждого совпадения, а ключам после первого добавляются `_2`, `_3` и так далее. |
| `offset_x`, `offset_y` | Доли страницы. Левый верхний угол поля определяется как левый верхний угол текста якоря, сдвинутый на эти смещения. |
| `width`, `height` | Размер поля в долях страницы. |Если текста нет в документе, вызов возвращает `400` с `field_anchor_not_found` и ключом поля. Didit не удаляет текст якоря из PDF, поэтому пишите его тем же цветом, что и фон страницы.### Значения полей`sign.field_values` задаёт значение каждого поля, у которого `prefill` равен `api.`, как для документов сценария, так и для документов сессии. Это объект, ключами которого являются имена ``. Значения представляют собой строки длиной от 1 до 500 символов для полей `text` и `data` и логические значения для `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" }
}
}
```| Ошибка (`400`) | Когда возникает |
| - | - |
| `field_value_unknown` | Ключ, который не используется ни одним полем. |
| `field_value_missing` | Обязательное поле, у которого `api.` не имеет значения. |
| `field_value_invalid` | Значение, не прошедшее [валидацию](https://docs.didit.me/ru/core-technology/electronic-signature/overview.md#валидация) своего поля. |### Ошибки и повторные вызовыСессия принимает до 20 документов и 50 МБ в сумме. Вызов возвращает `400` с ошибкой `sign`, если:- В сценарии нет шага электронной подписи.
- Вы передали `sign.documents`, а шаг принимает только документы сценария.
- Шаг принимает только документы сессии, а вы их не передали, или в шаге нет документов сценария, а вы их тоже не передали.
- Документ слишком большой, не является корректным base64 или не относится к поддерживаемому формату.
- Файл Word отклонён с ошибкой `signature_document_not_supported` или не может быть сконвертирован и возвращает `signature_document_conversion_failed`; в обоих случаях указывается `reason` из раздела [Поддерживаемые файлы](https://docs.didit.me/ru/core-technology/electronic-signature/overview.md#поддерживаемые-файлы).
- Поле некорректно, его якорь не найден (`field_anchor_not_found`) или [значение поля](#значения-полей) отклонено.Повторный вызов создания для того же `workflow_id` и `vendor_data` возвращает сессию, ожидающую обработки. Если этот вызов содержит `sign`, его документы, поля и значения полей должны полностью совпадать с первым вызовом (тот же порядок, названия, имена файлов, содержимое, поля и значения). Любое отличие возвращает `400` с `{"sign": "signature_document_changed"}`: используйте другой `vendor_data` или дождитесь завершения сессии, ожидающей обработки.## Тестирование со сценариями песочницыВ приложении в режиме песочницы передайте `sandbox_scenario`, чтобы заранее задать детерминированный результат (одобрение, конкретный отказ или сценарий «На проверке») без обращения к реальным провайдерам и без списания с баланса:```json theme={null}
{
"workflow_id": "YOUR_SANDBOX_WORKFLOW_ID",
"sandbox_scenario": "decline_document_expired"
}
````sandbox_scenario` отклоняется с ошибкой `400` в продакшн-приложениях. Если на момент создания результат ещё неизвестен, активируйте (или повторно активируйте) его позже через `POST /v3/session/{session_id}/sandbox/arm/`, пока сессия находится в статусе `Not Started`: выбор сценария на этапе до начала в размещённом потоке использует тот же эндпоинт. Полный каталог сценариев, реестр магических значений и формат запроса и ответа эндпоинта arm см. в разделе [Песочница и тестовые данные](https://docs.didit.me/ru/integration/sandbox-testing.md).## `vendor_data` привязывает сессию к сущности- Для сценариев KYC привязывает к [сущности пользователя](https://docs.didit.me/ru/entities/users/overview.md). Если пользователя не существует, он создаётся автоматически.
- Для сценариев KYB привязывает к [сущности компании](https://docs.didit.me/ru/entities/businesses/overview.md). Если компания новая, она создаётся автоматически.Подробнее см. в разделе [привязка данных вендора](https://docs.didit.me/ru/entities/vendor-data-linking.md).## Биометрическое согласие в Иллинойсе, Техасе и КолорадоХостед-флоу и нативный SDK версии 4.10.0 или новее могут показать явный шаг биометрического согласия перед первым захватом лица. Это зависит от режима согласия приложения и от того, где находится пользователь. На это решение влияют два необязательных поля:- `user_state`: место проживания пользователя, если вы его знаете (`US-IL`, `IL` или `Illinois`). В режиме Auto штат из списка охваченных заставляет флоу запросить согласие.
- `biometric_consent`: объект с полями `given_at` и `text_version` для согласия, которое вы уже получили. Флоу повторно не запрашивает согласие.Нативные SDK ниже 4.10.0 не могут показать этот шаг: их сессии работают как прежде, а решение указывает, что согласие не получено. См. [Биометрическое согласие](https://docs.didit.me/ru/getting-started/biometric-consent.md).## Важно: уведомление пользователя и получение согласия по-прежнему происходят в вашем продукте`Create Session` создаёт URL верификации и токен сессии. Сам по себе он **не** подтверждает, что вы предоставили пользователю необходимые уведомления или получили согласие, требуемое для вашего конкретного сценария использования.Если вы запускаете сессию Didit из собственного приложения, веб-сайта, обёртки SDK или White label-флоу, вам следует проработать юридическую часть в собственном UX до того, как пользователь начнёт захват.## Рекомендуемый чек-лист перед верификацией1. Сообщите пользователю, что верификацию запрашивает **ваша компания**, а флоу обеспечивает провайдер верификации / обработчик данных **Didit**.
2. Добавьте ссылку на **вашу политику конфиденциальности** и любые юридические условия со стороны контролера данных, которые применяются к этому пути пользователя.
3. Добавьте ссылки на [Политику конфиденциальности верификации](https://didit.me/terms/verification-privacy-notice) и [Пользовательское соглашение для верификации личности](https://didit.me/terms/identity-verification) от Didit.
4. Если ваш флоу включает захват документа, селфи, проверку живости или биометрию, соберите **явное утвердительное согласие** везде, где этого требует применимое законодательство или ваша правовая позиция.
5. Если вы используете собственный UI, собственный домен или путь только через API, предоставьте эту информацию в вашем продукте до того, как отправить пользователя во флоу Didit.
6. Если ваша юридическая служба требует журнал аудита, храните собственную запись текста уведомления и согласия, отметку времени и связанные метаданные.> [!WARNING]
>
> Законодательные требования различаются в зависимости от юрисдикции. Брендинг White label не отменяет роль Didit в процессе верификации. Если вы работаете в юрисдикциях с правилами, специфичными для биометрии, проверьте реализацию с юристами до запуска.
## OpenAPI
````yaml ru/openapi-25.json POST /v3/session/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: >-
API верификации личности. Аутентификация выполняется с помощью заголовка
x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/session/:
post:
tags:
- Sessions
summary: Создать сессию верификации
description: >-
Создать сессию Проверки пользователей (KYC) или Верификации бизнеса
(KYB) и получить `url` размещённой страницы верификации и
`session_token`, чтобы перенаправить на неё конечного пользователя или
встроить её. Параметр `workflow_id` определяет, какие шаги верификации
выполняются и является ли сессия KYC или KYB.
Вызывайте этот endpoint из бэкенда (никогда из браузера — API-ключ
является секретом) каждый раз, когда требуется проверить пользователя
или компанию: при регистрации, перед выполнением конфиденциального
действия или при необходимости повторной верификации. Предварительные
требования: опубликованный сценарий (созданный в Console на странице
[Workflows](https://docs.didit.me/ru/console/workflows)) и API-ключ
приложения с доступными кредитами. Для приложений в песочнице проверка
кредитов не выполняется.
**Идемпотентность:** если указан `vendor_data` и незавершённая сессия
(`Not Started`, `In Progress`, `Resubmitted` или `Awaiting User`) с
таким же `vendor_data` уже существует в **текущей последней
опубликованной версии** сценария (и для этой сессии уже создан URL
размещённой страницы верификации), возвращается существующая сессия
(по-прежнему с кодом `201`) вместо создания дубликата — при этом её
параметры `callback` и `metadata` обновляются до вновь переданных
значений. Незавершённая сессия, созданная в более старой версии сценария
(которая с тех пор была переопубликована), **не** используется повторно;
вместо этого создаётся новая сессия, привязанная к последней
опубликованной версии. Сессии в статусах `Approved`, `Declined`, `In
Review`, `Expired`, `Abandoned` или `Kyc Expired` никогда не
используются повторно.
**Побочные эффекты:** создаётся и сохраняется URL размещённой страницы
верификации; если `contact_details.send_notification_emails` имеет
значение `true` и указан адрес электронной почты, отправляется письмо с
приглашением на верификацию. Срок действия сессии истекает по истечении
времени жизни сессии, настроенного в сценарии. Для сценариев KYB
параметры `contact_details.phone` и `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: >-
Постоянный идентификатор сценария, который определяет, какие
шаги верификации будут выполнены в сессии. Сценарии
создаются и управляются на странице
[Workflows](/ru/console/workflows) в консоли. Значение
`workflow_id` также неявно определяет, является ли сессия
KYC или KYB.
example: 11111111-2222-3333-4444-555555555555
x-readme-id: '0.0'
vendor_data:
type: string
description: >-
Уникальный идентификатор верифицируемого пользователя,
например UUID, адрес электронной почты или внутренний ID
пользователя. Это поле используется для: (1) **Группировки
пользователей** — сессии с одинаковым vendor_data
связываются с одним профилем пользователя на вкладке Users.
(2) **Обнаружения дубликатов между сессиями** — при проверке
на дублирование лиц, документов, номеров телефонов, адресов
электронной почты, IP-адресов или цифровых отпечатков
устройств сессии с одинаковым vendor_data считаются одним и
тем же пользователем и исключаются из совпадений. Без
vendor_data каждая сессия рассматривается как отдельный
пользователь, и отображаются все потенциальные дубликаты. Мы
настоятельно рекомендуем всегда указывать vendor_data, чтобы
снизить уровень шума при обнаружении дубликатов.
example: user-123
x-readme-id: '0.1'
multi_account_segment:
type: string
maxLength: 64
description: >-
Необязательная область обнаружения дубликатов внутри вашей
организации. Проверки на дубликаты лиц сравнивают эту сессию
только с другими сессиями с тем же сегментом, поэтому
раздельные базы аккаунтов (личные и корпоративные аккаунты
или отдельные базы для B2B-субклиентов) не помечают
человека, законно владеющего по одному аккаунту в каждой из
них. Опустите это поле, чтобы использовать единую область по
умолчанию, применяемую сегодня ко всем сессиям.
Сопоставление со списком блокировки и белым списком
игнорирует это поле.
example: business-accounts
callback:
type: string
description: >-
URL для перенаправления пользователя после завершения
верификации. Didit автоматически добавляет
`verificationSessionId` и `status` (Approved, Declined, In
Review) в качестве query-параметров. Пользовательские схемы
URL (например, `myapp://`) поддерживаются для мобильных
обратных вызовов. Если параметр опущен, используется
`callback_url` сценария по умолчанию. Если у приложения
настроены разрешённые домены (`allowed_domains` в `PATCH
/v3/webhook/`), обратный вызов `http` или `https` должен
относиться к одному из этих источников (та же схема, хост и
порт), иначе запрос вернёт ошибку 400 по полю `callback`:
`callback must be on one of the application's allowed
domains: https://app.example.com`. Пользовательские схемы
URL принимаются всегда.
example: https://example.com/verification/callback
x-readme-id: '0.2'
callback_method:
type: string
description: >-
Определяет, какое устройство должно обработать
перенаправление на указанный URL обратного вызова.
Используйте `initiator`, чтобы перенаправить только
устройство, начавшее процесс, `completer` для устройства,
завершившего его, или `both`, чтобы разрешить запуск
обратного вызова любому из устройств. Если вы заметите, что
обратный вызов срабатывает нестабильно, мы рекомендуем
установить это значение в `both`.
enum:
- initiator
- completer
- both
default: initiator
example: both
x-readme-id: '0.3'
metadata:
description: >-
Произвольный JSON, сохранённый с сессией и возвращаемый в
ответе и событиях webhook. Допускается любое JSON-значение
(объект, строка, число, массив), но рекомендуется
JSON-объект с парами ключ/значение. Не отображается
конечному пользователю. Используйте его для передачи
собственных корреляционных ID, вариантов A/B-тестирования
или контекста компании.
example:
user_type: premium
account_id: ABC123
x-readme-id: '0.4'
tags:
type: array
items:
type: string
maxLength: 50
maxItems: 10
description: >-
Теги, добавляемые к сессии при ее создании, по имени. До 10,
каждый длиной до 50 символов. Имена нечувствительны к
регистру и сохраняются в верхнем регистре. Имя, которого еще
нет в приложении, создается как новый тег. Теги отображаются
на сессии в консоли, где по ним можно фильтровать.
example:
- VIP
- ONBOARDING Q4
language:
type: string
description: >-
Код языка (ISO 639-1) для интерфейса процесса верификации.
Определяет язык, отображаемый конечному пользователю во
время верификации. Если не указан, язык браузера
определяется автоматически. Ознакомиться со всеми
поддерживаемыми языками можно
[здесь](/ru/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: >-
Контактная информация пользователя, которая может
использоваться для уведомлений, автозаполнения форм
верификации и проверки телефона. Включает адрес электронной
почты, предпочтительный язык для сообщений и номер телефона.
example:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
properties:
email:
type: string
format: email
description: >-
Адрес электронной почты пользователя (например,
"john.doe@example.com"), который будет использоваться на
шаге [Проверка электронной
почты](/ru/core-technology/email-verification/overview).
Если не указан, пользователь должен ввести его в
процессе верификации.
example: john.doe@example.com
x-readme-id: '1.0'
send_notification_emails:
type: boolean
default: false
description: >-
Если параметр равен true и указан адрес электронной
почты, Didit асинхронно отправляет начальное письмо
«Подтвердите вашу личность» при создании сессии Проверки
пользователей (KYC) или Верификации бизнеса (KYB). Didit
также отправляет уведомления о статусе верификации для
сессий, требующих ручной проверки, на указанный адрес
электронной почты (например, при смене статуса с «На
проверке» на «Одобрена» или «Отклонена»). Это помогает
пользователям вернуться в ваше приложение после
завершения верификации. Если для сессии активирован
White label, отправленное письмо также будет
использовать White label.
example: true
x-readme-id: '1.1'
email_lang:
type: string
description: >-
Код языка (ISO 639-1) для email-уведомлений. Определяет
язык всех сообщений по электронной почте (например,
«en», «es», «fr»). Сохранённого значения по умолчанию
нет — если параметр опущен, письмо с приглашением на
верификацию при отправке автоматически переключается на
английский (`en`). Значения перечисления ниже являются
снимком; актуальным источником достоверных данных для
поддерживаемых значений служит документация по
[поддерживаемым
языкам](/ru/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: '1.2'
phone:
type: string
description: >-
Номер телефона в формате E.164 (например,
«+14155552671»), который будет использоваться на шаге
[Проверка
телефона](/ru/core-technology/phone-verification/overview).
Если он не указан, пользователь должен будет
предоставить его в процессе верификации. Игнорируется
для сценариев Верификации бизнеса (KYB). **Важно:** этот
номер телефона применяется только в том случае, если он
является корректным номером в формате E.164. Если
указанный номер некорректен или не может быть распознан,
он игнорируется, и пользователь сможет ввести любой
корректный номер телефона на шаге проверки телефона.
example: '+14155552671'
x-readme-id: '1.3'
x-readme-id: '0.4'
expected_details:
type: object
description: >-
Ожидаемые данные пользователя, используемые для перекрёстной
проверки с данными, извлечёнными из документа,
удостоверяющего личность пользователя, подтверждения адреса
и других шагов верификации. Несоответствия отображаются как
предупреждения в решении; некоторые поля (например,
`id_country`, `expected_document_types`) также изменяют
сценарий для пользователя. Для сценариев верификации бизнеса
(KYB) используются только поля компании (`company_name`,
`registry_country`, `registration_number`) — они
предварительно заполняют поиск в реестре компаний для
пользователя, а все поля физических лиц игнорируются.
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: >-
Имя пользователя. Например, `John`. При сопоставлении
используется нечёткое сравнение; вы можете настроить
строгость, задав порог оценки совпадения имён в Console
для сценариев ID Document и Подтверждение адреса.
example: John
x-readme-id: '1.0'
last_name:
type: string
description: >-
Фамилия пользователя. Например, `Doe`. При сопоставлении
используется нечёткое сравнение; вы можете настроить
строгость, задав порог оценки совпадения имён в Console
для сценариев ID Document и «Подтверждение адреса».
example: Doe
x-readme-id: '1.1'
date_of_birth:
type: string
format: date
description: >-
Дата рождения пользователя в формате YYYY-MM-DD.
Например, `1990-05-15`.
example: '1990-05-15'
x-readme-id: '1.2'
gender:
type: string
nullable: true
enum:
- M
- F
default: null
description: Пол пользователя. Должен быть 'M', 'F' или null.
example: M
x-readme-id: '1.3'
nationality:
type: string
description: >-
Код страны по стандарту ISO 3166-1 alpha-3,
представляющий страну происхождения заявителя. Например,
`USA`. См. [полный список поддерживаемых кодов
стран](https://docs.didit.me/ru/core-technology/id-verification/supported-documents-id-verification#поддерживаемые-документы-по-странам).
example: USA
x-readme-id: '1.4'
country:
type: string
description: >-
Код страны по стандарту ISO 3166-1 alpha-3, используемый
в качестве резервного значения для проверок
несоответствия страны как в Верификации личности, так и
в Подтверждении адреса. Обязателен, если передан
параметр `address` и не заданы ни `id_country`, ни
`poa_country`.
example: USA
x-readme-id: 1.4.1
id_country:
type: string
description: >-
Код страны по стандарту ISO 3166-1 alpha-3,
представляющий ожидаемую страну документа,
удостоверяющего личность заявителя, которая может
отличаться от гражданства. Например, `GBR`. Имеет
приоритет над `country` при проверках несоответствия
страны в верификации личности. См. [полный список
поддерживаемых кодов
стран](https://docs.didit.me/ru/core-technology/id-verification/supported-documents-id-verification#поддерживаемые-документы-по-странам).
example: GBR
x-readme-id: '1.5'
poa_country:
type: string
description: >-
Код страны по стандарту ISO 3166-1 alpha-3,
представляющий ожидаемую страну документа для
подтверждения адреса (Proof of Address). Например,
`USA`. Имеет приоритет над `country` при проверках
несоответствия страны в POA. См. [полный список
поддерживаемых кодов
стран](https://docs.didit.me/ru/core-technology/id-verification/supported-documents-id-verification#поддерживаемые-документы-по-странам).
example: USA
x-readme-id: 1.5.1
address:
type: string
description: >-
Адрес в удобочитаемом для человека формате, содержащий
как можно больше информации. Например, `123 Main St, San
Francisco, CA 94105, USA`. При передаче вы также должны
передать `country` или `poa_country`, иначе запрос
завершится с ошибкой `400`.
example: 123 Main St, San Francisco, CA 94105, USA
x-readme-id: '1.6'
identification_number:
type: string
description: >-
Номер документа, личный номер или налоговый номер
пользователя. Например, `123456789`.
example: '123456789'
x-readme-id: '1.7'
ip_address:
type: string
description: >-
Ожидаемый IP-адрес для сессии в формате IPv4 или IPv6.
Если фактический IP-адрес отличается от этого значения,
в журнал будет записано предупреждение. Например,
`192.168.1.100` или `2001:db8::1`.
example: 192.168.1.100
x-readme-id: '1.8'
expected_document_types:
type: array
description: >-
Ограничивает типы документов, которые пользователь может
предоставить во время шага верификации личности (OCR).
Если параметр задан, на экране выбора документов
отображаются только запрошенные типы, а возвращаемый
список `documents_allowed` фильтруется соответствующим
образом. Значения нечувствительны к регистру и
дедуплицируются; неизвестные значения отклоняются с
ошибкой `400`. Допустимые коды: `P` (паспорт), `ID`
(национальное удостоверение личности), `DL`
(водительское удостоверение), `RP` (вид на жительство),
`HIC` (карта медицинского страхования), `TC` (налоговая
карта), `SSC` (карта социального страхования).
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: >-
Ожидаемое юридическое наименование верифицируемой
компании. Например, `Tesco PLC`. Автоматически заполняет
поле названия компании при поиске в реестре в сценариях
верификации бизнеса (KYB); если также указан
`registration_number`, поиск в реестре объединяет оба
идентификатора. Игнорируется для сценариев KYC.
example: Tesco PLC
x-readme-id: '1.10'
registry_country:
type: string
maxLength: 10
description: >-
Двухбуквенный код страны ISO 3166-1 alpha-2, в реестре
компаний которой зарегистрирован бизнес. Например, `GB`.
Если реестры компаний действуют на уровне штата или
провинции, добавьте код подразделения ISO 3166-2 в
формате `XX-YY`: `US-CA` выбирает реестр Калифорнии. Тот
же формат, что и у `country_code` в [KYB Registry Search
API](https://docs.didit.me/ru/standalone-apis/kyb-registry-search).
Предварительно выбирает страну реестра в сценариях
верификации бизнеса (KYB); игнорируется в сценариях KYC.
example: US-CA
x-readme-id: '1.11'
registration_number:
type: string
maxLength: 100
description: >-
Ожидаемый регистрационный номер компании в реестре
компаний. Например, `00445790`. Автоматически заполняет
поле регистрационного номера при поиске в реестре в
сценариях верификации бизнеса (KYB); если также указан
`company_name`, поиск в реестре объединяет оба
идентификатора. Игнорируется для сценариев KYC.
example: '00445790'
x-readme-id: '1.12'
x-readme-id: '0.5'
portrait_image:
type: string
format: byte
description: >-
Портретное изображение лица конечного пользователя в
кодировке Base64 (не более 2 МБ; JPEG, PNG, WebP или TIFF).
Используется в качестве эталонного изображения для
сопоставления со снимком проверки живости, если используется
сценарий `Biometric Authentication` с включённым Сравнением
лиц или любой граф-сценарий, где Сравнение лиц выполняется
до Верификации личности (OCR). Необязательно, если у
пользователя из `vendor_data` уже есть сохранённое
изображение лица: Didit повторно использует его
автоматически, выбирая в порядке приоритета: лицо из
одобренной проверки живости, фото с чипа биометрического
паспорта, портрет из документа, удостоверяющего личность,
лицо профиля, добавленное вручную (повторно используются
только лица из одобренных сессий или лица, добавленные вами
самостоятельно). При передаче `portrait_image` всегда имеет
приоритет над сохранённым лицом. Если параметр опущен и
сохранённое лицо отсутствует (или `vendor_data` не
отправлен), создание сессии завершается ошибкой `400`.
Игнорируется для других типов сценариев.
example: >-
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=
x-readme-id: '0.6'
sandbox_scenario:
type: string
description: >-
Слаг сценария только для песочницы. Принимается только в том
случае, если API-ключ принадлежит приложению в режиме
песочницы; для продакшн-приложений отклоняется. Если задан,
процесс создания разворачивает встроенные магические
значения сценария во входные поля сессии (contact_details,
expected_details), чтобы мок-провайдеры воспроизводили
результат сценария через реальный конвейер сценария
верификации. Каталог сценариев см. в GET
/v1/sandbox/scenarios/ или в разделе [Песочница и тестовые
данные](/ru/integration/sandbox-testing). Вы также можете
активировать (или повторно активировать) сценарий после
создания с помощью POST
/v3/session/{sessionId}/sandbox/arm/, пока сессия всё ещё
находится в статусе `Not Started`. Для проверок без
документов используйте `lookup_partial_match`,
`lookup_no_match` или `lookup_provider_error`, чтобы
протестировать настроенный лимит попыток и резервный
вариант. Для кошельков идентификации используйте
`wallet_cancelled`, `wallet_timeout` или
`wallet_provider_error`; значение `approve` имитирует
верифицированный кошелёк. Все кошельки из каталога можно
тестировать в песочнице, включая схемы, недоступные в
продакшн-приложениях. Плата за имитированные попытки не
взимается.
example: decline_document_expired
sign:
type: object
description: >-
Входные данные электронной подписи для этой сессии.
`documents` содержит документы для подписания для сценария,
шаг электронной подписи которого берёт документы из сессии
(`signature_documents_source` со значением `session` или
`both`): до 20 документов и 50 MB суммарно. `field_values`
заполняет поля, у которых `prefill` имеет значение
`api.`, как в документах сценария, так и в документах
сессии. Повторное создание сессии с теми же `workflow_id` и
`vendor_data` возвращает ожидающую сессию; если этот вызов
передаёт `sign`, его документы, поля и значения должны быть
идентичны исходным, а любые отличия возвращают `400` с
`{"sign": "signature_document_changed"}`. См. [Документы
электронной
подписи](/ru/sessions-api/create-session#документы-для-электронной-подписи).
properties:
documents:
type: array
minItems: 1
maxItems: 20
items:
$ref: '#/components/schemas/SessionSignDocument'
field_values:
type: object
description: >-
Значения с ключами по `` каждого источника
автозаполнения `api.`: строки от 1 до 500 символов
для полей `text` и `data`, булевы значения для
`checkbox`. `400` с `field_value_unknown` для ключа,
который не используется ни одним полем,
`field_value_missing` для обязательного поля без
значения и `field_value_invalid` для значения, не
прошедшего валидацию своего поля.
additionalProperties:
oneOf:
- type: string
minLength: 1
maxLength: 500
- type: boolean
example:
credit_limit: 3,000 EUR
user_state:
type: string
maxLength: 16
description: >-
Место проживания лица, если оно известно: код подразделения
ISO 3166-2 (`US-IL`, `ES-M`) либо код или название штата США
(`IL`, `Illinois`). Если законодательство штата требует
явного согласия на обработку биометрии (Иллинойс, Техас,
Колорадо), сценарий верификации запрашивает его перед
захватом лица с триггером `declared_state`. Нераспознанное
значение возвращает `400`. См. раздел [Согласие на обработку
биометрии](/ru/getting-started/biometric-consent).
example: US-IL
biometric_consent:
type: object
description: >-
Явное биометрическое согласие, которое вы уже получили от
человека. Оно удовлетворяет требованию, поэтому в процессе
верификации повторный запрос не выполняется, а в решении оно
фиксируется со статусом `status: "given"` и триггером
`customer_collected`. Ответ, который пользователь уже дал в
процессе, никогда не перезаписывается. См. [Биометрическое
согласие](/ru/getting-started/biometric-consent).
required:
- given_at
- text_version
properties:
given_at:
type: string
format: date-time
description: >-
Время предоставления человеком явного биометрического
согласия (ISO 8601). Не может быть в будущем.
text_version:
type: string
maxLength: 64
description: >-
Идентификатор версии текста согласия, принятого
пользователем, в вашей системе учёта.
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 успешного сценария для сессии проверки
пользователей (KYC)
description: >-
Реалистичный вызов создания, использующий все часто
используемые поля: выбор сценария, привязку к вендору,
маршрутизацию обратных вызовов, метаданные, локаль,
предварительное заполнение контактов и ожидаемые данные
пользователя. Скопируйте и вставьте это напрямую в пример cURL
выше.
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 успешного сценария (happy-path) для сессии Верификации
бизнеса (KYB)
description: >-
Та же структура, что и у вызова KYC — именно `workflow_id`
определяет сессию как KYB. Поле `vendor_data` обычно ссылается
на компанию в вашей системе, а `contact_details.email`
указывает на законного представителя, который будет проходить
процесс. В `expected_details` передаются поля компании
(`company_name`, `registry_country`, `registration_number`),
которые предварительно заполняют поиск в реестре компаний;
поля уровня физического лица и `contact_details.phone` для
сценариев 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: >-
Сессия создана (или возвращена, если незавершённая сессия с теми же
`vendor_data` уже существует в последней опубликованной версии
сценария). Ответ содержит сериализованную сессию, включая `url`
размещённой страницы верификации для перенаправления пользователя.
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: >-
Уникальный идентификатор сессии верификации. Используйте
этот id при вызове `GET
/v3/session/{sessionId}/decision/`.
example: 11111111-2222-3333-4444-555555555555
session_number:
type: integer
description: >-
Порядковый, удобный для восприятия номер, присвоенный
сессии внутри вашего приложения. Полезен для службы
поддержки и панелей управления.
example: 43762
session_token:
type: string
description: >-
12-символьный URL-безопасный token, который авторизует
конечного пользователя для доступа к размещённому сценарию
верификации по адресу `url`. Действителен до тех пор, пока
сессия не истекла. Относитесь к нему как к секрету: любой,
у кого он есть, может открыть сценарий верификации для
этой сессии.
example: 3FaJ9wLqX2Mz
url:
type: string
format: uri
description: >-
Размещённый URL верификации, на который перенаправляется
конечный пользователь. URL содержит `session_token` и,
если настроено, использует ваш White label домен. Если
запрос содержит `language`, URL включает языковой сегмент
пути —
`https://verify.didit.me/{language}/session/{session_token}`
(например, `/es/session/...`); без `language` этот сегмент
опускается.
example: https://verify.didit.me/session/3FaJ9wLqX2Mz
vendor_data:
type: string
nullable: true
description: >-
Идентификатор, переданный вами в запросе для привязки
сессии к пользователю или компании в вашей собственной
системе. Возвращается без изменений. Null, если не указан.
example: user-123
metadata:
description: >-
Произвольный JSON payload, сохранённый с сессией при её
создании. Возвращается в неизменном виде — любое
переданное JSON-значение (объект, строка, число, массив)
возвращается как есть, хотя рекомендуется передавать
JSON-объект. Не отображается конечному пользователю.
Всегда присутствует в ответах; `null`, если не было
передано при создании.
example:
user_type: premium
account_id: ABC123
tags:
type: array
items:
type: string
description: Теги сессии, по именам.
example:
- VIP
- ONBOARDING Q4
status:
type: string
enum:
- Not Started
- In Progress
- Approved
- Declined
- In Review
- Expired
- Abandoned
- Kyc Expired
- Resubmitted
- Awaiting User
description: >-
Текущий статус сессии. Для только что созданных сессий
возвращается `Not Started`. Если для тех же данных
`vendor_data` в последней опубликованной версии сценария
уже существовала незавершённая сессия, возвращаемый статус
отражает состояние этой существующей сессии.
example: Not Started
callback:
type: string
format: uri
nullable: true
description: >-
Финальный URL перенаправления, на который направляется
пользователь после завершения сценария. Didit добавляет к
этому URL
`?verificationSessionId={session_id}&status={status}`. По
умолчанию используется настроенный URL обратного вызова
сценария, если он не передан в запросе; `null`, если ни
один из них не задан. Если в приложении настроены
разрешённые домены и данный URL является веб-URL вне их
списка (например, значение по умолчанию в сценарии,
заданное до изменения списка), размещённый сценарий не
перенаправляет пользователя на него.
example: https://example.com/verification/callback
workflow_id:
type: string
format: uuid
description: >-
Постоянный идентификатор сценария, в рамках которого
выполняется эта сессия. Всегда является постоянным
идентификатором группы сценария — даже если в запросе был
указан UUID конкретной версии сценария (для обратной
совместимости), ответ содержит постоянный `workflow_id`.
Используйте его для сопоставления сессии со сценарием,
настроенным вами в консоли.
example: 11111111-2222-3333-4444-555555555555
workflow_version:
type: integer
description: >-
Номер опубликованной версии сценария, к которой сессия
была привязана при создании. Didit сопоставляет
`workflow_id` с последней опубликованной версией сценария
на момент создания сессии, и сессия продолжает выполняться
на этой версии, даже если сценарий позже будет опубликован
повторно.
example: 3
examples:
KYC session:
summary: KYC-сессия создана
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: KYB-сессия создана
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: >-
Некорректный запрос — payload не прошёл валидацию (отсутствует или
неизвестен `workflow_id`, недопустимый `language`, `vendor_data` из
списка блокировки, некорректный `portrait_image`, `address` без
`country`/`poa_country`, недопустимый `sandbox_scenario`, документы
для подписания `sign`, поля или значения, отклонённые шагом сценария
«Электронная подпись», такие как `signature_document_not_supported`,
`signature_document_conversion_failed`, `field_anchor_not_found` или
`field_value_missing` и т. д.), либо у вашей организации
недостаточно кредитов для запуска сессии.
Тело ответа представляет собой объект, ключами которого являются
имена ошибочных полей (или `detail` для ошибок, не связанных с
конкретными полями). Значения представляют собой **массив строк**
для ошибок валидации входных данных (например, отсутствие
обязательного поля, недопустимый язык, слишком большой размер
портретного изображения) и **обычную строку** для ошибок,
обнаруженных при создании сессии (неизвестный `workflow_id`,
`vendor_data` из списка блокировки, отсутствие эталонного лица для
сценария со Сравнением лиц). Обрабатывайте обе структуры.
content:
application/json:
schema:
type: object
additionalProperties: true
properties:
detail:
type: string
description: >-
Понятное сообщение об ошибке для ошибок, не связанных с
конкретными полями (например, недостаточно кредитов). Для
сбоев на уровне полей в качестве ключа используется имя
поля со строковым значением или массивом строк.
example: >-
You don't have enough credits to perform this request.
Please top up at https://business.didit.me
examples:
Missing workflow_id:
summary: Обязательное поле не указано (формат массива строк)
value:
workflow_id:
- This field is required.
Invalid workflow_id:
summary: Неизвестный workflow_id (в виде обычной строки)
value:
workflow_id: Invalid workflow_id.
Insufficient credits:
summary: У организации закончились кредиты
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 находится в списке блокировки
value:
vendor_data: >-
This user or business has been blocked and cannot create
new verification sessions.
Portrait image too large:
summary: portrait_image не проходит проверку размера
value:
portrait_image:
- Image size exceeds 2MB.
No stored face for vendor_data:
summary: >-
Сценарий «Сравнение лиц» без portrait_image и без
сохраненного лица для пользователя 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: >-
Сценарий «Сравнение лиц» без portrait_image и без
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: >-
Ошибка аутентификации или авторизации. Неверный, отозванный или
истекший ключ возвращает `401`. Endpoint возвращает `403`, если
заголовок `x-api-key` отсутствует или если API-ключ действителен, но
у клиента нет разрешения на создание сессий в этом приложении
(например, API-ключ принадлежит другой организации). В таких случаях
тело ответа имеет вид `{"detail": "You do not have permission to
perform this action."}`. Убедитесь, что заголовок `x-api-key`
присутствует и относится к нужному приложению, при необходимости
запросите API-ключ приложения повторно через [Auth
API](/ru/auth-api/get-credentials) и повторите попытку.
**Удалённое приложение:** в течение нескольких минут после удаления
приложения запрос, выполненный с одним из его API-ключей, может
возвращать `{"detail": "This application was deleted.", "code":
"application_deleted"}`. Не повторяйте попытку: приложение и его
API-ключи больше не существуют. По истечении этих нескольких минут
ключ отклоняется, как и любой другой недействительный ключ.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: You do not have permission to perform this action.
code:
type: string
description: >-
Машиночитаемая причина, присутствует только при некоторых
ошибках. `application_deleted`: API-ключ принадлежит
приложению, которое было удалено.
example: application_deleted
required:
- detail
examples:
Missing or invalid API key:
summary: >-
Отсутствует заголовок `x-api-key` или передан
недействительный API-ключ
value:
detail: You do not have permission to perform this action.
No permission:
summary: Клиент не может создавать сессии
value:
detail: You do not have permission to perform this action.
Application deleted:
summary: API-ключ удалённого приложения
value:
detail: This application was deleted.
code: application_deleted
'429':
description: >-
Превышен лимит запросов — более 600 запросов на создание сессии за
60-секундное окно с одного и того же API-ключа / IP. Проверьте
заголовок `Retry-After` и сделайте паузу перед повторной попыткой.
**Примечание:** В исходном коде также определен
`FREE_SESSION_RATE_LIMIT`, равный 10 вызовов/минуту наряду с
`PAID_SESSION_RATE_LIMIT=600` (`sessions/serializers/session.py`),
но этот потолок бесплатного тарифа **не применяется к данному
endpoint V3** — middleware лимитирования запросов применяет
`SESSION_CREATE_RATE_LIMIT`, равный 600/мин, независимо от тарифа.
Лимит 600/мин является единственным, в который здесь можно
упереться.
headers:
Retry-After:
description: >-
Количество секунд, которое вызывающая сторона должна подождать
перед повторной попыткой запроса.
schema:
type: integer
minimum: 1
example: 42
X-RateLimit-Limit:
description: >-
Максимальное количество запросов, разрешённое в текущем
60-секундном окне для лимита, который был превышен (600 для
создания сессии). Отсутствует в варианте квоты песочницы.
schema:
type: integer
example: 600
X-RateLimit-Remaining:
description: >-
Количество запросов, всё ещё разрешённых в текущем окне для
превышенного лимита. Отсутствует в варианте с квотой песочницы.
schema:
type: integer
minimum: 0
example: 0
X-RateLimit-Reset:
description: >-
Количество секунд эпохи Unix по UTC, когда текущее окно лимита
запросов сбрасывается. Отсутствует в варианте квоты песочницы.
schema:
type: integer
minimum: 0
example: 1747497600
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
Понятное объяснение нарушения лимита запросов. Используйте
это сообщение, чтобы определить, какой из трёх лимитов был
исчерпан.
example: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
examples:
Session-create limit:
summary: Более 600 запросов на создание сессии в минуту
value:
detail: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
Sandbox session quota:
summary: >-
Приложение в песочнице превысило лимит в 500 сессий за 24
часа
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: >-
Название, отображаемое подписывающему лицу. По умолчанию
`file_name`.
file_name:
type: string
minLength: 1
maxLength: 255
description: Имя файла, оканчивающееся на `.pdf` или `.docx`.
content_base64:
type: string
format: byte
description: >-
Файл в кодировке base64. PDF-файл может иметь размер до 20 МБ и до
100 страниц, без пароля, скриптов или прикреплённых файлов. Файл
Word (`.docx`) может иметь размер до 20 МБ и конвертируется в PDF во
время выполнения запроса максимум за 25 секунд; к полученному PDF
применяются те же ограничения. До 5 файлов Word за сессию. Файл Word
с макросами, отслеживанием исправлений, ссылками на внешний контент
или внедрёнными объектами отклоняется с ошибкой
`signature_document_not_supported`, а для файла, который не удалось
сконвертировать, возвращается
`signature_document_conversion_failed`, в каждом случае с указанием
`reason`.
fields:
type: array
description: >-
Необязательные поля для размещения в этом документе, до 200. Номера
страниц и координаты позиций относятся к PDF (или к
сконвертированному PDF для файла Word). Без полей подписант просто
читает документ и соглашается с ним.
items:
$ref: '#/components/schemas/SignatureField'
maxItems: 200
SignatureField:
type: object
description: >-
Поле для размещения в документе сессии: кто из подписантов его
заполняет, как и где. Укажите либо позицию (`page`, `x`, `y`, `width` и
`height`), либо `anchor`. Позиции представляют собой доли отображаемой
страницы от её верхнего левого угла, округлённые до 4 десятичных знаков,
и поле должно полностью помещаться в пределах страницы. Документ вмещает
до 200 полей, а один подписант может иметь до 500 полей, и для каждой
роли с полями в документе там требуется поле `signature` или `initials`.
См. [Поля в
документе](/ru/core-technology/electronic-signature/overview#поля-на-документе).
required:
- key
- type
properties:
key:
type: string
pattern: ^[a-z][a-z0-9_]{0,63}$
description: >-
Задаёт имя поля в результатах и в `sign.field_values`. Уникально в
пределах документа.
type:
type: string
enum:
- signature
- initials
- full_name
- date_signed
- text
- checkbox
- email
- data
description: >-
Что содержит поле. Подписант ставит свою принятую `signature` и
`initials`, вводит `text`, отмечает `checkbox` и вводит `email`,
если в сессии нет подтвержденной электронной почты. Didit заполняет
`full_name` (подтвержденное имя), `date_signed` (дату подписания в
часовом поясе подписанта), `data` (из `prefill`) и подтвержденный
`email`, отображая их только для чтения. Тип для выбора даты
отсутствует: используйте `text`.
role:
type: string
enum:
- verified_person
- legal_representative
- key_people
description: >-
Кто заполняет поле (со значениями `signature_signer`). Шаг заполняет
и подписывает только поля своего подписанта. По умолчанию
используется подписант шага.
page:
type: integer
minimum: 1
description: >-
Номер страницы, от 1 до общего количества страниц документа. Для
документа Word это страница сконвертированного PDF.
x:
type: number
minimum: 0
maximum: 1
description: Левый край, в виде доли ширины страницы.
'y':
type: number
minimum: 0
maximum: 1
description: Верхний край в виде доли от высоты страницы.
width:
type: number
minimum: 0.02
maximum: 1
description: >-
Ширина в виде доли от ширины страницы. Подпись имеет ширину не менее
`0.12`.
height:
type: number
minimum: 0.012
maximum: 1
description: >-
Высота в виде доли от высоты страницы. Высота подписи составляет не
менее `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: >-
Отображается подписывающему лицу и в результатах. По умолчанию
определяется типом.
placeholder:
type: string
nullable: true
maxLength: 80
description: Только `text` и `email`.
validation:
$ref: '#/components/schemas/SignatureFieldValidation'
prefill:
type: string
nullable: true
description: >-
Откуда поступает значение: `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.` (ключ из `metadata` сессии) или `api.` (ключ
из `sign.field_values`). Обязательно для `data`. `full_name` всегда
использует `identity.full_name`, а `email` использует
`contact.email`. Значения полей `data`, `full_name` и
верифицированного `email` фиксируются в момент, когда подписант
начинает подписание.
editable_when_prefilled:
type: boolean
default: false
description: >-
Только `text` и `email`: подписант может изменить предзаполненное
значение.
checked_by_default:
type: boolean
default: false
description: 'Только для `checkbox`: флажок изначально установлен.'
date_format:
type: string
enum:
- DD/MM/YYYY
- MM/DD/YYYY
- YYYY-MM-DD
- D MMMM YYYY
default: DD/MM/YYYY
description: Только `date_signed`.
SignatureFieldAnchor:
type: object
description: >-
Размещает поле по фрагменту текста в документе вместо позиции. Didit не
удаляет этот текст из PDF, поэтому задайте для него тот же цвет, что и у
фона страницы. Если текст не найден, вызов возвращает `400` с
`field_anchor_not_found`. См. [Размещение полей по якорному
тексту](/ru/sessions-api/create-session#размещение-полей-по-тексту-якорю).
required:
- text
properties:
text:
type: string
minLength: 1
maxLength: 64
description: >-
Текст, искомый в документе. Для файла Word поиск выполняется в
преобразованном PDF.
occurrence:
type: string
enum:
- first
- all
default: first
description: >-
`all` размещает по одному полю на каждое совпадение; ключи после
первого получают суффиксы `_2`, `_3` и так далее.
offset_x:
type: number
description: Добавляется к левому краю текста в виде доли от ширины страницы.
offset_y:
type: number
description: Добавляется к верхнему краю текста в виде доли от высоты страницы.
width:
type: number
minimum: 0.02
maximum: 1
description: Ширина поля в виде доли от ширины страницы.
height:
type: number
minimum: 0.012
maximum: 1
description: Высота поля в виде доли от высоты страницы.
SignatureFieldValidation:
type: object
nullable: true
description: >-
Правила для значения поля `text`. Предпросмотр в панели управления,
процесс подписания и API применяют одни и те же правила.
properties:
kind:
type: string
enum:
- any
- letters
- number
- email
- pattern
description: >-
`letters`: буквы в любой системе письма, пробелы, дефисы и
апострофы. `number`: цифры с необязательным десятичным разделителем.
`pattern`: значение должно соответствовать шаблону `pattern`.
min_length:
type: integer
minimum: 0
maximum: 500
description: От `0` до `max_length`.
max_length:
type: integer
minimum: 1
maximum: 500
default: 120
pattern:
type: string
nullable: true
minLength: 1
maxLength: 200
description: >-
Обязательно при `kind: "pattern"`. Регулярное выражение, которому
должно соответствовать значение целиком. Lookaround-проверки и
обратные ссылки не поддерживаются.
message:
type: string
nullable: true
maxLength: 120
description: Отображается подписывающему лицу вместо стандартной ошибки.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
API-ключ вашего приложения из раздела «Разработчикам» -> «API-ключи» в
Business Console. Основной ключ имеет полный доступ. Именованный ключ
может иметь ограниченную область действия: без доступа, чтение или
запись для каждого ресурса, ограничение определенными сценариями или
одобренными сессиями, списком IP-адресов и сроком действия. 401
означает, что ключ неверен, отозван или его срок действия истек; 403
означает, что ключ не был передан, у ключа нет доступа к этому ресурсу
или действию, либо запрос поступил с адреса вне его списка IP-адресов;
404 на маршруте сессии означает, что сессия не входит в сценарии или
статусы ключа. Ключ без доступа к медиа получает URL изображений, видео
и PDF как null, а ключ без прав на запись сессий получает ссылки на
сессии и токены как null. См. https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.