Webhook trigger rate limits

Rate limiting is a technique to control the number of requests a user or application can make to a service within a specific time frame. It's used to prevent system overload, ensure fair usage, and protect against attacks like DDoS or scraping by temporarily slowing or rejecting requests that exceed predefined limits.

Rewst will enable rate limits for our webhook triggers on February 18, 2026. Existing customers should see the section Existing customer rate limit transition for instructions on how to prepare.

To ensure platform reliability and consistent performance for the entire platform, Rewst applies rate limits to inbound webhook triggers.

Current limits per trigger

50 requests per second
1000 requests per minute

These limits apply individually to each webhook trigger, not to your organization as a whole. Our integrations operate well within these thresholds under normal conditions.

The rate limit occurs at ingest rather than after trigger criteria are considered.

Common causes of rate limit errors

Misconfigured integrations sending duplicate events
Bulk operations triggering large volumes of webhooks simultaneously
Retry storms from upstream services

Response when limit is exceeded

If your webhook traffic exceeds our limits, Rewst will respond with an HTTP 429 Too Many Requests status code. This is a standard response that signals the sending service to slow down and retry, and is displayed in the header of the webhook response.

As webhook requests originate from external platforms, Rewst can't retry the request on your behalf. The event is lost once it's rejected, unless the external platform is configured to retry on 429 responses. Most well-designed webhook senders will automatically back-off and retry when they receive a 429 response. WHRL However, note that Rewst has built integrations with MSP-requested tools, and not all tools have 429 responses built in yet.

Example response

Below is an example of the 429 response Rewst sends back to the involved partner app when your trigger is rate limited. Use this table to reference its meaning.

{
  "data": "",
  "status_code": 429,
  "headers": {
    "Date": "Fri, 23 Jan 2026 06:01:50 GMT",
    "Content-Length": "0",
    "Connection": "keep-alive",
    "x-envoy-ratelimited": "true",
    "x-ratelimit-remaining": "0",
    "x-ratelimit-reset": "10",
    "Retry-After": "10",
    "strict-transport-security": "max-age=15552000; includeSubDomains",
    "Server": "istio-envoy"
  },
  "cookies": {}
}

Item Key

Example Value

Meaning

HTTP status code - status

429

Too Many Requests — rate limit exceeded.

Envoy rate limited - x-envoy-ratelimited

true

Request was blocked by Envoy due to rate limiting.

Retry after - retry-after / x-ratelimit-reset

10

Wait 10 seconds before retrying the request.

How to resolve and prevent rate limit issues

Naive immediate retries will cause loops and continued rate limiting.

Review your integration configuration to ensure that events aren't being sent multiple times.
Verify that upstream services are correctly handling 429 responses and implementing back-off.
If you're performing bulk operations, consider spacing them out over time.
Add delays or exponential back-off before retrying.
Filter events before sending requests. Configure the source system to only emit webhook events that are actually needed: limit event types, scopes, objects, environments, etc.
If supported, batch or consolidate events. Prefer sending fewer webhook requests that contain multiple changes or events, or use built-in batching aggregation options on the source platform to reduce request volume.
Contact Rewst support if you need further guidance on how to prevent rate limiting.

Existing customer rate limit transition

Rewst recommends evaluating your applications that send automated HTTP requests to Rewst before the transition date to ensure your webhook triggers are not exceeding the fair use limits put in place.

Supplemental partner documentation

Below are links to related documentation from some of the apps Rewst integrates with, which may help you in ensuring that your webhook triggers are within limit. Partner documentation may require logging in to that partner app to view content.

Receive change notifications through webhooks – Microsoft Graph: This is Microsoft’s direct documentation of webhook delivery semantics for Graph.

Webhooks error handling - Autotask Official Documentation: This contains an authoritative description of Autotask webhook retry behavior.

ConnectWise developer guide: This contains ConnectWise's documentation on how their product handles retries.

Webhook integration triggers reference table

integration_name

trigger_name

description

Autotask PSA

Company Webhook