Rate Limiting
Current state of rate limiting on the ZeepNotti REST API.
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.