Organization 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.

To ensure platform reliability and consistent performance for the entire platform, Rewst applies rate limits to inbound webhook traffic at the organization level.

Rate limits per organization

Limits apply per organization, across all of the org’s webhook triggers and managed
subscriptions— for example, Microsoft Graph. There’s no per-trigger or per-second limit.
The limit is set by your organization’s plan and is measured over a fixed 60-second
window. Specific limits depend on your plan.

Every request to a valid trigger counts against your organization’s limit, including requests that are later rejected, filtered out by trigger criteria, or deduplicated. Accepted requests receive an HTTP 202 response; requests filtered out by trigger criteria receive an HTTP 200. Result-polling requests draw from a separate limit, so polling for results doesn’t use up your delivery budget.

Microsoft Graph notification limits

Microsoft Graph subscriptions accept at most 200 notifications per request. Notifications beyond that limit are dropped, and the request still counts once against your organization’s rate limit.

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. The response includes a Retry-After header indicating how many seconds to wait before your organization’s rate-limit window resets, along with a JSON body describing the error. This response does not include X-RateLimit-* headers.

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 organization 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

Retry after - retry-after

10

Wait 10 seconds before retrying the request

Retry after (body) - retryAfter

10

Same wait time as the Retry-After header,

included in the JSON response body

Synchronous responses

If a webhook trigger is configured with rewst_respond=sync or rewst_respond=hold, Rewst holds the connection open and waits for a synchronous result for up to 5 minutes. If a result isn’t ready within that window, Rewst falls back to an HTTP 202 response that includes a statusUrl you can poll for the result.

Each organization can hold at most 32 synchronous connections at a time. Once that limit is reached, additional synchronous requests receive an immediate 202 response instead of waiting. Responses larger than 5 MiB are never returned synchronously; those always come back with a statusUrl instead. Results are retained for 24 hours.

Deduplication

To deduplicate webhook requests, include an X-Idempotency-Key header with a unique value for each logical event. Rewst retains idempotency keys for 24 hours.

How to resolve and prevent rate limit issues

Naive immediate retries will cause loops and continued rate limiting. Because the limit is shared across all of an org’s webhook triggers, one noisy integration can throttle every webhook for that organization.

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.

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