Rate limits and sending capacity

Two different limits, and mixing them up is the most common integration bug.

API rate limits cap how fast your code can call the API. Technical limit: you hit a 429, you back off retryAfter seconds, you continue.

Sending capacity caps how many brand-new cold contacts one line reaches per day. Deliverability limit: it exists because Apple's spam detection watches exactly that number, and it is not something to retry your way past.

API rate limits

Per key, enforced by the platform:

A 429 looks like this:

{
  "error": "Rate limit exceeded",
  "error_code": "rate_limited",
  "retryAfter": 12,
  "resetAt": "2026-08-31T09:20:00Z"
}

Wait retryAfter seconds and retry. Note the instant-send daily cap (75/day per key) is a velocity guard for conversational replies; outreach volume belongs on the drip lane, which has no such per-key ceiling because the lines themselves pace it.

Sending capacity: what is actually limited

The single most important fact, and the one integrators get wrong by assuming every message counts:

A number counts toward a line's daily cap only when all three are true: the line sent it a message today, the line had never messaged it before today, and it has never replied to you. Five follow-ups to the same new person count once, not five times.

The Blue Reacher managed policy

These thresholds come from Apple's observed enforcement behavior, not from us; we enforce them so your lines stay registered. Blue Reacher runs managed lines at:

These are the healthy long-term operating rates for a warmed line. Sizing rule of thumb: a 200-new-conversations-per-day target on opted-in traffic is a 4-line setup.

Limits scale with engagement. High reply rates and near-zero spam reports are what Apple's trust model rewards, so a line that consistently earns replies gets headroom; we raise caps as a line proves out rather than publishing a fixed ceiling that would be wrong in both directions. What we never do is invent our own arbitrary limits: everything here exists to keep you under Apple's thresholds, and daily_cap on GET /v1/devices always shows the number actually in force for each line today. (The sandbox's simulated line reports an illustrative cap; read the live number from your own lines.)

Warm-up

A new line ramps to full capacity over roughly four weeks of active days: a day banks toward the ramp when the line actually sends meaningful volume, and idle days pause progress instead of resetting it. During ramp, daily_cap reflects the current tier automatically. You never pace a ramping line yourself; the drip queue does it.

Plan for this commercially: order lines for the volume you want a month out, not the week you need it.

Quiet hours and pacing

Cold and bulk sends deliver inside the org-local 9am to 6pm window by default (override per send with window_start_hour / window_end_hour); a send that would land at 1am is pushed to 9am. Conversational replies are exempt and go out immediately. Within the window, drip sends are spaced with randomized gaps, because a hundred messages leaving a line in thirty seconds is the clearest automation signal there is. When a workspace has several lines, sends rotate across them.

What happens when a line trips anyway

Apple enforces per number, silently. Blue Reacher's monitoring watches the early signals (blue bubbles going green to known iPhones, delivery delays, reply-rate collapse) and reacts before you have to:

• Cooldown. A rate-limited line has cold sends paused automatically, typically 24 to 72 hours, then re-ramps at reduced volume. Replies to engaged contacts continue throughout, because two-way conversation is exactly the signal that rebuilds trust.
• Replacement. If Apple de-registers the number from iMessage outright, we replace the line: free, once per line per month, typically live within one business day. History stays in the platform; the new number ramps like a new line and reads as a new sender to recipients. Apple bans numbers, not accounts, which is why a swap fixes it.

Both surface on the device.health_changed webhook and in the dashboard.

Scale by adding lines, not by pushing one line

Capacity is per line, so volume is a multiplication problem: four lines at 50 opted-in contacts per day is 200 new conversations a day, roughly 4,400 a month, with every line inside the safe range.

Rules that keep it working:

• One prospect, one line, for the whole relationship. Sends auto-lock a contact to the line that reached them (lock, default on), so replies always come from the number the person knows.
• Fill lines evenly rather than running two hot and two idle; rotation does this for you when you do not pin device_id.
• Watch reply rate per line. A line sending 50 and getting 1 reply has a copy or list problem that more lines would only multiply.
• Reply fast. Engaged contacts are unlimited, so every reply you win converts capped traffic into uncapped conversation.