This is not optional timing trivia
WhatsApp treats rapid, repeated OTP traffic from one linked number as spam risk. If your backend fires many POST /api/v1/send calls in parallel (retries, load tests, double-clicks, or a loop without a queue), you are asking for a ban on the business line you linked in the dashboard.
Zindua’s anti-ban layer paces WhatsApp delivery for you. After a successful WhatsApp send, wait at least 3 seconds before the next WhatsApp send for the same project. If you ignore that gap, you will see errors like: Wait Xs before sending another WhatsApp OTP.
- Minimum 3 seconds between WhatsApp sends (same project)
- Do not burst concurrent /send calls for WhatsApp
- Prefer a queue or debounce in your app for resend / load tests
- Zindua workers also pace; your app must still respect the gap
What Zindua does vs what you must do
On our side, the anti-ban robot applies a minimum interval and per-minute caps so one noisy client cannot melt a linked session. That protects every project on the platform, including yours.
Official SDKs (Node, PHP, Python, .NET) mirror that robot client-side: by default they wait ≥3s between WhatsApp sends on the same client instance and print a warning so developers learn to space traffic. On your side, still treat WhatsApp OTP like a rate-limited API: serialize bursts, use a queue or debounce, and map wait messages to clear UX.