> ## 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.

# Sessions API：KYC・KYBを統合した本人確認API

> DiditのSessions APIは、KYCとKYBを1つのエンドポイントで実行できる統合APIです。従量課金制、2秒未満の推論、220以上の国と14,000種類以上の書類に対応。毎月$10の無料クレジット付き。

セッションは、Diditにおける認証の単位です。認証を開始すると**セッション**が作成され、認証が完了すると、そのセッションに判定ペイロード全体が格納されます。同じセッションAPIで両方の種類を扱います。

| 種類 | 認証の対象 | 判定ペイロードに含まれる内容 |
| - | - | - |
| **本人確認（KYC）セッション** | 個人 | 本人確認、ライブネス、顔照合、POA、NFC、データベース検証、電話番号、メールアドレス、AML、アンケート、デバイス・IP分析 |
| **法人確認 (KYB)セッション** | 企業・法人 | 法人登記の確認、主要人物（役員/UBO）、書類の検証、電話番号、メールアドレス、AML、アンケート、デバイス・IP分析 |

Academyの「ユーザーに表示される内容」に関するレッスンでは、5:34のチャプターでホスト型フローと独自画面の構築を比較検討しています。これはまさに、このAPIによって決まるトレードオフです。

[ホスト型フローと独自画面の構築の比較 | Didit Academy](https://www.youtube.com/embed/LzGe-dMWjUw?start=334\&rel=0\&playsinline=1)

## 種類はワークフローによって決まる

[セッションを作成](https://docs.didit.me/ja/sessions-api/create-session.md)する際には、`workflow_id`を渡します。ワークフローの種類によって、セッションが本人確認になるか法人確認になるかが決まり、呼び出し側が別途選択することはありません。KYBワークフローでは法人確認セッションが、KYCワークフローでは本人確認セッションが作成されます。

## `session_kind`による種類の判別

作成、取得、一覧取得、ステータス更新、共有、インポートのいずれのセッションレスポンスにも、次のトップレベルフィールドが含まれます。

```json theme={null}
{
  "session_id": "...",
  "session_kind": "user",
  ...
}
```

* `"user"`：セッションは**本人確認（KYC）セッション**です。レスポンスにはユーザー固有の機能のarrayが含まれます。
* `"business"`：セッションは**法人確認 (KYB)セッション**です。レスポンスには企業固有の機能のarrayが含まれます。

お客様側では、このフィールドを使ってレスポンスの構造に応じた処理を切り替えてください。

> [!NOTE]
>
> enum値は短い識別子の`"user"`と`"business"`です。APIの使いやすさを考慮して短くしています。ドキュメント全体では、わかりやすさのために正式名称の\*\*本人確認（KYC）**と**法人確認 (KYB)\*\*を使用しています。

## 種類ごとの機能配列

判定に含まれる機能配列は種類によって異なります。一方の種類に存在しないフィールドは、そのレスポンスには一切現れません（nullやプレースホルダーも含まれません）。

| 機能配列 | 本人確認（KYC） | 法人確認 (KYB) |
| - | :-: | :-: |
| `id_verifications` | ✅ | — |
| `liveness_checks` | ✅ | — |
| `face_matches` | ✅ | — |
| `nfc_verifications` | ✅ | — |
| `poa_verifications` | ✅ | — |
| `database_validations` | ✅ | — |
| `registry_checks` | — | ✅ |
| `document_verifications` | — | ✅ |
| `key_people_checks` | — | ✅ |
| `aml_screenings` | ✅ | ✅ |
| `phone_verifications` | ✅ | ✅ |
| `email_verifications` | ✅ | ✅ |
| `questionnaire_responses` | ✅ | ✅ |
| `ip_analyses` | ✅ | ✅ |
| `reviews` | ✅ | ✅ |
| `contact_details` | ✅ | ✅ |

## 共通のトップレベルフィールド

すべてのセッション（両方の種類）に次のフィールドが含まれます。

| フィールド | 説明 |
| - | - |
| `session_id` | セッションのUUID |
| `session_kind` | `"user"`（本人確認/KYC）または`"business"`（法人確認/KYB） |
| `session_number` | アプリケーション内の連番 |
| `session_url` | ホスト型検証ページのURL |
| `status` | セッション全体のステータス（`APPROVED`、`DECLINED`、`IN_REVIEW`、`IN_PROGRESS`など） |
| `workflow_id` | 使用したワークフローのUUID |
| `vendor_data` | エンティティに対するお客様側の識別子。[詳細はこちら](https://docs.didit.me/ja/entities/vendor-data-linking.md) |
| `metadata` | 作成時に添付した任意形式のJSON |
| `callback` | 任意のコールバックURL |
| `features` | ワークフローが実行する機能のカンマ区切りリスト |
| `expected_details` | クロスバリデーション用の任意の期待データペイロード |
| `created_at`, `expires_at` | タイムスタンプ |

## 対象のエンドポイント

以下のエンドポイントはすべて、どちらの種類にも対応しています。`/v3/business-session/*`のような個別のパスはありません。

| エンドポイント | 対応内容 |
| - | - |
| [`POST /v3/session/`](https://docs.didit.me/ja/sessions-api/create-session) | ワークフローの種類に応じて、本人確認セッションまたは法人確認セッションを作成 |
| [`GET /v3/session/{id}/decision/`](https://docs.didit.me/ja/sessions-api/retrieve-session) | どちらの種類も取得（`session_id`に基づいて振り分け） |
| [`GET /v3/sessions/`](https://docs.didit.me/ja/sessions-api/list-sessions) | どちらの種類も一覧表示。絞り込むには`session_kind`クエリパラメーターを使用 |
| [`PATCH /v3/session/{id}/update-status/`](https://docs.didit.me/ja/sessions-api/update-status) | どちらの種類も更新 |
| [`DELETE /v3/session/{id}/delete/`](https://docs.didit.me/ja/sessions-api/delete-session) | どちらの種類も削除 |
| [`GET /v3/session/{id}/generate-pdf/`](https://docs.didit.me/ja/sessions-api/generate-pdf) | どちらの種類もPDFを生成（本人確認または法人確認のテンプレートに振り分け） |
| [`POST /v3/session/{id}/share/`](https://docs.didit.me/ja/sessions-api/share-session/share) | 共有トークンに`session_kind`が含まれる |
| [`POST /v3/session/import-shared/`](https://docs.didit.me/ja/sessions-api/share-session/import) | どちらの種類もインポート（トークンの`session_kind`を保持） |

## 検索の仕組み

本人確認セッションと法人確認セッションは、それぞれ異なる2種類のセッションです。IDにはUUIDを使用しているため、衝突は起こりません。`session_id`を指定してエンドポイントを呼び出すと、Diditは次のように処理します。

1. まず本人確認のテーブルでIDを検索します（トラフィックの大部分はこれで処理されます）。
2. 見つからない場合は、法人確認のテーブルを検索します。
3. どちらのテーブルにも一致するものがなければ、404を返します。

どちらの種類を探しているかをAPIに伝える必要はありません。

## ステータスは両方の種類で共通

ステータス値は両方の種類で同じであり、APIはここに記載されているとおりの表記で返します。`"Not Started"`、`"In Progress"`、`"Approved"`、`"Declined"`、`"In Review"`、`"Abandoned"`、`"Expired"`、`"Kyc Expired"`、`"Resubmitted"`、`"Awaiting User"`。完全一致かつ大文字と小文字が区別されます。詳細なリファレンスは[認証ステータス](https://docs.didit.me/ja/integration/verification-statuses.md)を参照してください。

## Webhook

Webhookイベントにはすでに`session_kind`フィールドが含まれているため、Webhookハンドラーで種類ごとに処理を振り分けられます。

| イベント | 種類 | 発生するタイミング |
| - | - | - |
| `status.updated` | 両方 | セッションのステータスが変更されたとき。ペイロードには`session_kind: "user"`または`"business"`が含まれます。 |
| `data.updated` | 両方 | セッションのデータが変更されたとき(機能の結果、登記情報の更新、継続的なAMLモニタリング)。ペイロードには`session_kind`が含まれます。 |
| `business.status.updated` / `business.data.updated` | 企業エンティティ | 紐づく企業エンティティが変更されたとき。 |
| `user.status.updated` / `user.data.updated` | ユーザーエンティティ | 紐づくユーザーエンティティが変更されたとき。 |

署名検証と再試行の仕組みについては[Webhook](https://docs.didit.me/ja/integration/webhooks.md)を、法人確認 (KYB)のイベント一覧については[KYB Webhook](https://docs.didit.me/ja/business-verification/webhooks.md)を参照してください。

## 次のステップ

> [card] [セッションの作成](https://docs.didit.me/ja/sessions-api/create-session.md)
>
> ユーザー認証または企業認証を開始します。

> [card] [セッションの取得](https://docs.didit.me/ja/sessions-api/retrieve-session.md)
>
> 判定を取得します。両方の種類に対応しています。

> [card] [セッションの一覧](https://docs.didit.me/ja/sessions-api/list-sessions.md)
>
> `session_kind`でフィルターできます。

> [card] [ステータスの更新](https://docs.didit.me/ja/sessions-api/update-status.md)
>
> 承認、却下、レビュー、再提出を行います。

> [card] [PDFの生成](https://docs.didit.me/ja/sessions-api/generate-pdf.md)
>
> 種類ごとのPDFレポートを生成します。

> [card] [共有とインポート](https://docs.didit.me/ja/sessions-api/share-session/overview.md)
>
> アプリケーション間でセッションを移動します。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.