> ## Documentation Index
> Fetch the complete documentation index at: https://messages.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Note>
  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.
</Note>

## 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`](/docs/concepts/errors#rate-limit-error-429) 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

<CardGroup cols={1}>
  <Card title="Scaling with multiple lines" icon="network-wired" href="/docs/scaling/multiple-lines">
    Add more lines and spread users across them when one line isn't enough.
  </Card>
</CardGroup>