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:

1. Rate limits - How many events can you send in a specific time interval
2. Byte limits - How much cumulative memory 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

Rate limits are applied on a workspace environment. If your workspace have multiple environments (i.e. DEV, TEST, PROD), each environment has its own individual rate limits as dictated below. For workspaces without environments, you have a single rate limit.

Our webhook gateway has the following rate limits:

1. 72,000 events per hour
2. 18,000 events in a burst

Our webhook gateway follows a leaky bucket approach with the following mechanics:

• You start with a burst allowance of 18,000 events.
• The allowance of 72,000 events per hour are amortized to 20 events every second.
• Events you receive in each second will use up the 20 events allowance you have been allocated.
  • If you receive more than 20 events in a second, you will start to consume your burst allowance.
  • If you receive less than 20 events in a second, the excess will be added to your burst allowance.
  • Your burst allowance cannot exceed 18,000 events.
• If you have no quota left in that second and in your burst allowance, the webhook gateway will respond with a 429 response.

HANDLING 429 RESPONSES

429 requests are meant to preserve the stability of our webhook gateway for all customers. Industry best practices for 429s are to retry webhooks until they are eventually accepted. In high volume scenarios, webhook gateway limits may be adjusted on a per-customer basis and subject to commercial terms and approval.

Learn more about handling 429 responses.

Lets go over some examples to highlight

Example 1

In a single second, if you receive 18,020 events, all events will be accepted but your burst allowance would be depleted. In the next second, you can receive another 20 events that will be accepted before we respond with 429 responses.

Example 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

---

Byte limits

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

1. 30MB per minute
2. 30MB in a burst

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

HANDLING 429 RESPONSES

429 requests are meant to preserve the stability of our webhook gateway for all customers. Industry best practices for 429s are to retry webhooks until they are eventually accepted. In high volume scenarios, webhook gateway limits may be adjusted on a per-customer basis and subject to commercial terms and approval.

Learn more about handling 429 responses.

---

Additional information for embedded partners

For Embedded Partners using our shared connectors feature to distribute connectors to their customers, static webhook triggers in your customer workspaces have their own separate webhook rate limits. For example, webhook events to Customer A's workspace will not be counted to Customer B's workspace webhook rate limits.

---

Handling situations when your Webhook Gateway 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 5 headers that help you understand when you can successfully send your next event.

• Retry-After - How many seconds to retry the same 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
• X-Byte-Limit-Remaining - How much cumulative data across all webhooks that can be sent before 429s are 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.