Limits

Per-line throughput and daily volume guidance

Apple doesn’t publish iMessage rate limits, but the signals their spam detection watches are well understood. Messages.dev is built around inbound-first conversations because that’s the pattern that stays comfortably under those signals. The numbers below are the safe operating points we recommend per line.

Only the API request rate is enforced by Messages.dev. The per-line message numbers are guidance reflecting Apple’s unpublished thresholds — exceeding them won’t return a 429, it raises the risk of Apple silently throttling or banning the underlying line.

Per-line limits

Limit	Value
Throughput per line	1 message / second
Inbound-initiated unique contacts / day	1,000
Replies inside a 24h conversation window	unlimited
Outbound to contacts > 24h since last reply	200 / day
Max unanswered messages to a single contact	5
Healthy outbound : inbound ratio	≤ 10 : 1
API requests / hour per key	1,000

A conversation is inbound-initiated when the recipient texted your line first. Replies inside 24 hours of their last message are effectively unconstrained. Once the 24-hour window lapses, follow-ups count against the 200 / day reach-out budget.

Signals Apple watches

Treat the table above as the safe envelope for these levers. Drift on any of them and the ceilings effectively shrink:

• Send-to-receive ratio. A line that mostly talks and rarely listens looks like a spammer. Keep it within roughly 10:1.
• Unanswered messages to a single contact. Stop after about 5 messages with no reply on the same thread.
• Daily volume. Volume itself isn’t the problem; volume combined with low recipient diversity or a poor reply ratio is.
• Recipient diversity. Lots of brand-new recipients in a short window reads as a blast.
• Spam reports. A handful of “Report Junk” taps on a single line can trigger restrictions within hours, with no appeals process.

What happens when you hit a limit

There are two failure modes, and they look different:

1. Messages.dev API limit (1,000 req / hour per key). You get a rate_limit_error with a Retry-After header. Back off until that many seconds have passed.
2. Apple-side throttling. Silent. Sends start slowing down, getting delayed, or stop delivering altogether. There’s no error code and no appeal — the only fix is to back off, fix the upstream pattern (ratio, unanswered messages, daily volume), and let the line cool down.

If a line is consistently flirting with the per-line numbers, the answer isn’t to push harder on that line. It’s to scale horizontally across more lines.

Warming up a new line

A brand-new line has no history with Apple, and its first ~2 weeks are when it’s most likely to get flagged. Ramp gradually: low volume the first few days, increase as the line accumulates real two-way conversations, and expect to operate well under the per-line numbers above until the line is established. Don’t assume a fresh line can immediately match an older line’s volume.

Next

Scaling with multiple lines

Add more lines and spread users across them when one line isn’t enough.