Key takeaways (TL; DR)
Diditなら数時間で本人確認のフルフローを実装して、今日リリース可能。
まずはノーコードで素早く開始し、プロジェクト拡大に合わせてAPIへ拡張して柔軟性を確保。
KYCのメインプランは無料・無制限。初日からコストを増やさずスケール可能。
ユーザー体験を損なわず、同時に厳格なコンプライアンス要件を満たす設計。
KYC APIの導入は、本来より面倒になりがちです。重要な箇所のドキュメントが薄かったり、サンドボックスと本番の挙動が一致しなかったり、Webhookが理由なく失敗することも。心当たりがあるなら、このガイドが役立ちます。
DiditのKYC APIを使えば、公的身分証と生体認証の実運用フローを数時間で構築できます。1:1のFace Matchとパッシブ・ライブネス(Passive Liveness)に加え、署名付きWebhookと“本番同等”のサンドボックスで、検証ステータスをリアルタイム管理可能。さらにスピード重視なら、ノーコードの検証フローで数分で本番投入できます。
何より、DiditのKYC APIは完全無料。無料・無制限で本人確認を回せるので、すぐにプラットフォームの拡大を始められます。
本ガイドはエンジニアによる、エンジニアのための内容です。数秒で承認されるセッションと理解しやすいステータスを備えた堅牢な検証フローを短時間で立ち上げることを目的としています。「KYC APIを1日で実装する方法」を探していた方は、まさにここが正解です。
KYCソリューションの統合により、企業は本人確認プロバイダーを通じて本人確認要件を満たせます。これらの統合はユーザー検証を自動化し、マネーロンダリング対策(AML)をはじめとする規制遵守の要となります。
一般的に、KYC統合はAPI(柔軟性)か、ホスト型の検証URL(スピード)で実装します。どちらを採るかは、プロダクトの要件次第です。
標準的なDidit統合は、Diditホストのワークフロー、ユーザーごとの検証セッション、フロー実行用の検証URL、そしてリアルタイム同期のための署名付きWebhookで構成されます。最小サイクルは次のとおり:workflow_id
でセッション作成 → 検証url
にユーザーを誘導 → 決定結果を含むWebhookを受信 → 必要に応じてAPIで結果を取得。Diditのモジュール性により、AMLスクリーニング、住所証明(Proof of Address)、年齢推定などを基盤を作り直さずに追加できます。
詳細はフルドキュメント(API Full Flow)をご参照ください。
Business Console(無料登録)にログインし、左メニューのAPI & Webhooksへ。ここでAPI Key(リクエストヘッダーX-Api-Key
で認証)とWebhook Secret Key(Webhook署名検証用)を取得します。
同画面で、ステータス変更を通知するWebhook URLも設定します。
これらの値は環境変数(.env)として保存してください:
API_KEY=<YourApiKey>
WEBHOOK_SECRET_KEY=<YourWebhookSecretKey>
WEBHOOK_URL=https://yourapp.example.com/api/webhooks/didit
次に検証サービスを呼び出します。以下は例です。workflow_id
、callback
、API_KEY
は実値に置き換えてください。
POST /v2/session/
Host: verification.didit.me
Content-Type: application/json
X-Api-Key: {YourApiKey}
{
"workflow_id": "11111111-2222-3333-4444-555555555555", // Replace with your chosen workflow
"callback": "<https://example.com/verification/callback>",
"vendor_data": "user-123", // Your user identifier
"metadata": {
"user_type": "premium",
"account_id": "ABC123"
},
"contact_details": {
"email": "taro.yamada@example.com",
"email_lang": "ja",
"phone": "+81312345678"
}
}
レスポンスには、session_id
、初期status
、Diditホストのフローにユーザーを誘導する検証url
などが含まれます。
{
"session_id": "11111111-2222-3333-4444-555555555555",
"session_number": 1234,
"session_token": "abcdef123456",
"vendor_data": "user-123",
"metadata": { "user_type": "premium", "account_id": "ABC123" },
"status": "Not Started",
"workflow_id": "example_workflow_id",
"callback": "<https://example.com/verification/callback>",
"url": "<https://verify.didit.me/session/abcdef123456>"
}
より詳しい説明や追加のコード例は、ドキュメントのCreate Sessionをご覧ください。
検証url
が得られたら、ユーザーをリダイレクト(最も簡単)するか、レイアウトを維持したい場合は<iframe>
で埋め込みます。Diditはワークフローに従って、ドキュメント撮影、セルフィー、ライブネスをオーケストレーションします。
各ステップ完了時にセッションのステータスが進み、Webhookで通知されます。
結果はWebhook(推奨)またはAPIによる随時取得の2通り。Webhookなら、セッションの状態変更ごとにバックエンドがリアルタイム通知を受信—ポーリング不要で“単一の信頼ソース”を維持できます。
Webhookの正当性を担保するため、ヘッダーX-Signature
の署名をWEBHOOK_SECRET_KEY
で必ず検証してください。併せてX-Timestamp
を確認し、短い許容ウィンドウ(例:5分)を超えるリクエストは拒否してリプレイ攻撃や不正を防ぎます。
詳細はドキュメントのWebhooksセクションを参照してください。
もしWebhook未達などで整合を取りたい場合は、決定結果をオンデマンドで取得できます:
GET <https://verification.didit.me/v2/session/{sessionId}/decision/>
X-Api-Key: <YourApiKey>
自社システムでステータスを一貫してマッピング(例:Not Started → In Progress → In Review → Approved / Declined / Abandoned)し、UIやメトリクスにも遷移を反映しましょう。プロダクト・サポート・アナリティクス間の齟齬を防げます。
より細粒度の制御が必要なら、DiditのスタンドアロンAPIが最適です。オールインワンのKYC API(ID Verification、1:1 Face Match、Passive Liveness)に加え、必要な機能だけを組み合わせてカスタム検証パイプラインを構築できます。
DiditのスタンドアロンAPIでできること:
Diditは無料・無制限の本人確認プランを提供しています。つまり、KYC APIの利用コストは0。単発でも数百回でも同じです。
小さな但し書きや縛り、固定パッケージはありません。Diditはシンプルでオープン、柔軟かつ経済的な代替手段で、既存ベンダー比で**最大約70%**のコスト削減が見込めます。ビジネスモデルは、任意機能(AML Screening、Proof of Address、Phone/Email Verification等)とスタンドアロンAPIの利用量に基づきます。
スタンドアロンAPIの料金をご確認ください。