Webhook Quotas: Keep Signed Capacity Separate?

This calculator helps you decide whether to keep signed webhook capacity separate from other API quotas by modeling the math behind shared vs. dedicated capacity. You enter your total webhook volume, the percentage that is signed (e.g., authenticated via HMAC or JWT), and the burst size you need to handle; the calculator returns the minimum separate quota required to avoid throttling signed traffic, plus the utilization of that dedicated capacity. The result is a concrete number you can take to your API vendor or use in your own capacity planning.

Formula

The calculator uses two simple formulas. First, the average signed webhook rate per hour is:

Signed rate = Total volume × (Signed share / 100)

Then the minimum separate quota is the larger of two values: the average signed rate and the burst capacity you need (burst per minute × 60 to convert to hourly). In symbols:

Minimum quota = max(Total × share%, Burst × 60)

Where:

• Total volume – total webhooks delivered per hour (webhooks/h)
• Signed share – percentage of webhooks that are signed (0–100)
• Burst – maximum signed webhooks you need to handle in a single minute (webhooks/min)
• Minimum quota – the hourly quota that guarantees signed webhooks never wait (webhooks/h)
• Utilization – what percentage of that quota you actually use on average (%)

Worked Example

Using the default values: total volume = 1000 webhooks/h, signed share = 20%, burst = 50 webhooks/min.

1. Average signed rate = 1000 × 20 / 100 = 200 webhooks/h.
2. Burst capacity needed = 50 × 60 = 3000 webhooks/h.
3. Minimum quota = max(200, 3000) = 3000 webhooks/h.
4. Utilization = 200 / 3000 × 100 = 6.67%.

The calculator shows a minimum separate quota of 3000 webhooks/h, with 6.67% utilization. That low utilization is normal – separate quotas are sized for peaks, not averages.

Why Separate Quotas Matter for Signed Webhooks

Signed webhooks (those carrying an HMAC signature, JWT, or similar authentication) are typically more sensitive than unsigned ones. If an attacker can flood your unsigned webhook endpoint, they can also exhaust your shared quota, causing signed webhooks to be throttled or dropped. That could mean missed payment notifications, failed CI/CD triggers, or unprocessed security alerts. Keeping signed capacity separate ensures that a burst of unsigned traffic cannot starve the authenticated, high-priority webhooks.

Many API providers offer quota tiers – e.g., a shared pool for all webhooks and an optional dedicated pool for signed/authenticated traffic. The decision to pay for that separation is a risk/cost tradeoff. The calculator helps you quantify the minimum dedicated capacity you need, so you don’t overpay for unused headroom.

How Quotas Are Typically Enforced

Webhook quotas are usually enforced per endpoint, per account, or per API key. They can be:

• Rate limits – maximum requests per second/minute/hour.
• Daily/monthly caps – total deliveries per billing cycle.
• Concurrency limits – simultaneous in-flight deliveries.

When a quota is shared, all webhooks (signed and unsigned) draw from the same bucket. When separate, each type has its own bucket. The enforcement is often a token bucket or leaky bucket algorithm. Understanding which model your provider uses is essential – if they only offer a daily cap, a separate quota might be expressed as a sub-limit on signed deliveries.

How to Choose: Shared vs. Separate

Consider these factors when deciding:

• Criticality – if signed webhooks trigger payments, security alerts, or data sync, they deserve isolation.
• Traffic pattern – if unsigned traffic is bursty (e.g., marketing events) and signed traffic is steady, separation prevents interference.
• Cost – separate quotas often cost extra. Calculate the utilization; if it’s below 10%, you might be paying for unused capacity.
• Failure tolerance – can you afford to lose signed webhooks during a spike? If not, separate.
• Compliance – some regulations require authenticated delivery to be reliable; separate quotas help demonstrate that.

As a rule of thumb, if signed webhooks are less than 5% of your volume and you can tolerate occasional loss, shared is fine. If they are mission-critical, separate is safer.

Common Mistakes and Misconceptions

A frequent mistake is sizing the separate quota based on average volume, not burst. The calculator uses the max of average and burst to avoid that. Another error is forgetting that burst per minute must be converted to hourly for comparison – using 50 instead of 3000 would give a quota too small by a factor of 60.

Another misconception: “signed” means the webhook is secure. Signing only verifies authenticity; it does not protect against quota exhaustion. Also, some assume that a separate quota automatically guarantees delivery – it only guarantees that the request is accepted, not that your endpoint processes it successfully.

Alternatives to Separate Quotas

If separate quotas are too expensive or not offered, consider:

• Prioritization – some providers allow you to set priority levels on endpoints; signed webhooks get higher priority.
• Queueing – implement your own queue for signed webhooks, so they are processed even if the provider throttles.
• Redundancy – use a second provider or a fallback endpoint for signed webhooks.
• Client-side retries – with exponential backoff, a throttled signed webhook can be retried later.

These alternatives add complexity but can be cheaper than paying for dedicated capacity.

Cost and Safety Considerations

Separate quotas typically cost more, but the price is often based on the quota size, not utilization. The calculator shows utilization; if it’s very low, you might negotiate a smaller quota or use a pay-as-you-go model. Safety-wise, ensure that your quota limits are monitored – set alerts for when utilization exceeds 80%, so you can scale up before a drop.

Also, consider the security of your signing mechanism. A separate quota doesn’t protect against compromised keys; rotate keys regularly and use a strong HMAC algorithm.

Frequently Asked Questions

Q: What is a signed webhook?
A: A webhook that includes a cryptographic signature (like HMAC-SHA256) in its headers or body, allowing the receiver to verify that it came from the expected sender and wasn’t tampered with.

Q: Can I use the same quota for signed and unsigned webhooks?
A: Yes, but that means a burst of unsigned traffic can block signed ones. If signed webhooks are critical, separate quotas are safer.

Q: How do I know if my provider supports separate quotas?
A: Check the documentation for “dedicated quota,” “separate rate limit,” or “per-endpoint limits.” If not listed, contact support.

Q: What happens if I exceed the separate quota?
A: The provider will typically reject the webhook with a 429 status or queue it if you have retries configured. You might lose the event if retries are exhausted.

Q: Is a separate quota worth the cost?
A: It depends on the criticality and traffic pattern. Use the calculator to see utilization; if it’s above 50%, it’s likely worth it. If below 10%, consider alternatives.

Q: Can I calculate the quota for multiple endpoints?
A: Yes, sum the volume and burst for all signed endpoints, then use the calculator with the combined numbers.

Related

• How to Add Conditional Formatting Rules in Excel
• Monitor Regulatory Websites for Changes
• Cassette Beast Codes: Mailbox Codes Worth Trying

in t | Total webhook volume (per hour) | webhooks/h | 1000 | 0
in p | Signed webhook share | % | 20 | 0
in b | Max burst size (signed, per minute) | webhooks | 50 | 0
out min_q | Minimum separate quota (per hour) | webhooks/h | max(b * 60, t * p / 100) | 0
out util | Utilization of that quota | % | (t * p / 100) / min_q * 100 | 0