Skip to main content
MoEngage enforces rate limits on its REST APIs to keep the shared platform fast and reliable for every customer. Limits apply per workspace unless a specific endpoint states otherwise (some are per client or per consumer), and a request that exceeds its limit is rejected with an HTTP 429 Too Many Requests response. Most limits below are the defaults. Several limits can be raised for your workspace based on genuine need — contact your MoEngage Customer Success Manager (CSM) or the Support team to discuss an increase.
Rate limits and payload caps are two separate controls. A request can be within the rate limit but still be rejected for exceeding the payload size, or vice versa. Each endpoint’s own reference page carries its authoritative limit; the tables below summarize them.

Rate limits by endpoint

Endpoints are grouped by product area to match the API reference navigation. When several endpoints share a single pool, the limit is applied across all of them.

Data

File imports

Business Events

Templates and content

Recommendations

Coupons

Catalog

Flows

Offerings

Campaigns (V5)

Campaigns (Legacy)

Campaign report and stats

Segments

A workspace can have up to 1,000 active segments at a time (file, filter, and custom combined).

Subscriptions

Push

Cards

Inform

Live Activities

Personalize

Message Archival

Payload size limits

Payload caps are enforced independently of rate limits. A request larger than the cap is rejected — typically with HTTP 413 (payload too large) or HTTP 400, depending on the endpoint.

Monitor your usage

Rate-limited endpoints return the following headers on every response, so your integration can track remaining capacity in real time rather than waiting for a 429:
A few high-throughput endpoints (such as the Push API) signal throttling with an x-envoy-ratelimited: true header instead. Check the specific endpoint’s reference page for the headers it returns.

When you hit a limit

When a request is rejected with HTTP 429:
  1. Stop sending further requests to that endpoint until the window resets (x-ratelimit-reset).
  2. Retry with exponential backoff rather than retrying immediately.
  3. Batch where the endpoint supports it — for example, send multiple user updates in a single Track User request instead of one call per user.
If your integration consistently approaches a limit through legitimate, well-batched usage, contact your CSM or the Support team to request an increase.