Authentication
Send your key in the Authorization header on every request:
Authorization: Bearer dk_live_…
- Keys are secret. Call the API from your servers only: never from browsers, mobile apps or public repositories.
- A key passed in the URL (
?api_key=) is rejected withapi_key_in_query. Rotate any key that was ever put in a URL. - Accounts can hold several keys, grouped into projects. A key can be limited to some APIs and given an expiry date; calls outside its APIs fail with
scope_not_in_key, and an expired key getsexpired_api_key. - To rotate a key, use Rotate in the dashboard: you get a new key with the same settings, and the old one keeps working for the grace period you choose, so you can deploy without downtime. Revocation takes effect immediately.
Storing a key. Keep it in an environment variable or a secret manager, never in source control. Keys carry a fixed dk_live_ or dk_admin_ prefix so secret scanners can spot one easily — if a key does reach a public repository, rotate it straight away and revoke the old one once your deploy is through.
Two kinds of key. A data key (dk_live_…) reads listings, market data, analytics and projects. An admin key (dk_admin_…), created by an organization owner, manages the organization itself — keys, projects, members, usage and audit events — and is the only thing the /v1/organization endpoints accept. The two never overlap: a data key on an admin endpoint gets admin_key_required, an admin key anywhere else gets admin_key_not_allowed. Admin calls aren't metered.
Test keys. A dk_test_… key reads the same live data as a live key, under a fixed allowance of 1,000 units a month at 30 units a minute, 25 results a page and 250 deep. It counts against its own buckets, so a test key left running in CI can't eat the quota your production integration depends on, and it can never generate a bill — overage is off whatever the plan allows. It reaches the same APIs your plan does, so what you build against is what you ship against. Create one on the API keys page; an organization can hold three, separate from the plan's limit on live keys.
OAuth is for the MCP server, not direct calls. People connect AI assistants through Darak MCP by signing in with OAuth. The MCP server exchanges their token for a short-lived API credential bound to the organization they chose at consent, so those calls count against that organization's plan and appear in its logs. Tokens issued to MCP clients are not accepted by the API directly: a server, script or scheduled job should hold a key.