Routing & control

Anti-spam pacing

Each number has a randomized gap between sends. Goal: spread traffic out so it doesn't read as a burst and keeps deliverability stable.

How it works (brief)

You POST /messages/send as usual.
The API computes notBeforeMs = max(now, lastReservedSlot) + random(min, max) for this sender.
The message goes onto the queue stamped with that timestamp. The gateway waits until notBeforeMs before sending to WhatsApp.
Your request still returns quickly (~202 Accepted), but the actual delivery lags by a few seconds.

Defaults & bounds

Field	Default	Range
`minGapMs`	3000	0 – 60 000
`maxGapMs`	8000	0 – 60 000 (≥ min)
`enabled`	true	boolean

Throughput math

Average throughput per number = 60 / ((min+max)/2 in seconds) msg/min.

min / max	Average	msg/min	Best for
1000 / 3000	2 s	~30	Time-sensitive transactional (OTP, login notif).
3000 / 8000	5.5 s	~11	Default — mixed notification + promo traffic.
5000 / 12000	8.5 s	~7	Bulk promo for new or risky numbers.

Configuring pacing

Via the dashboard (Numbers → Pacing) or directly via API. Fields are patch-style — send only what you want to change.

bashPATCH /v1/numbers/:id/pacing

curl -X PATCH https://api.shiftwa.dev/v1/numbers/<id>/pacing \
  -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{ "minGapMs": 1000, "maxGapMs": 5000 }'

How it works (brief)

You POST /messages/send as usual.
The API computes notBeforeMs = max(now, lastReservedSlot) + random(min, max) for this sender.
The message goes onto the queue stamped with that timestamp. The gateway waits until notBeforeMs before sending to WhatsApp.
Your request still returns quickly (~202 Accepted), but the actual delivery lags by a few seconds.

Field

Default

Range

minGapMs

3000

0 – 60 000

maxGapMs

8000

0 – 60 000 (≥ min)

enabled

true

boolean