Technical reference

Rate limits and fair use

Page updated: 2026-04-03

Summary

Rate limits protect linked WhatsApp accounts and shared infrastructure. Expect 429 responses when you exceed configured throughput.

Canonical reference: Hostnames, path prefixes, JSON field names, and changelog are maintained on docs.waping.app. Examples below are illustrative — align your integration with the live OpenAPI/reference there.

Connection model: WAPing links WhatsApp through a QR session (similar in concept to WhatsApp Web). This is not Meta’s WhatsApp Business Cloud API product, and you do not complete Meta BSP / Cloud API onboarding inside WAPing for this path.

Key definitions

Term	Definition
HTTP 429	Too Many Requests — short-term pacing; not the same as “monthly message quota exceeded”.
Retry-After	Optional header hinting when to retry; format may vary by endpoint version—confirm in canonical docs.
Monthly outbound quota	Plan entitlement on outbound volume—see /pricing; enforced separately from per-second API throttling.

Purpose

Give client implementers predictable signals for backoff and sharding without relying on undocumented behavior.

Best for

Clients that treat 429 as normal under burst load and implement backoff + jitter.
Spreading campaign sends over time instead of synchronized wall-clock spikes.

Not for

Assuming one global rate limit covers all routes and devices.
Publishing static RPM numbers from this marketing page—authoritative limits are workspace-specific.

Two different limit types

Type	What it caps	Where numbers live
Monthly outbound quota	Billable plan allowance for sends per month	/pricing (2026-04-03)
HTTP throttling (429)	Request rate and burst protection	Dashboard + docs.waping.app

Plan	WhatsApp devices (linked)	Outbound messages / month	REST API & webhooks
Free	1	500	Not included
Starter	1	3,000	Included
Growth	5	30,000	Included
Pro	15	300,000	Included
Enterprise	50	1,000,000	Included

Table above lists only published monthly quotas; it does not replace per-route 429 tuning.

Typical signals

HTTP 429 — too many requests; a Retry-After header may be present (seconds or HTTP-date depending on product version — confirm in canonical).
Response body — may include a machine-readable code and human-readable message (see Errors).

Workflow

1) Detect throttle

Classify 429 in your HTTP client; branch to backoff rather than tight retry loops.

2) Backoff with jitter

Use exponential backoff with jitter; cap maximum delay to avoid thundering herds on recovery.

3) Shard load

Spread campaign sends and batch jobs over time; avoid synchronized bursts from all workers.

Example response

429 Too Many Requests (illustrative)

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests; retry after 30s"
  }
}

Authoritative 429 values

Exact 429 thresholds are tier- and workspace-dependent. This page does not list RPM/RPS numbers. Use the dashboard and docs.waping.app for current values.

Caveats

Per-device and per-route limits may differ — a single global rate in your client is not always sufficient.
Webhooks have separate delivery and retry semantics — see Webhooks guide.