Rate Limiting

No client-facing rate limit today

The ZeepNotti REST API does not enforce a rate limit on incoming requests as of this version - there is no 429, no Retry-After header, and no X-RateLimit-* header on any endpoint. You will not be throttled for sending requests quickly.

This is a current-state fact, not a guarantee for the future - build your integration so it can handle a 429 gracefully (back off and retry) even though the API does not return one today. This page will be updated if request-level throttling is added.

What "rate limit" handling exists is outbound, not inbound

ZeepNotti's delivery worker does interpret 429 Too Many Requests responses from FCM and APNs when it pushes notifications out to those providers - it treats that as a retryable delivery error and backs off before retrying the send to the device. That is provider-side throttling on the outbound leg of delivery; it has no relationship to how fast you can call the ZeepNotti REST API yourself, and it isn't exposed to you as a caller.

Practical guidance

• Sending a very large batch (e.g. targeting a large Segment) is one API call - ZeepNotti fans the delivery out internally per Device, so you don't need to throttle notification sends to stay under a device-count limit.
• If you're scripting bulk operations against Apps, Templates, or Segments, there's no enforced ceiling today, but keep concurrency reasonable - an unthrottled backend still has real CPU/DB/Redis capacity behind it.