> ## 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認証：KYC APIリクエストを安全に送信する方法

> Didit APIのリクエストは、スコープ付きのAPIキーをx-api-keyヘッダーに指定して認証します。キーが誤っているか期限切れの場合は401、キーがない場合は403が返されます。



API認証プロンプト
        プロンプトをクリップボードにコピー



      
      

\<pre>

\````# Goal — authenticate against Didit's REST API

Two hosts, two auth schemes. Never mix them up.

\## Host map

\| Host | Surface | Auth header |
\|---|---|---|
\| `https://verification.didit.me` | Verification API — sessions, workflows, entities, transactions, standalone APIs, lists, webhooks, billing (every `/v3/...` route) | `x-api-key: <DIDIT_API_KEY>` |
\| `https://apx.didit.me` | Account / organization / application management (`/auth/v2/programmatic/...`, `/auth/v2/organizations/...`) | `Authorization: Bearer <JWT access_token>` |

The verification API does **not** use OAuth Bearer tokens. It uses a long-lived API key on the `x-api-key` header. Treat the key as a server-side secret — never ship it to a browser or mobile bundle.

\## How to obtain the api_key (no console UI needed)

\<Warning>
Substitute `you@yourdomain.com` below with a real inbox. The register endpoint sends the verification code synchronously, so reserved test domains (`@example.com`, `@example.org`, `@*.test`, `@*.example`, `@*.invalid`) get refused by mail delivery and the call returns a `500`.
\</Warning>

\```bash
\# 1) Register — emails a 6-char code (15 min TTL).
\#    Password rules: ≥8 chars, 1 uppercase, 1 lowercase, 1 digit, 1 special.
curl -X POST https://apx.didit.me/auth/v2/programmatic/register/ \
-H "Content-Type: application/json" \
-d '{"email": "you@yourdomain.com", "password": "StrongP@ss1"}'

\# 2) Verify email — returns api_key inline.
curl -X POST https://apx.didit.me/auth/v2/programmatic/verify-email/ \
-H "Content-Type: application/json" \
-d '{"email": "you@yourdomain.com", "code": "A3K9F2"}'
\# 200 -> { access_token, refresh_token, organization, application: { api_key, client_id, uuid } }
\```

Persist `response.application.api_key` as the env var `DIDIT_API_KEY`.
New keys start with `sk_live_` (live application) or `sk_test_` (sandbox application), followed by 43 URL-safe characters.
Keys created before this format have no prefix and keep working, so never validate a key by its prefix.

\## Recover the key (lost it)

\```bash
\# Log back in to get a fresh JWT
TOK=$(curl -s -X POST https://apx.didit.me/auth/v2/programmatic/login/ \
-H "Content-Type: application/json" \
-d '{"email":"you@yourdomain.com","password":"StrongP@ss1"}' | jq -r .access_token)

\# Find your org and app
curl https://apx.didit.me/auth/v2/organizations/me/ -H "Authorization: Bearer $TOK"
curl https://apx.didit.me/auth/v2/organizations/me/$ORG_ID/applications/$APP_ID/ \
-H "Authorization: Bearer $TOK"
\# Response.api_key is your key.
\```

\## Calling the verification API

\```bash
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"workflow_id":"<WORKFLOW_ID>","vendor_data":"user-42","callback":"https://myapp.com/return"}'
\```

\## Failure modes

\| Status | Meaning | Fix |
\|---|---|---|
\| `401` on verification.didit.me | `x-api-key` header wrong, malformed, revoked or expired | Re-fetch via the recover-key flow above, or use a key that has not expired |
\| `403` on verification.didit.me | No `x-api-key` header, a scoped key without access to this resource or action, or a key called from an address outside its IP list | Use a key with that access (Developers -> API keys in the console) |
\| `403` with `"code": "application_deleted"` on verification.didit.me | The key's application was deleted. You get this for a few minutes after the deletion; after that the key is refused like any invalid key | Do not retry: the application and its keys no longer exist. Use a key of an application that exists |
\| `404` on a session route | The session is outside the scoped key's workflows or statuses | Use a key whose limits include that session |
\| `403` on apx.didit.me | JWT `Authorization` header missing or expired | Call `POST /auth/v2/programmatic/login/` again |
\| `429` | Rate limit; response includes a `wait` field (seconds) | Back off, then retry |

\## Sources of truth
\- /openapi-auth.json — every account / org / app endpoint
\- /openapi-25.json — every verification endpoint
\- /integration/integration-prompt — end-to-end integration recipe````

\</pre>



      
      

貼り付け先

## APIキーの確認方法Diditでは、APIキーはアカウント内の特定の**Application**に紐づきます。アプリケーションとは、特定のプロジェクトや環境ごとにワークフローを設定し、検証を管理するためのワークスペースです。アプリケーションを作成すると、フルアクセス権を持つプライマリAPIキーが1つ発行されます。それに加えて追加のキーを作成でき、各キーにはサービスやパートナーが必要とするアクセス権だけを付与できます。キーを確認する手順は次のとおりです。**1. Business Consoleにログインする**[**Didit Business Console**](https://business.didit.me)にアクセスしてサインインします。**2. アプリケーションを選択する**画面上部のドロップダウンメニューから、使用する**Application**を選択します。**3. APIキーを開く**左側のサイドバーで**Developers -> API keys**に移動します。**4. キーをコピーまたは作成する****Primary**キーは、そのアプリケーション固有のシークレットです。サービスやパートナーに専用のシークレットを渡すには、必要なアクセス権を持つ新しいキーを作成します。> [!WARNING]
>
> **APIキーはシークレットです。パスワードと同じように扱ってください。**
>
> プライマリキーは、アプリケーションに代わってAPIへのフルアクセスを提供します。フロントエンドのコード、公開リポジトリ、クライアント側のバンドルには絶対に含めないでください。必ずサーバー側でのみ保管してください。### APIキーの形式新しいAPIキーは、本番環境のアプリケーションでは`sk_live_`、サンドボックスのアプリケーションでは`sk_test_`で始まり、その後に43文字のURLセーフな文字(英字、数字、`-`、`_`)が続きます。
この形式の導入前に作成されたキーにはプレフィックスがなく、そのまま引き続き使用できます。
プレフィックスを含むキー全体を`x-api-key`ヘッダーで送信してください。また、プレフィックスがないことを理由にキーを拒否しないでください。## 組織IDの確認方法**組織 ID**は、組織を識別するUUIDです。`/auth/v2/organizations/me/{org_id}/applications/`のような組織単位のAPIパスで使用します。API呼び出しは不要で、Business Consoleから直接コピーできます。**1. 組織設定を開く**[**Didit Business Console**](https://business.didit.me)で**組織設定**に移動します。**2. 組織IDをコピーする****組織 ID**フィールドには、組織名の横に組織のUUIDがクリップボードにコピーするボタンとともに表示されます。***## 認証済みリクエストの送信APIリクエストを認証するには、シークレットAPIキーを`x-api-key` HTTPヘッダーに含めます。以下は、`Create Session`エンドポイントへの認証済みリクエストの例です。```shell cURL theme={null}
curl --request POST \
     --url https://verification.didit.me/v3/session/ \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'x-api-key: YOUR_API_KEY' \
     --data '
{
  "workflow_id": "WORKFLOW_ID",
  "vendor_data": "USER_ID",
  "callback": "CALLBACK_URL"
}
'
```***## エラー処理APIキーが誤っている、形式が不正である、または失効している場合、APIは`401 Unauthorized`を返します。```json theme={null}
{
  "detail": "Authentication credentials were not provided or are invalid."
}
```有効期限切れのキーも`401`を返し、`"detail": "This API key has expired."`が含まれます。
キーなしのリクエストは`403`を返し、`"detail": "You do not have permission to perform this action."`が含まれます。| ステータスコード | 意味 |
| - | - |
| **401** | APIキーが誤っている、形式が不正である、失効している、または有効期限切れである |
| **403** | APIキーが送信されていない、キーに要求されたリソースまたはアクションへのアクセス権がない、またはリクエストがキーのIPリストにないアドレスから送信された |
| `"code": "application_deleted"`を伴う**403** | キーが削除されたアプリケーションに属している。APIは削除後の数分間この応答を返し、その後は他の無効なキーと同様にキーを拒否します。再試行しないでください。アプリケーションとそのキーはすでに存在しません。 |
| **404** | セッションエンドポイントでは、セッションがキーのワークフローまたはステータスの対象外である |すべてのステータス、ボディ、コードは[APIエラー](https://docs.didit.me/ja/integration/api-errors.md)のページに記載されています。***## スコープ付きAPIキープライマリキーを共有するのではなく、サービスやパートナーごとに専用のキーを発行してください。
各キーは独自のアクセス権を持ちます。すべてのリソース(セッション、判定、メディア、人物、企業、取引、ワークフロー、Webhook、アプリケーション設定、分析)ごとになし・読み取り・書き込みを設定でき、さらに任意で特定のワークフロー、承認済みセッションのみ、IPアドレスのリスト、有効期限による制限を加えられます。
キーは24時間の重複期間を設けてローテーションでき、即座に失効させることもできます。スコープ付きアクセスの導入前に作成されたキーは、引き続きフルアクセス権を持ちます。プリセット、各プリセットが対象とするリソース、スコープ付きキーに対するAPIの応答については、[APIキー](https://docs.didit.me/ja/console/api-keys.md)を参照してください。> [!TIP]
>
> `401`エラーを受け取った場合は、正しいアプリケーションに対応する正しいAPIキーを使用しているか、またそのキーが再生成されていないかを再確認してください。


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