Billing and Usage

See what consumes quota, when a plan change takes effect, and how the Sandbox fallback operates.

7 min read

Use this guide to read the plan limits and the usage.

Plans and the Team trial#

Every new organization starts with a 14-day Team trial. You do not need a card. The trial uses the Team limits and the Team features, with the team organizations and the advanced retry policies. When the trial ends, the organization stays active on Sandbox, until you subscribe.

Display plan	API tier	Price	Accepted events each month	Active endpoints	Enabled destinations for each endpoint	Retry cap	Members	Maximum payload	Requests each minute
Sandbox	`FREE`	$0	250	1	2	1	1	256 KB	30
Team trial	`TRIAL`	14 days	10,000	5	5	5	5	512 KB	600
Solo	`BASIC`	$9/month or $90/year	1,000	1	3	3	1	256 KB	60
Team	`PRO`	$49/month or $490/year	10,000	5	5	5	5	512 KB	600
Scale	`ULTIMATE`	$199/month or $1,990/year	100,000	50	10	5	Unlimited	1 MB	3,000

Some organizations use a custom plan. The agreement of the organization sets the limits and the available features of a custom plan. For a question about a custom plan, contact Support.

Each plan supports every destination type and the failover. Sandbox and Solo use the standard retry schedule. On the Team trial, Team, Scale, and an eligible custom plan, you can select an aggressive schedule or a conservative schedule, and custom retry status codes.

What counts toward usage#

One accepted webhook event or email event consumes one event from the monthly allowance of the organization.
The destination fan-out, the failover, the delivery attempts, and the retries consume no more event quota.
A request that PayloadRelay rejects before the acceptance, such as an authentication error or a validation error, consumes no quota.
An event that receives a temporary 503 before the acceptance consumes no quota. Wait for Retry-After when that header is present, then send the original request again.
The quotas reset on the first day of each calendar month (UTC).
If the quota alerts are enabled, PayloadRelay sends them at 80% and at 100%. The notification delivery is at-least-once, and an alert can arrive more than one time.
An accepted-event quota is a hard limit. There is no metered overage billing.

A public relay response does not show the plan, the allowance, the usage, the reset date, the billing state, or other account metadata. A public Retry-After value is an operational retry hint. It is not the quota reset window of the organization. To see the current allowance and usage, sign in and use Billing, or use the authenticated GET /billing/usage API.

The requests-per-minute limit and the monthly accepted-event billing are different.

Destination limits#

The destination limit applies to each endpoint. It counts only the enabled destinations that are not failover destinations. A disabled destination configuration and a failover row do not count against the limit. If a downgrade makes the limit lower, PayloadRelay keeps the oldest permitted destinations enabled, and it keeps the later destination configurations disabled.

If you try to enable more destinations than this limit, PayloadRelay returns HTTP 402 with OUTPUT_LIMIT_REACHED. An advanced retry configuration on a plan that is not eligible returns 402 with ADVANCED_RETRY_POLICY_REQUIRED.

When you select a paid plan, PayloadRelay compares the organization with the plan. If Solo must change the organization, Billing lists each necessary change before Stripe Checkout opens. These changes can include disabled trial endpoints, disabled destinations, a lower retry configuration, and members that become inactive. Billing also reports an accepted-event usage that is above the allowance. You must acknowledge the list before the checkout. No resource changes occur until the payment succeeds.

Team and Scale usually continue directly to Checkout, because their limits are equal to the Team trial limits or higher. A Checkout preview expires after 15 minutes. If the organization changes before Checkout starts, PayloadRelay asks for a new review.

Change a paid plan#

When you select a plan, PayloadRelay creates a 15-minute preview. Read the amount due, the proration credit, the estimated tax, the recurring USD price, and the renewal date. Before you approve the change, read the effect on the accepted events, the endpoints, the destinations, and the members.

An upgrade and a monthly-to-annual change apply after the payment confirmation from Stripe.
A downgrade and an annual-to-monthly change apply at the end of the current period.
A scheduled downgrade preview identifies the endpoints and the destinations that PayloadRelay disables, the destinations with a lower retry configuration, and the members that become inactive.
When PayloadRelay applies the limits, it keeps the oldest permitted endpoints and destinations. It also keeps the organization owner and the oldest permitted members.
You cannot change the plan while a cancellation is scheduled. Resume the renewal before you create a new preview.

Payment recovery#

Checkout and an immediate upgrade can show Processing or Payment required. The paid features and limits do not change until Stripe completes the payment confirmation. A recurring payment that fails starts a recovery period. The access stays available in that period. If the payment does not succeed before the deadline, PayloadRelay pauses the relay delivery and the configuration changes until you correct the billing.

An invoice finalization problem alone does not end an active subscription. If the billing changes are not available, or if an invoice problem continues, contact Support.

Cancel, resume, and view invoices#

A cancellation stops the renewal at the end of the paid period. The paid features stay available to that date. The organization then moves to an active Sandbox plan with a new 250-event allowance. The invoice history stays available after the cancellation.

The cancellation fallback also does these actions:

It keeps the oldest permitted endpoints and members active.
It disables the extra destinations. It does not delete their configuration.
It lowers the retries and the advanced retry configuration to the Sandbox limits.

To keep the renewal active, select Resume subscription before the paid period ends. The Stripe portal stays available for the payment methods, the tax details, and the invoice history.

Activity retention and privacy#

PayloadRelay keeps a metadata-only Activity trail and the delivery outcomes for 30 days. PayloadRelay does not store a customer relay request body or a customer message body in its databases, activity logs, object storage, or backups. A body stays only in memory and in the delivery, retry, and dead-letter queues. It stays there only while PayloadRelay delivers the event. If the delivery fails permanently, the message stays in a dead-letter queue for a maximum of 7 days for diagnosis or a new delivery. PayloadRelay can keep operational metadata, such as an SMTP envelope sender address, in the 30-day Activity trail.

The stored endpoint templates, the destination configuration, and the billing records are separate from the customer relay-event bodies.

Common issues#

The usage data is old: select Refresh usage, and examine it again after a short delay.
The remaining events are wrong: make sure that the calendar-month window and the accepted traffic are correct.
You cannot enable a destination: disable a different enabled primary destination, or upgrade to a plan with a higher destination limit.
An advanced retry control is not available: you need the Team trial, Team, Scale, or an eligible custom plan.
The payment is still in progress: continue the open Checkout, or wait for Stripe to complete the payment. Do not create a second subscription.
You need billing help: open Support with the organization, the time period, and the related Stripe invoice references and customer references.

← Back to documentation