A short status update and a detailed order payload each count as one webhook. Yet one might carry a hundred times more data than the other. That makes request count alone a limited way to describe how much an integration uses.
On September 25, 2026, we switched Adal Cloud from credits to byte-based billing. Usage now reflects the exact size of the data we accept, with no rounding up to blocks and no minimum usage charge per request. Delivery retries remain free.
The aim is to make usage easier to understand and estimate. You can work directly with the size of your requests, using the accounting rules below.
Requests, credits, or bytes?
The unit a service uses for billing determines what you need to know to estimate your usage. Each approach comes with its own tradeoffs.
| Model | What makes it useful | What to keep in mind |
|---|---|---|
| Request count | A steady event rate makes the required allowance easy to estimate | Small and large requests count equally unless separate size rules apply |
| Credits | Different operations can share a common unit | You need to know the credit cost of each operation and how size affects it |
| Data volume rounded up to blocks | Usage takes request size into account | A small increase across a block boundary can cause a jump in recorded usage |
| Exact bytes, as now used by Adal Cloud | Usage maps directly to the size of accepted data | Estimates need both request count and average accounted size |
Credits don’t necessarily involve rounding; that depends on the service’s rules. They do, however, introduce a conversion between the data you send and the allowance you have left. We’ve removed that step from Adal Cloud’s usage accounting.
Consider a hypothetical service that rounds each request up to the next 64 KiB block. A 65,536-byte request uses one block. Add a single byte, and it uses two. With Adal Cloud’s new model, those two requests differ by exactly one byte of usage. This illustrates how rounding works; it isn’t a price comparison between services.
What counts toward request size
For incoming webhooks, we count the path and query string, the user-supplied headers we retain, and the request body. For Adal Outbound, we count the full destination URL, user-supplied headers, and the body after Base64 decoding.
That means the accounted size includes more than the JSON payload alone. A header containing the sender’s signature, for example, also contributes to the total. Base64 encoding adds no extra body usage in Outbound: we count the decoded bytes.
Adal Cloud’s internal metadata, transport overhead, and the recipient’s response are excluded. Text is measured by its encoded size in bytes, rather than by character count.
Usage is recorded once, when a new incoming Request is successfully saved or an Adal Outbound message is accepted. The subsequent delivery outcome doesn’t change that recorded amount.
Small webhooks use a small share of your allowance
Suppose two integrations each send 1,000 requests. In the first, each request has an accounted size of 1 KiB. In the second, it’s 100 KiB. They use approximately 0.98 MiB and 97.66 MiB, respectively.
The event counts are identical, but the data volumes differ by a factor of 100. Byte-based accounting preserves that difference: a small notification uses an amount proportional to its size.
For a rough estimate, you can use:
Usage per period ≈ number of new requests × average accounted size
For example, 500 MiB covers 102,400 requests of 5 KiB each, provided those 5 KiB include every part counted toward usage and nothing else consumes the allowance. That’s an example calculation, not a fixed webhook limit for the plan. Real requests vary in size.
This gives you a practical way to choose a plan using your own integration data. Small events don’t each consume a minimum block, and larger payloads increase usage byte by byte.
Retries don’t add to your usage
A recipient may be temporarily unavailable, return an error, or fail to respond before a timeout. A retry gives an already accepted event another chance to reach its destination.
In Adal Cloud, automatic retries and manual retries of an existing delivery use no additional allowance. A request recorded as 5 KiB still accounts for 5 KiB after several delivery attempts, rather than growing to 15 or 25 KiB. Forwarding the same incoming Request to multiple Destinations doesn’t multiply its accounted size either.
Replay is different: it creates a new Request from a saved original. That new Request counts separately, using the original’s size. The distinction matters when debugging: a retry repeats an existing delivery, while Replay starts processing a new Request.
If an external service sends the webhook again, that submission can also create a new Request. Free retries apply to delivery attempts within Adal Cloud; identical content alone doesn’t make a new submission free.
One allowance for incoming and outgoing requests
Your allowance is shared across the Servers and flows in your account, including Adal Outbound. You don’t need to allocate portions of it to individual Servers or regions in advance.
At launch, the plans include these amounts per subscription period:
| Plan | Included data |
|---|---|
| Free | 10 MiB |
| Developer | 500 MiB |
| Startup | 2 GiB |
We use binary units: 1 KiB is 1,024 bytes, 1 MiB is 1,048,576 bytes, and 1 GiB is 1,073,741,824 bytes. Usage itself is tracked to the exact byte.
Renewing a subscription provides a fresh full allowance; unused data doesn’t roll over. When you upgrade to a higher plan, your remaining allowance carries over once.
The allowance measures data accepted during the period. Deleting a request body when its retention period ends doesn’t restore that allowance, and neither does a failed delivery.
How the limits work
The maximum accounted size of a single request is 10 MiB for both incoming webhooks and Adal Outbound, on every plan. This technical limit is separate from the total subscription allowance.
The allowance is a soft limit. If a region’s current usage information shows a positive balance, it can accept a whole request even if that request is larger than the remaining balance. Usage updates also take time to synchronize across regions, so total usage can exceed the allowance, including when requests arrive concurrently.
Once a region sees that the allowance is exhausted, it rejects new incoming requests with HTTP 429 and new Adal Outbound messages with HTTP 402. The soft limit lets a whole request be accepted against a positive balance; it doesn’t provide unlimited acceptance after the allowance runs out.
What this means for existing users
The switch is complete. Accounts, subscriptions, Servers, Destinations, and data still within their retention periods have been preserved. Previous credit usage wasn’t converted into bytes: existing subscriptions started the new accounting system with zero recorded byte usage.
You can now estimate your needs and track consumption in the same units. Small requests use a small share of your allowance, payload growth is reflected without jumps caused by rounding, and retries remain available to recover from delivery failures without adding to usage.
Open the Adal Cloud dashboard to check your subscription’s available allowance. Compare it with your event volume and average request size to find the plan that fits your integration.