Every keyed request authenticates with a DailyTube API key in the `Authorization` header:
```
Authorization: Bearer dtk_YOUR_KEY
```
## Keys
- Keys are created in the [Developer Console](/) — up to **five active** per account.
- A key looks like `dtk_` followed by a long random secret. The full key is shown **exactly once** at creation; DailyTube stores only a hash and cannot recover it.
- Keys carry your account's **full** API access — there are no per-key scopes (yet). Give each integration its own key so you can revoke independently.
- Revoking is immediate: the very next request with that key fails. There is no cached-validity window.
## The uniform 401
Missing, malformed, unknown, and revoked keys all return the **same** response — there is no way to probe whether a key exists or was revoked:
```responses
~~~401
{
"error": { "code": "auth.invalid_key", "message": "Invalid API key" },
"request_id": "5f0c…"
}
~~~
```
A request with **no** key at all returns `401 auth.no_key` instead.
## Plan gating
Authentication and authorization are separate steps. A valid key on a plan without API access gets:
```responses
~~~403
{
"error": { "code": "subscription.api_not_enabled", "message": "API access is not enabled for this plan" },
"request_id": "5f0c…"
}
~~~
```
## Keeping keys safe
> Treat keys like passwords. One per project, never in client-side code, never in git. If a key leaks, revoke it in the console and issue a fresh one — revocation is instant and irreversible.
- Prefer environment variables or a secrets manager over config files.
- Don't send keys to the keyless endpoints (`POST /v1/summarize` accepts anonymous calls — see [Summarize](/docs/summarize)).
- Rotate by creating the new key first, deploying it, then revoking the old one — both can be active during the swap (within the five-key cap).
Authentication
Every keyed request authenticates with a DailyTube API key in the Authorization header:
Authorization: Bearer dtk_YOUR_KEY
Keys
• Keys are created in the Developer Console (/) — up to five active per account.
• A key looks like dtk_ followed by a long random secret. The full key is shown exactly once at creation; DailyTube stores only a hash and cannot recover it.
• Keys carry your account's full API access — there are no per-key scopes (yet). Give each integration its own key so you can revoke independently.
• Revoking is immediate: the very next request with that key fails. There is no cached-validity window.
The uniform 401
Missing, malformed, unknown, and revoked keys all return the same response — there is no way to probe whether a key exists or was revoked:
~~~401
{
"error": { "code": "auth.invalid_key", "message": "Invalid API key" },
"request_id": "5f0c…"
}
~~~
A request with no key at all returns 401 auth.no_key instead.
Plan gating
Authentication and authorization are separate steps. A valid key on a plan without API access gets:
~~~403
{
"error": { "code": "subscription.api_not_enabled", "message": "API access is not enabled for this plan" },
"request_id": "5f0c…"
}
~~~
Keeping keys safe
Treat keys like passwords. One per project, never in client-side code, never in git. If a key leaks, revoke it in the console and issue a fresh one — revocation is instant and irreversible.
• Prefer environment variables or a secrets manager over config files.
• Don't send keys to the keyless endpoints (POST /v1/summarize accepts anonymous calls — see Summarize (/docs/summarize)).
• Rotate by creating the new key first, deploying it, then revoking the old one — both can be active during the swap (within the five-key cap).
Get started / Authentication
Authentication
API keys, how they work, and how to keep them safe.
Every keyed request authenticates with a DailyTube API key in the Authorization header:
Authorization: Bearer dtk_YOUR_KEY
Authorization: Bearer dtk_YOUR_KEY
Keys
- Keys are created in the Developer Console — up to five active per account.
- A key looks like
dtk_followed by a long random secret. The full key is shown exactly once at creation; DailyTube stores only a hash and cannot recover it. - Keys carry your account's full API access — there are no per-key scopes (yet). Give each integration its own key so you can revoke independently.
- Revoking is immediate: the very next request with that key fails. There is no cached-validity window.
The uniform 401
Missing, malformed, unknown, and revoked keys all return the same response — there is no way to probe whether a key exists or was revoked:
{
"error": { "code": "auth.invalid_key", "message": "Invalid API key" },
"request_id": "5f0c…"
}
{
"error": { "code": "auth.invalid_key", "message": "Invalid API key" },
"request_id": "5f0c…"
}
A request with no key at all returns 401 auth.no_key instead.
Plan gating
Authentication and authorization are separate steps. A valid key on a plan without API access gets:
{
"error": { "code": "subscription.api_not_enabled", "message": "API access is not enabled for this plan" },
"request_id": "5f0c…"
}
{
"error": { "code": "subscription.api_not_enabled", "message": "API access is not enabled for this plan" },
"request_id": "5f0c…"
}
Keeping keys safe
Treat keys like passwords. One per project, never in client-side code, never in git. If a key leaks, revoke it in the console and issue a fresh one — revocation is instant and irreversible.
- Prefer environment variables or a secrets manager over config files.
- Don't send keys to the keyless endpoints (
POST /v1/summarizeaccepts anonymous calls — see Summarize). - Rotate by creating the new key first, deploying it, then revoking the old one — both can be active during the swap (within the five-key cap).