Rate Limits · Developers

Rate limits are enforced per credential (per API key or per CLI-Bearer session), per named scope, per hour. Named scopes group endpoints that share a budget — a burst of send-message calls, for example, does not consume from the budget for read-user calls.

What happens when you hit a limit

When a scope’s hourly budget is exhausted, the API returns 429 Too Many Requests with a Retry-After header (seconds until reset) and a JSON body. Every 4xx and 5xx response type is catalogued at /developers/errors.

Example 429 response

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

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

The Retry-After value is the number of seconds until the limit resets. Always honor it — do not retry earlier. For hourly scope exhaustion, the code may differ or be absent; see machine-readable error codes for the full reference.

Free-plan daily throttles

On free-plan organizations, two endpoints have a hard per-org per-day limit in addition to the standard per-credential hourly scopes. These throttles are no-ops on paid plans and on API-key transport.

Endpoint	Free-plan limit	On excess
POST /v1/agent-reports/	50 per org per day	429 + code: "free_plan_daily_limit_exceeded"
POST /v1/send-email/	20 per org per day	429 + code: "free_plan_daily_limit_exceeded"

• Daily limits reset at 00:00 UTC.
• When throttled, the Retry-After header indicates seconds until the daily reset.
• Paid plans have no per-day cap on these endpoints.

Named scopes

The public API buckets endpoints into a small set of named scopes so a burst on one activity does not block unrelated activity on the same credential. The current scope list is descriptive of the endpoint families it covers:

• default reads — Every GET endpoint that is not covered by a more specific scope below. Most read-heavy integrations live here.
• general writes — Non-agent, non-messaging POST/PATCH/DELETE — users, teams, kudos, invitations, workflows, forms, check-ins.
• messaging — Every endpoint that sends a bot message on a chat platform (Slack, Teams, Discord, Google Chat) or opens a conversation.
• email — Every endpoint that sends transactional email on behalf of the caller.
• invitations — Every endpoint that creates or resends a user or guest invitation.
• workflow triggers — API-triggered workflow runs.
• agent-scoped — The agent-system endpoints (reports, health, messages, email, webhook, register) — designed for higher-cadence machine callers.
• authentication — OTP + OAuth + token-exchange endpoints. Stricter, to protect the auth surface from brute-force.

Current per-scope quotas

Concrete quotas per scope are not published as a contract. If you need to design capacity against a specific number, contact Dailybot support — we’ll share the current value for your account’s scopes. In the general case, the design guidance below keeps every well-behaved integration well under the line without a spec.

Design guidance

• Cache read responses when the data is org-scoped and does not change often — organization info, user list, team list.
• Use pagination cursors — do not re-scan a list from offset 0 on every job run.
• Batch writes (one POST with 20 items instead of 20 POSTs) whenever an endpoint supports it.
• Honor Retry-After on every 429 — do not retry earlier. Add jitter to your retry delay to avoid thundering-herd resets when the quota window rolls over.
• For agent-cadence heartbeats (agent-health, agent-messages), pick an interval that matches your actual poll need. A heartbeat every 5 seconds is almost always over-engineering.