Overview
Buzzbip applies reasonable rate limits to protect platform stability and comply with carrier and Meta policies. Limits may vary by endpoint, account tier, and channel (WhatsApp, SMS, chat). When exceeded, the API returns an error response in the JSend format — typically with HTTP 429 or a business error code in the body. Implement exponential backoff and respect Retry-After headers when present. Bulk sends (WhatsApp templates, SMS campaigns) should be queued server-side rather than fired in tight loops from client browsers.
Best practices
Cache read-heavy responses where safe (templates list, user profile). Use pagination parameters (currentPage, limit, page) instead of requesting unbounded datasets. Separate interactive user flows from batch sync jobs so a CRM import cannot starve transactional sends. Monitor error rates and throttle proactively before hard limits trigger.
Queue WhatsApp and SMS bulk sends server-side with delays between batches.
Handling throttling
When you receive rate-limit errors, pause the worker, wait, and retry with jitter. Do not spin in a tight retry loop. For ecommerce webhooks pushing orders or carts, deduplicate events idempotently so retries do not multiply load.
Integration notes
When integrating the Buzzbip rate limits endpoint into your application, treat https://app.buzzbip.com as the only production host. Obtain a JWT from POST /api/login_check and send Authorization: Bearer <token> on every request. Confirm User.hasApiAccess is enabled in Buzzbip Admin — without it, valid tokens still receive authorization errors. Parse JSend responses by reading status, message, and data together; do not rely on HTTP status codes alone. For ecommerce plugins, also send x-api-key, x-platform-type, and x-base-uri as described in the secret-key documentation. Respect trailing slashes on routes such as POST /api/contacts/ and POST /api/whatsapp/. Implement retries with exponential backoff when you encounter rate limits, and log full error bodies during development. Store credentials server-side, rotate secrets if exposed, and re-authenticate before the 3600-second JWT TTL expires in long-running workers. Use pagination query parameters instead of unbounded list calls, and queue bulk WhatsApp or SMS sends from your backend rather than client browsers. Test against a small set of contacts before enabling production campaigns. Keep an integration runbook that lists which Buzzbip templates, automations, and API keys each deployment uses so on-call engineers can diagnose failures quickly.
Security
Security best practices for Buzzbip API clients include restricting API credentials to backend services, using TLS for every request, and monitoring failed authentication attempts. Separate staging and production Buzzbip accounts when possible so template tests do not message real customers. Document which templates and automations each integration triggers, and version your webhook or sync job deployments. When debugging, redact phone numbers and message bodies in application logs shared with third parties.
What's next?
Related topics: getting-started/errors api/whatsapp-messaging api/sms