Rate Limits

Per-route rate limit policies, the response headers that report your remaining budget, and the canonical 429 retry cookbook for Public API v1.

Brew rate-limits every authenticated public v1 endpoint. Most limits apply per credential and route over a rolling 60-second window. Email audits also use an organization-wide request limit and concurrency limits. Rate-limited responses expose standard Retry-After semantics. The no-auth GET /v1/health and GET /v1/help discovery endpoints have no rate limit.

Headers

Every rate-limited response carries the rate-limit headers, and a 429 RATE_LIMITED or retryable 503 response also carries Retry-After. See Response headers for the complete header catalog and wire-level examples. This page owns the policies and recovery behavior.

Per-Route Policies

Each route declares a named policy in lib/api/rate_limit/policy.ts. The policy name appears in observability dashboards. HTTP rate-limit failures use the stable RATE_LIMITED error code, with the policy context available in the message or logs.

Policy	Per-min limit	Routes
triggers.read	100	GET /v1/automations/triggers
triggers.write	60	POST/PATCH/DELETE /v1/automations/triggers, POST /v1/automations/triggers/{triggerEventId}/fire
automations.read	100	GET /v1/automations
automations.write	60	POST/PATCH/DELETE /v1/automations, POST /v1/automations/{automationId}/run (publish/unpublish is PATCH … { published })
automation.runs.read	100	GET /v1/automations/runs, GET /v1/automations/audience-runs
automation.runs.write	60	POST /v1/automations/{automationId}/test, POST /v1/automations/audience-runs/{audienceRunId}/control
emails.read	100	GET /v1/emails (list or detail), GET /v1/emails/{emailId}/inbox-placement-tests
emails.generate	20	POST /v1/emails
emails.edit	20	PATCH/DELETE /v1/emails/{emailId}, POST /v1/emails/{emailId}/clone, /restore, /export
sends.read	100	GET /v1/analytics/sends
sends.write	10	POST /v1/sends (campaign + { test: true })
sends.control	60	POST /v1/sends/{sendId}/cancel, /pause, /resume
contacts.read	100	POST /v1/contacts/search
contacts.write_single	100	POST /v1/contacts with a single-row body, PATCH/DELETE /v1/contacts/{email}
contacts.write_batch	10	POST /v1/contacts with a batch body, POST /v1/contacts/import-csv, POST /v1/contacts/batch-delete
audiences.read	100	GET /v1/audiences
audiences.write	60	POST/PATCH/DELETE /v1/audiences
domains.read	100	GET /v1/domains, GET /v1/domains/{domainId}/health
domains.write	20	POST/PATCH/DELETE /v1/domains, POST /v1/domains/{domainId}/verify (hits the sending provider)
analytics.read	100	GET /v1/analytics/* (overview, campaigns, automations, events, sends, trigger-instances)
brand.read	100	GET /v1/brand, GET /v1/brand/images
brand.write	60	PATCH /v1/brand
usage.read	100	GET /v1/usage
fields.read	100	GET /v1/fields
fields.write	100	POST /v1/fields, DELETE /v1/fields/{fieldName}
templates.read	100	GET /v1/templates
content.generate	20	POST /v1/content/generate-image, POST /v1/content/gif
email.audit	6	POST /v1/emails/audit
content.transform	60	POST /v1/emails/import, POST /v1/emails/figma, POST /v1/emails/{emailId}/client-previews, POST /v1/emails/{emailId}/inbox-placement-tests, POST /v1/contacts/validate, POST /v1/content/transform, POST /v1/content/html-to-png, POST /v1/content/add-image
chats.read	100	GET /v1/chats/{chatId}

Email Audit Admission

Email audits fan out to several external checks. They use these additional limits across the Public API, MCP, and agent calls:

Dimension	Limit	Scope
Credential or session requests	6 per minute	One credential or signed-in session
Organization requests	20 per minute	All credentials, sessions, MCP calls, and agent calls in one organization
Organization concurrency	4 running audits	One organization
Global concurrency	16 running audits	All organizations

Capacity rejections return 429 RATE_LIMITED with Retry-After. They do not run or charge the audit.

Session Traffic: 300/min Ceiling

UI-backed session traffic (dashboard, Brew chat orchestrator) gets a flat 300/min ceiling across every policy above except email.audit, which stays at 6 per minute. API-key traffic uses the strict per-route limits in the table.

Generosity & Burst Behavior

• The window is a rolling 60 seconds, not a fixed wall-clock minute. A spike at the top of a minute does NOT get a free second budget.
• The store uses Redis sorted-sets (when available); when Redis is unavailable, every rate-limited endpoint fails open with X-RateLimit-Remaining: <limit> and X-RateLimit-Reset: now+60. You will not see spurious 429s during a Redis blip.
• Test mode bypass: BREW_DISABLE_API_RATE_LIMIT=1 on the dev server skips the gate entirely (test-only env var; never set in production).

429 Recovery Cookbook

The canonical retry loop:

import { setTimeout as sleep } from 'node:timers/promises'

async function withRetry<T>(fn: () => Promise<Response>): Promise<T> {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const res = await fn()
    if (res.status !== 429) {
      if (!res.ok) throw new Error(`HTTP ${res.status}: ${await res.text()}`)
      return (await res.json()) as T
    }
    const retryAfterSec = Number(res.headers.get('Retry-After') ?? '1')
    const backoffSec = Math.max(retryAfterSec, 2 ** attempt)
    await sleep(backoffSec * 1000)
  }
  throw new Error('Exhausted retries after repeated 429 responses')
}

// Create one stable key per logical send, outside the retry callback.
const idempotencyKey = 'send-promo-2026-11-27'

const sendResponse = await withRetry<{ status: string; runId: string }>(() =>
  fetch('https://brew.new/api/v1/sends', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.BREW_API_KEY!}`,
      'Content-Type': 'application/json',
      'Idempotency-Key': idempotencyKey,
    },
    body: JSON.stringify({
      emailId: 'eml_abc',
      domainId: 'dom_brand_primary',
      audienceId: 'aud_subscribers',
      subject: 'Black Friday, 40% off',
    }),
  })
)

Key invariants:

• Always honor Retry-After. Take the max of Retry-After and your own back-off so you don’t out-aggressive yourself.
• Reuse the same Idempotency-Key on every retry. See Idempotency for replay semantics.
• Preemptively pause when X-RateLimit-Remaining hits 0. The header ships on rate-limited responses, so a well-behaved client can throttle itself before a 429 ever fires.

The standard 429 RATE_LIMITED and retryable 503 envelopes, including error.retryAfter, are documented in Errors. The header and body carry the same wait duration.

Server-Side Observability

Every rate-limited response records an api.rate_limit.hit event with the policy, admission scope, limit, retry interval, request id, and actor scope. The event does not include request content. If persistent 429 responses do not match your expected request rate, contact support with the x-request-id from one response.

See Also

• Idempotency: pair with Idempotency-Key so retries are safe.
• Errors: full error envelope + every error.code.
• Response headers: every header Brew sets.
• Async jobs & polling: for POST /v1/sends and POST /v1/automations/triggers/{triggerEventId}/fire, you don’t need to call the API again to wait for delivery. Poll the run.

Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you:

Self-Service Tools

Search Documentation

Type in the “Ask any question” search bar at the top left to instantly find relevant documentation pages.

ChatGPT/Claude Integration

Click “Open in ChatGPT” at the top right of any page to explore it further with ChatGPT or Claude.

Talk to Our Team

Schedule a Call

Book time with our founders for personalized guidance on strategy, best practices, or complex implementation questions.

Call Us Directly

Need immediate assistance? Reach us at [phone] for urgent issues or time-sensitive questions.

Slack Channel

Our preferred support channel. You’ll receive an invite after signup for direct founder support and fast responses.

Email Support

Contact us at [e-mail] for detailed inquiries or if you prefer not to use Slack.