Skip to content

Rate Limits · Developers

How the Dailybot public API paces callers, how you learn you’ve been throttled, and how to design an integration that stays under the line.

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 small 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."
}

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.