Your API key is under Developers, API keys; the workflow ID is on the Workflows page; the webhook signing secret is per endpoint under Developers, Webhooks.
You need three values from the console. The API key is created under Developers → API keys. The workflow ID is copied from the Workflows page. The webhook signing secret belongs to each endpoint under Developers → Webhooks, and you can show it again at any time with Reveal. Take all three from the same application and the same environment, Live or Sandbox.
A starter app or an AI-generated project often lists environment variables such as DIDIT_API_KEY, DIDIT_WORKFLOW_ID and DIDIT_WEBHOOK_SECRET. The names belong to that app: Didit does not set them for you. This table says where each value comes from.
#Where each value lives
| Value | Where to get it | What to know |
|---|---|---|
| API key | Developers → API keys, then Create key (every application also has a Primary key) | The full secret is shown once, when you create or rotate the key, so copy it into your secret manager then. A Live application and a Sandbox application have different keys: a sandbox key never creates a live verification. Send it in the x-api-key header, from your server only |
| Workflow ID | Identity verification → Workflows: open the row's menu and choose Copy workflow ID (the preview panel has the same button) | Each workflow has its own ID in each application. A copy of a workflow gets a new ID |
| Webhook signing secret | Developers → Webhooks, open the endpoint, then its signing secret and press Reveal | One secret per endpoint, not per application. Reveal asks you to confirm it is you, then the secret hides again within 60 seconds. You can reveal it again whenever you need it |
| API base URL | Not in the console: docs.didit.me states it | https://verification.didit.me serves the verification API (sessions, workflows, lists, webhooks), authenticated with the x-api-key header. See API authentication |
The API key and the signing secret are different values. The API key authenticates your calls to Didit; the signing secret lets you check that a webhook really came from Didit. Using one in place of the other gives a 401 or a signature mismatch.
#Can I see the webhook signing secret again?
Yes. Open Developers → Webhooks, open the endpoint and press Reveal. Confirm it is you, and the secret shows for up to 60 seconds. If Reveal is greyed out for you, ask a teammate with access or contact support. If you want a new secret, rotate it instead: the old one keeps working for 24 hours. More in getting verification results with webhooks.
#Check your setup
- Match the environment
Pick the application and the Live or Sandbox environment in the console first, then copy the key, the workflow ID and create the webhook endpoint there. A sandbox key with a live workflow ID is a common reason for a 401 or 403.
- Put the values in your server configuration
Store them as server-side secrets. Never put the API key or the signing secret in frontend code, a public repository or a mobile app.
- Create a session
Call the create session endpoint at
https://verification.didit.mewith your key and workflow ID. A 401 means the key is wrong, expired or revoked; a 403 on a workflow usually means the key belongs to a different application. See API errors. - Send a test event
In Developers → Webhooks, open your endpoint and press Send test event. Your server should check the signature with the signing secret and answer with a 2xx. If nothing arrives, see when a webhook never arrives.
#Related
- Managing your API keys
- Getting verification results with webhooks
- Building a verification workflow
- API authentication on docs.didit.me
Still stuck? Talk to a human.
Include your organization ID and the session ID you are asking about.