FlowRelay
Operate
Usage limits
Use this page to choose a plan, prepare setup or migration volume, and understand what happens when FlowRelay reaches a usage boundary.
On this page
Quick answer #
FlowRelay responds differently depending on what ran out. If your plan's event capacity is used up, new events get a 402 Payment Required response — nothing is billed silently; you choose whether to upgrade, wait for the next period, or request approved custom capacity. If an automated client is looping too fast, or the traffic is invalid, the response is 429 Too Many Requests with guidance on when to retry. Normal signed events from your senders are stored durably on arrival while capacity remains, and FlowRelay paces the Shopify Flow handoff from there.
| Situation | Response | What to do |
|---|---|---|
| Event capacity is exhausted. | 402 | Upgrade, wait for the next period, or ask FlowRelay about approved custom capacity. |
| Paid-plan event grace is exhausted. | 402 | Approve more capacity before sending more production traffic. |
| An agent, sender, or client is looping too quickly. | 429 | Obey Retry-After, narrow the request, and avoid tight retry loops. |
| A sender sends valid signed events while capacity remains. | Accepted durably | Let FlowRelay buffer intake and pace downstream Shopify Flow handoff. |
| Agent or recovery usage is unusually heavy. | Fair-use review | Use compact reads first, check plan-usage, and ask support before migration or backfill windows. |
Plan capacity #
These are the public plan limits most merchants compare first: event intake, recovery tools, Agent Access posture, and retained event history.
| Plan | Accepted events | Diagnostics shares | Replay executions | Agent Access | Event history |
|---|---|---|---|---|---|
| Free/Test | 500 | 25 | 25 | Included safeguards | 30 days |
| Starter | 25,000 | 1,000 | 500 | Included safeguards | 30 days |
| Growth | 250,000 | 10,000 | 5,000 | Included safeguards | 30 days |
| Scale | 1,000,000 | 50,000 | 25,000 | Expanded safeguards | 30 days |
Paid-plan event grace #
Starter, Growth, and Scale include bounded event-intake grace after the included accepted-event cap is reached. Events accepted during grace are still stored, metered, and handed off normally when the receipt path succeeds. FlowRelay does not create silent overage charges; more capacity requires an explicit upgrade, approved add-on, or custom-capacity approval.
What counts against usage #
The embedded Plan page and Agent Operations plan-usage response show current usage and enforcement state. Use them for capacity planning, monitoring cadence, and setup or recovery work.
| Usage | What counts | How it is limited |
|---|---|---|
| Accepted events | Inbound events accepted by FlowRelay for processing during the plan period. | Plan capacity. Paid plans include bounded event-intake grace after the included cap. |
| Diagnostics shares | Private, redacted diagnostics shares created for support, a partner, or an authorized agent. | Included recovery-tool allowance plus fair-use review. |
| Replay executions | Intentional reruns of retained events. Replay can repeat downstream actions. | Included recovery-tool allowance plus fair-use review. |
| Agent Operations reads | Compact setup and plan checks plus richer event, endpoint, diagnostics, reliability, or history reads. | Short-window rate limits, scoped grants, and sustained fair-use review. |
| Action previews | Preview or proposal records for approved actions before anything changes. | Short-window rate limits, confirmation, idempotency, audit, and sustained fair-use review. |
| Executed actions | Confirmed approved actions such as diagnostics-share creation, endpoint tests, endpoint changes, or secret rotation. | Short-window rate limits, confirmation, idempotency, audit, and sustained fair-use review. |
Operational safeguards #
Usage limits are not just plan counters. FlowRelay also protects operators from unsafe loops, repeated recovery actions, and bad traffic. Exact 429 response details live in the Agent and API rate limits guide.
- Agent and API rate limitsSee exact 429 response fields, retry behavior, and machine-readable rate-limit classes.
| Situation | How FlowRelay handles it |
|---|---|
| Valid signed event intake | Eligible events are accepted durably while plan capacity remains, then FlowRelay paces downstream Shopify Flow handoff. |
| Agent and API work | Automated reads, previews, and approved actions use short-window rate limits so agents can avoid tight loops and unsafe repetition. |
| Recovery work | Replay, diagnostics, endpoint changes, and secret rotation stay preview-first, explicit, auditable, and paced. |
| Invalid or malformed traffic | Bad endpoint URLs, failed authentication, and malformed payloads can receive 429 responses before they burn event capacity. |
Recovery visibility at limits #
Existing event history, receipts, error context, diagnostics, replay history, and recovery guidance stay visible when a limit is reached or event intake is in grace. The operator can still decide whether to upgrade, request custom capacity, wait for the next period, or reduce limit-consuming work.
What usage limits do not change #
Usage limits do not create configurable retry schedules, custom endpoint-level throttling, user-managed queue buffering, a default sender-facing throttle for valid signed event bursts, or general webhook traffic management.
Operating guidance
Apply the concept through the receipt before changing setup, resending, or replaying.
-
Treat a 402 Payment Required response as a capacity stop: upgrade, wait for the next period, or ask about approved custom capacity.
-
Use plan-usage before broad agent reads, repeated action previews, migration work, or high-volume recovery.
-
Valid signed events are stored durably on arrival while event capacity remains; FlowRelay then paces the Shopify Flow handoff.
-
Use the Agent and API rate limits guide when an agent, CLI, MCP client, API client, or sender receives 429.