API keys

Where your key comes from, exactly what it can do, and how to hold it safely.

One key per app, created with the app itself. It is the only credential this API accepts, and it carries the full authority of the account that owns the app.

Finding your key

Open the console, choose an app, and find the API key card in the right-hand column of the app page. The value is shown masked; the copy button puts the full key on your clipboard.

dk_live_9f3aC2xQ7mB1vT8sE4nK6pR0jY5wZ2hL

Keys are opaque strings prefixed with dk_live_. Treat the whole string as the secret — there is no separate id and secret pair.

What the key can do

The key authenticates as the user who owns the app. That is broader than it may look, so it is worth stating plainly. A holder of the key can:

List, create, rename and delete any workspace under the app.
Upload documents into any of those workspaces, and delete them.
Read every resource's file_url, which is a direct link to the stored original document.
Ask questions and read the chat history of any end user in any of those workspaces.

There is no way to issue a narrower key. Anyone who obtains this key can delete an entire workspace and download every document in it.

Keeping it safe

Which leads to a short list of rules:

Call the API from your backend only. Not from a browser, a mobile app, a desktop app, or a build artefact your users can download.
Read it from an environment variable or a secret manager. Never commit it, and never put it in a client-side bundle where a build step could inline it.
If your users need to ask questions from a browser, proxy through your own server: your frontend calls your API, your API holds the key. That also lets you enforce your own rate limits, which this API does not yet have.
Send a different external_user_id per end user, so the transcripts you store stay separated even though they share one key.

Rotation and revocationOn the roadmap: Soon

Rotation and revocation are not available yet. There is no endpoint to issue a replacement key, retire an old one, or list which keys exist — an app has exactly one key, fixed for the life of the app.

If a key is exposed, contact us and we will replace it manually. Until self-service rotation ships, that is the only route, and it's why the rules above matter more than they would with a rotatable credential.

Finding your key

Open the console, choose an app, and find the API key card in the right-hand column of the app page. The value is shown masked; the copy button puts the full key on your clipboard.

dk_live_9f3aC2xQ7mB1vT8sE4nK6pR0jY5wZ2hL

Keys are opaque strings prefixed with dk_live_. Treat the whole string as the secret — there is no separate id and secret pair.

What the key can do

The key authenticates as the user who owns the app. That is broader than it may look, so it is worth stating plainly. A holder of the key can:

List, create, rename and delete any workspace under the app.

Upload documents into any of those workspaces, and delete them.

Read every resource's file_url, which is a direct link to the stored original document.

Ask questions and read the chat history of any end user in any of those workspaces.

There is no way to issue a narrower key. Anyone who obtains this key can delete an entire workspace and download every document in it.

Keeping it safe

Which leads to a short list of rules:

Call the API from your backend only. Not from a browser, a mobile app, a desktop app, or a build artefact your users can download.

Read it from an environment variable or a secret manager. Never commit it, and never put it in a client-side bundle where a build step could inline it.

If your users need to ask questions from a browser, proxy through your own server: your frontend calls your API, your API holds the key. That also lets you enforce your own rate limits, which this API does not yet have.

Send a different external_user_id per end user, so the transcripts you store stay separated even though they share one key.

Rotation and revocationSoon