# Limits and schedules

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

Source: https://developers.processcart.com/reference/limits

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.