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

# Examples

> Example prompts and end-to-end agent conversations with the Didit MCP — set up a KYC workflow, run cross-app analytics, create sessions, and wire webhooks.

A few patterns that show what the Didit MCP is good at. Phrase things in plain language — the agent picks the tools.

***

## Quick prompts

**Operations & monitoring (cross-app)**

* *"Show me the last 5 in-review sessions across all my apps."* → `didit_session_search`
* *"How many people tried phone verification but dropped off in the last 15 days?"* → `didit_analytics` (one call; reads the feature funnel)
* *"Find the customer with vendor\_data `user_8842` and tell me which app and status."* → `didit_vendor_user_search`
* *"What's my credit balance and this month's conversion rate?"* → `didit_org_get_balance` + `didit_analytics`

**Configuration**

* *"Create a KYC workflow with ID scan + liveness and give me a verification link."* → `didit_workflow_create` → `didit_session_create`
* *"Create an ID-verification workflow that only accepts passports, then a selfie liveness."* → `didit_workflow_create` — just say `documents_allowed: ["PASSPORT"]`; the MCP expands it to passport-only for every country (see [Advanced → feature configs](/integration/mcp/advanced#feature-configs-and-allow-lists)).
* *"New workflow: scan a passport; if the ID is declined, decline the session; if the stated profession is ≈ 'Software Engineer' (≥60%), run a liveness check; otherwise ask for proof of address in Spanish; then auto-decide."* → `didit_workflow_get_field_definitions` → `didit_workflow_validate_graph` → `didit_workflow_set_graph` (a branch on `kyc.status` plus a `fuzzy_match` on `kyc.extra_fields.profession`, with an else path to a POA step)
* *"In workflow `26d33c04…`, after ID verification: if it's declined, decline the session; if the profession is ≥80% similar to 'Software Engineer', add a proof-of-funds Document-AI step; then continue."* → `didit_workflow_search` → `didit_workflow_get_graph` → `didit_workflow_edit_graph` (small ops, saved as a reviewable draft — preserves the existing pipeline + allow-lists)
* *"Register a webhook for status updates and show me the signing secret."* → `didit_webhook_create`

**Compliance**

* *"Screen this wallet for AML and add it to the blocklist if it hits."* → `didit_transaction_screen_wallet` + `didit_blocklist_add`
* *"Open a case for session `…` and assign it to me."* → `didit_case_create` → `didit_case_manage`

***

## End-to-end: stand up verification

> **You:** "Set up Didit identity verification for my app with ID scan and liveness."
>
> **Agent:** I'll create the workflow. *(calls `didit_workflow_create` with ID scan + passive liveness)* — Published **"Standard KYC"**, `workflow_id = 6f2c…`. Here's how to create a session from your backend:
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
>   -H "x-api-key: $DIDIT_API_KEY" \
>   -H "Content-Type: application/json" \
>   -d '{ "workflow_id": "6f2c...", "vendor_data": "internal-user-id", "callback": "https://myapp.com/done" }'
> ```
>
> Redirect the user to `response.url`. (That `x-api-key` is your application's **REST API key**, used by your backend to create sessions — it's separate from how you signed in to this MCP, which uses *Log in with Didit*.) Want me to register the webhook destination too?
>
> **You:** "Yes — my endpoint is `https://myapp.com/webhooks/didit`."
>
> **Agent:** *(calls `didit_webhook_create` with `webhook_version: "v3"`, `subscribed_events: ["status.updated"]`)* — Done. Store this signing secret as `DIDIT_WEBHOOK_SECRET`: `whsec_…`. Verify the `X-Signature-V2` header on each delivery before trusting it.

***

## Session results are asynchronous

`didit_session_create` returns a `session_id`, a `session_token`, and a hosted `url` — but the verification hasn't happened yet. The user opens `url` and completes the flow. The final decision arrives via:

1. A `status.updated` **webhook** (recommended), or
2. `didit_session_get_decision` (polling, as a fallback).

Both share the same shape — **always plural arrays** with a `node_id` per entry:

```json theme={null}
{
  "session_id": "uuid",
  "status": "Approved",
  "session_kind": "user",
  "id_verifications":  [ { "node_id": "first_id", "status": "Approved", "first_name": "Jane" } ],
  "liveness_checks":   [ { "node_id": "first_liveness", "status": "Approved", "score": 95.4 } ],
  "face_matches":      [ { "node_id": "first_face_match", "status": "Approved", "score": 96.1 } ],
  "aml_screenings":    [ { "node_id": "first_aml", "status": "Approved", "total_hits": 0, "hits": [] } ],
  "reviews": []
}
```

Never read singular V2 keys (`id_verification`, `liveness`) — they only ship when a destination is explicitly pinned to `webhook_version: "V2"`. See [Data models](/reference/data-models) for the per-feature field reference and [Advanced → Webhooks](/integration/mcp/advanced#handling-webhooks) for verification and retry rules.

***

## Pair it with the one-prompt integration

The MCP is great for *running* Didit. To have an agent *write* a full integration (backend route + frontend SDK + webhook handler + DB schema), hand it the [Integration Prompt](/integration/integration-prompt) — it walks the seven steps and calls MCP tools to create the workflow, session, and webhook live.

***

<CardGroup cols={2}>
  <Card title="Tools reference" icon="wrench" href="/integration/mcp/tools">
    Everything the agent can call.
  </Card>

  <Card title="Advanced & troubleshooting" icon="gear" href="/integration/mcp/advanced">
    Scopes, cross-app behavior, webhooks, self-hosting.
  </Card>
</CardGroup>