Security

Where each key may live, what protects it, and a checklist before you go live.

Daneshyar has three kinds of credential. Each one is safe in one place only.

Server keys and browser keys

Use this table to decide where each one goes:

Where you send it	Who uses it	Rule
`X-API-Key`	Your server, calling the REST API (/v1).	Secret. Keep it in a server environment variable or a secret manager. Never send it to a browser.
`data-api-key`	The widget on your public pages.	Public. Anyone can read it. Today it is the same key as the server key, so read the next section.
`Authorization: Bearer`	The Daneshyar console, after you sign in.	Handled by the console. It does not work with /v1, and you never need to copy it.

The widget uses your app's API key, and that key also works with the REST API. Anyone who opens your page source can use it to list, change or delete the workspaces in that app, and to download its files.

This will change when the widget gets its own limited key. Until then, do these four things:

Make an app only for the widget. A key works only on its own app, so your other apps and their documents stay out of reach.
Upload only documents you would be happy to publish. Never put patient records or private files in it.
Keep your own copy of those documents, so you can rebuild the workspace if needed.
Never use the widget app's key for server work. Server calls use a different app and its own key.

What allowed domains protect

Allowed domains become a frame-ancestors rule on the widget page. That rule is enforced by the visitor's browser.

It does stop: another website showing your widget to its visitors, and using your credits.
It does not stop: someone copying the key and calling the API with a script or curl. The server does not check where a request comes from.

How to write entries: Allowed domains.

Rate limits

The widget has three limits: 20 questions an hour per IP address, 500 a day per app, and 60 loads an hour per IP address. Details are in Limits and costs.

The REST API (/v1) has no rate limit yet. If you put it behind your own endpoint, add your own limit there, per user, so one person cannot use all your credits.

CORS

CORS is a browser rule. It decides which websites may call an API from JavaScript.

The widget does not need CORS from you. It runs on Daneshyar's own site, inside the iframe.
Calling /v1 from your own website's JavaScript is blocked by CORS. That is on purpose: call it from your server.
If your site sends a Content-Security-Policy, allow the widget's site in script-src and frame-src, or the browser blocks the script and the iframe.

Rotating and revoking a keyOn the roadmap: Soon

You cannot rotate or revoke a key yourself yet. Each app has one key for its whole life.

If a key leaks, contact us and we will replace it. Then update your snippet and your server with the new key. Until we replace it, you can delete the app's workspaces to protect their documents.

Checklist before you go live

Your server key is only in server environment variables, and not in Git or any front-end code.
The widget uses its own app, which holds only public documents.
The allowed domains list has your real sites only, and no leftover test domains.
Your own chat endpoint, if you have one, has a rate limit and sends one external_user_id per user.
Your site's Content-Security-Policy allows the widget's script and iframe.
You know who to contact if a key leaks.

X-API-Key

Your server, calling the REST API (/v1).

Secret. Keep it in a server environment variable or a secret manager. Never send it to a browser.

data-api-key

The widget on your public pages.

Public. Anyone can read it. Today it is the same key as the server key, so read the next section.

Authorization: Bearer

The Daneshyar console, after you sign in.

Handled by the console. It does not work with /v1, and you never need to copy it.

Securing the widget key

This will change when the widget gets its own limited key. Until then, do these four things:

Make an app only for the widget. A key works only on its own app, so your other apps and their documents stay out of reach.

Upload only documents you would be happy to publish. Never put patient records or private files in it.

Keep your own copy of those documents, so you can rebuild the workspace if needed.

Never use the widget app's key for server work. Server calls use a different app and its own key.

What allowed domains protect

Allowed domains become a frame-ancestors rule on the widget page. That rule is enforced by the visitor's browser.

It does stop: another website showing your widget to its visitors, and using your credits.

It does not stop: someone copying the key and calling the API with a script or curl. The server does not check where a request comes from.

How to write entries: Allowed domains.

Rate limits

The widget has three limits: 20 questions an hour per IP address, 500 a day per app, and 60 loads an hour per IP address. Details are in Limits and costs.

The REST API (/v1) has no rate limit yet. If you put it behind your own endpoint, add your own limit there, per user, so one person cannot use all your credits.

CORS

CORS is a browser rule. It decides which websites may call an API from JavaScript.

The widget does not need CORS from you. It runs on Daneshyar's own site, inside the iframe.

Calling /v1 from your own website's JavaScript is blocked by CORS. That is on purpose: call it from your server.

If your site sends a Content-Security-Policy, allow the widget's site in script-src and frame-src, or the browser blocks the script and the iframe.

Checklist before you go live

Your server key is only in server environment variables, and not in Git or any front-end code.

The widget uses its own app, which holds only public documents.

The allowed domains list has your real sites only, and no leftover test domains.

Your own chat endpoint, if you have one, has a rate limit and sends one external_user_id per user.

Your site's Content-Security-Policy allows the widget's script and iframe.

You know who to contact if a key leaks.