# Webhook Gateway Limits

Whenever you use a real-time trigger, our webhooks connector or build a webhook trigger on the connector SDK, your events are sent to our webhooks gateway before being turned into jobs. Workato's webhook gateway has 2 limits that apply on the entire Workspace level:

Rate limits - How many events can you send in a specific time interval
Byte limits - How much cumulative memeory can your webhook events contain in a specific time interval

WARNING

These limits apply across all your real-time triggers in your workspace and consume the same allowance of both your rate and byte limits.

# Rate limits

Our webhook gateway has the following rate limits:

1,200 events per minute (20 request per second)
18,000 events in a burst

You may imagine your rate limit in this way:

You receive 20 credits per second to accept events in the webhook gateway
Whatever events you receive in that second will use up the 20 credits you have been allocated.
Any excess credits that are unused in that second will be added into your burst allowance which has a max amount of 18,000.
If, in any second, you receive more than 20 events, the events are accepted by drawing credits from your store of 18,000
If you have no credits left in that second and burst allowance, the webhook gateway will respond with a 429 response.

# Scenario 1

In a single second, if you receive 18,020 events, all events will be accepted but your burst allowance would be depleted. If you receive no events afterwards, your burst allowance will be refilled in 15 minutes

# Scenario 2

In a single second, if you receive 18,020 events, all events will be accepted but your burst allowance would be depleted. If you receive 20 events per second for every second afterwards, your burst allowance will not be refilled until your steady rate of events falls below 20 events per second

# Handling situations when your Rate limits are exceeded

When you exceed your rate limits, Workato's webhook gateway responds with 429 errors. In addition to this, Workato's webhook gateway responds to every event with 3 headers that help you understand when you can successfully send your next event.

Retry-After - How many seconds to retry the webhook before it will be accepted
X-Rate-Limit-Remaining - How many events that can be sent before 429s will be returned
X-Rate-Limit-Reset - How many seconds before your event burst allowance is refilled

Your API can use these headers to understand how and when to throttle webhook events.

# Byte limits

Our webhook gateway has the following byte limits, which represents the total memory in all your webhooks:

30MB per minute
30MB in a burst

You can imagine the byte limits per minute and burst in the same way as the rate limits.

# Scenario 1

In a single minute, if you receive 60MB across all your events events, all events will be accepted but your memory allowance would be depleted. If you receive no events afterwards, your memory allowance will be refilled in 1 minute.

# Scenario 2

In a single minute, if you receive 60MB across all your events events, all events will be accepted but your memory allowance would be depleted. If you receive 30MB across all events per minute for every minutes afterwards, your memory allowance will not be refilled.

# Handling situations when your Byte limits are exceeded

Retry-After - How many seconds to retry the same webhook before it will be accepted
X-Byte-Limit-Remaining - How much culmilative data across all webhooks that can be sent before 429s will be returned
X-Byte-Limit-Reset - How many seconds before your Byte burst allowance is refilled

Your API can use these headers to understand how and when to throttle webhook events.