Authentication

All Dailybot API requests require authentication via an API key passed in the request headers. This page covers the required headers, authentication methods, and security best practices.

API Key Authentication

Dailybot uses header-based authentication. Include your API key in theX-API-KEY header with every request.

curl -X GET "https://api.dailybot.com/v1/me/" \
  -H "X-API-KEY: your_api_key" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json"

{
  "id": "usr_abc123",
  "email": "[email protected]",
  "first_name": "Jane",
  "last_name": "Doe",
  "role": "admin"
}

{
  "detail": "Authentication credentials were not provided."
}

Parity guarantee — API key vs. CLI Bearer

Dailybot supports two credential types for the public API: a long-livedAPI key (X-API-KEY header) and a personalCLI Bearer token (Authorization: Bearer …) obtained via dailybot login. Both credentials grant thesame access to every public endpoint below, with the sole exception of the four CLI-only endpoints listed at the end of this section.

This is an explicit design commitment: fields, pagination, error codes, and rate-limit scopes are the same across credential types for the same underlying user. Enforcement is being rolled out inapi-services — the log of that rollout lives at/developers/api-changelog. If you observe an endpoint that behaves differently under the two credentials, please file an issue — it's a bug against this commitment.

Which credential should I use?

• Personal use / interactive shell: dailybot login. The CLI stores an OTP-derived Bearer session locally and refreshes it transparently.
• Automation / CI / cron: a long-lived API key exported as$DAILYBOT_API_KEY. No interactive login required.
• AI-agent frameworks (Cursor, Claude Code, Codex, Gemini, Copilot):the same $DAILYBOT_API_KEY. The agent-skill package auto-detects it.

The four CLI-only endpoints

These four endpoints are the only rows in the public API that reject API-key auth by design. They are used by the CLI itself to maintain its own session and update lifecycle:

• GET /v1/cli/updates/ — CLI update manifest.
• GET /v1/cli/status/ — CLI session status.
• POST /v1/cli/chat/completions/ — CLI-scoped agent chat.
• /v1/cli/auth/* — CLI OTP authentication endpoints (anonymous).

Every other /v1/ endpoint — /v1/users/,/v1/teams/, /v1/forms/, /v1/kudos/,/v1/workflows/, /v1/checkins/,/v1/send-message/, /v1/agent-*, and the rest — accepts both credential types. See the individual reference pages under/developers/api/ for the exact auth badges per endpoint.

Plan requirements

API keys require a paid Dailybot plan. Every request made with an API key is validated against the key owner's organization plan on every request — not just at key creation. An org that downgrades will have its keys stop working within 60 seconds (cache TTL).

owner vs. created_by

Every API key records two distinct users:

• owner — the user whose identity and role scope the key acts as. All requests see the owner's data, scoped by the owner's role.
• created_by — the admin who minted the key. Nullable on historical keys. Used for auditing.

Organization admins can create a key owned by a member — useful for integrations that need to operate with member-level permissions rather than admin-level.

API key secret lifecycle (show-once)

API key secrets follow show-once semantics — the full plaintext key is only returned at the moment of creation or regeneration. After that, only the last 4 characters (key_suffix) are ever shown.

Member API key access

Non-admin organization members can now manage their own API keys. Previously only admins had access.

Member restrictions when attempting restricted actions:

• Create agent key (is_agent_key: true) → 400 agent_key_admin_only
• Create for another user (for_user_id) → 403 org_admin_required
• PATCH/DELETE another user's key → 404 (key not in member's queryset — no existence leak)

Free-plan CLI allowlist

CLI Bearer tokens on free-plan organizations can only access a restricted set of endpoints. All other /v1/ endpoints return 403 with code: "plan_upgrade_required".

Allowed on free plan (CLI Bearer):

• POST /v1/agent-reports/ — limited to 50/day per org
• POST /v1/send-email/ — limited to 20/day per org
• GET/POST /v1/agent-messages/, POST /v1/agent-messages/read/
• GET /v1/agent/health/, agent registration + claim flow
• GET /v1/me/, GET /v1/organization/, GET /v1/cli/status/

Authentication method matrix

Base URL & Versioning

All API endpoints use the following base URL:

https://api.dailybot.com/v1/

The API is versioned via the URL path. The current and only version isv1. It is recommended that you configure your HTTP client with the full base prefix including the version to ensure forward compatibility.

Exchange Token

The Exchange Token mechanism allows you to make API calls on behalf of other organization members. This is useful for scenarios like:

• Giving kudos to team members programmatically
• Filling in check-in responses for other users
• Performing actions in the context of a different user

Obtaining Exchange Tokens

There are two ways to obtain an exchange token:

1. Via ChatOps & Custom Commands

When a user triggers a custom command in chat, the command receives an exchange token that can be used to make API calls in that user's context.

2. Via Dedicated API Endpoint

You can request an exchange token for a specific user through a dedicated endpoint, provided your API key has the necessary permissions.

Rate Limits

The Dailybot API enforces rate limits to ensure fair usage. If you exceed the limit, you will receive a 429 Too Many Requests response.

{
  "detail": "Request was throttled. Expected available in 30 seconds."
}

Security Best Practices

• Never commit API keys to version control or expose them in client-side code
• Use environment variables or a secrets manager to store credentials
• Rotate keys regularly and immediately revoke any compromised keys
• Revoke unused keys from the Integrations dashboard
• Use HTTPS only — all API requests must use TLS encryption
• Monitor API usage through the dashboard for unexpected activity