Limits and schedules

Every published limit — rate, sizes, pages, keys, files, webhooks — and the retry schedule.

View this page as Markdown

Every published number in one place, generated from the constants the API enforces. Limits are the same on every plan.

What Limit
Rate limit per key 600 requests / 60 s
Rate limit on /v1/health 60 requests / 60 s per client address
Request body 1,048,576 bytes (1 MiB) — 413 above it
Page size (limit) default 50; max 200 (100 on /v1/runs and /v1/views/{id}/runs); above the max is a 422, never clamped
Fields per write 1–200 keys per PATCH /v1/runs/{id}/fields / fields at start
Field value strings ≤ 10,000 characters; arrays ≤ 200 items of ≤ 200 characters; numbers finite
Run name 1–300 characters
Labels per run 50 ids
Approval comment 5,000 characters
Idempotency-Key 1–255 printable ASCII characters; stored 24 h; responses over 262,144 bytes are not stored (a retry re-executes)
X-Request-Id echoed when 1–128 printable ASCII characters; else server-minted req_<uuid>
API key name 80 characters
Key rotation grace 24 h (the previous secret keeps working)
Allowlist per key up to 200 workflow ids and 200 folder ids
File upload 25 MB per file; the upload URL is valid 2 hours; download URLs 1 hour
Webhook URL / description 2048 / 200 characters; https only
Webhook timeout 10 s per attempt
Webhook retries 1 / 5 / 15 / 30 / 60 minutes after a failure (6 attempts), then exhausted
Webhook auto-disable after 5 consecutive exhausted deliveries, or one 410
Webhook secret rotation grace 24 h (both secrets sign)
Webhook timestamp tolerance 300 s (reject older or newer deliveries as replays)
Delivery log retention 30 days
Events per subscription any number of types, or *
Schedules 200 per workspace; times on 5-minute steps — runs are created at the scheduled time, usually within a minute
Schedule name / run-name pattern 120 / 300 characters; the run name it renders is cut to 200
Schedule presets / assignment overrides 50 preset fields; 30 overridden tasks, each with 1–20 assignees
Schedule start failures paused (failed) after 3 in a row; a database outage is retried and never counts
Automation rules that are on 100 per workspace
Rule name / actions / conditions 120 characters; up to 10 actions and 10 conditions per rule
Rule assign_task / notify 20 assignees; 20 recipients and a 500-character message
Rule auto-disable after 10 consecutive failed executions
Rule loop guard 20 executions of one rule on one run in any 60 minutes
Rule execution log retention 30 days

Webhook retry schedule

  • First attempt immediately; after a failure, retries at 1 min → 5 min → 15 min → 30 min → 60 min after the previous attempt — 6 attempts in all over about 1 h 51 min; then the delivery is exhausted.
  • Per-attempt timeout 10 seconds; any 2xx counts as delivered, anything else (or a timeout, or a refused connection) as a failed attempt.
  • A 410 Gone disables the endpoint at once (disabledReason: "gone"); 5 consecutive exhausted deliveries disable it ("failures"). Either way the workspace's Builders and Admins are notified; enable it again from Automations → Webhooks or POST /v1/webhooks/{id}/enable.
  • Deliveries are kept 30 days.