Messaging safety limits and recovery

Blooio applies safety limits to protect iMessage numbers from patterns that Apple may treat as automated or unwanted messaging. There are two independent systems:

• Conversation limits apply to one recipient or chat. They clear when that recipient responds.
• Number protections apply to one sending number. They use rolling activity windows and clear when every triggering pattern has recovered.

Do not blindly retry a blocked send. Read the response body's stable code field and follow the recovery step for that code.

Conversation limits

Each chat earns a larger consecutive-message allowance as the recipient builds a real two-way history with you.

Conversation state	How it is reached	Consecutive outbound allowance	How to recover
New	No written reply or reaction yet	3 plain-text messages before the first response	Stop sending and wait for a reply or reaction.
Acknowledged	The recipient reacted but has not written back	3 messages after each response	Wait for another response. A written reply is still required before sending links or attachments.
Active	At least one written reply	4 messages after each response	Wait for another reply or reaction.
Established	3+ written replies across 2+ different UTC days	6 messages after each response	Wait for another reply or reaction.
Trusted	10+ written replies across 3+ days in a thread at least 7 days old	8 messages after each response	Wait for another reply or reaction.
Inactive	No reply or reaction for more than 14 days	One plain-text re-engagement message	After the re-engagement, wait for a reply or reaction.

A reaction proves that the recipient is engaged, so it resets the consecutive-message allowance and keeps a chat from becoming inactive. It does not unlock rich content or promote the chat to a higher allowance. Only a written reply unlocks links, media, and attachments and contributes to the higher conversation states.

Conversation error handling

• conversation_content_restricted (403): send plain text and wait for a written reply before sending links, media, or attachments.
• conversation_awaiting_reply (429): the 3-message first-contact allowance is exhausted. Wait for the recipient to respond.
• conversation_streak_limit (429): the current state's consecutive-message allowance is exhausted. Wait for the recipient to respond.
• conversation_inactive_paused (429): the one re-engagement message was already used. Wait for the recipient to respond.

These responses are not transient rate limits. Exponential retries will continue to fail and can create unwanted traffic. Resume the workflow after an inbound message or reaction event.

Number-level protections

Number protections are graduated. Blooio applies the most restrictive action required by any active reason.

Action	Effect
queue	Sends are accepted. Up to 8 messages in one chat can drain together, followed by a 3–8 second wait before the next burst. A conversation's lower allowance still applies.
slow	Sends are accepted with the same burst behavior and a 30–60 second wait.
pause_new	Brand-new chats are rejected. Existing chats and recipients who have previously replied remain available.
reply_only	Sending is limited to recipients who have messaged the organization first.
review	All outbound sending on the number is paused. Contact support.

queue and slow are transparent deferrals: the API accepts the message and its status remains queued until dispatch. Do not submit a duplicate because delivery is taking longer.

Recovery by reason

The reasons object in a v4 safety.state_changed event identifies every active reason. The Limits page shows the same reason-specific recovery steps. If several reasons are present, each one must recover before the action clears completely.

one_way: broad outreach with too few replies

This reason becomes active when all of the following are true:

• More than 10 new chats per day on a trailing 3-day average.
• At least 10 new chats exist in the trailing 7-day sample.
• Fewer than 40% of those new chats receive a written reply.

It starts at slow. It escalates to pause_new when the reply rate falls below 20% or the pattern remains active for 48 hours.

To recover:

1. Pause new outreach on the affected number.
2. Continue useful replies in conversations where recipients are already engaged.
3. Send future first messages only to opted-in recipients and make them specific enough to invite a genuine response.
4. Wait for the 3-day new-chat average to reach 10 or fewer, or for the trailing 7-day written reply rate to reach at least 40%.

Old activity remains in the rolling windows, so recovery can take several days even after behavior changes.

template: repeated first-message openers

This reason becomes active when there are at least 10 first touches in 7 days and at least half use a repeated opener. An opener is treated as repeated after the same fingerprint appears 5 or more times.

To recover:

1. Stop reusing the flagged opener. Do not send additional outreach merely to dilute the percentage.
2. Personalize future first messages for the recipient and context.
3. Allow up to 7 days for earlier repeated openers to leave the rolling window.

This signal is measured across the organization, so the same campaign copied across several numbers can protect all of them.

delivery: recent delivery health changed

With sufficient samples, Blooio compares the most recent 72 hours with the earlier baseline. The reason becomes active when the iMessage share drops by more than 10 percentage points or the device-visible failure rate doubles.

To recover:

1. Pause new outreach and inspect recent failed messages, recipient addresses, and protocol results.
2. Correct invalid or unreachable recipients before resuming.
3. If failures are not elevated and only the recipient protocol mix changed, contact support; messaging more Android recipients can lower iMessage share without indicating a problem with the number.
4. Allow up to 72 hours for the recent sample to normalize or age out.

sibling_ban: another number on the account was banned

This reason applies slow for 72 hours after another number owned by the same organization is banned.

Use the remaining number conservatively, prioritize existing two-way conversations, and investigate the sending pattern that caused the other ban. The reason becomes eligible to clear 72 hours after the ban.

When the protection clears

Number state is re-evaluated as messaging activity continues. A stale send can be evaluated against the previous state while a background refresh runs, so wait briefly before retrying a send that should now be eligible. In v4, subscribe to safety.state_changed and resume when action becomes none or moves to an action your workflow can handle. In v2, use the Limits page and the next send's machine-readable result.

The relevant blocking codes are:

• safety_new_conversations_paused (403)
• safety_reply_only (403)
• safety_account_review (403)

Turning limits off

Administrators can turn safety limits off for a dedicated number from the Limits page. This bypasses both conversation limits and number protections for that number and materially increases the risk of an unrecoverable Apple ban. Recipient opt-outs are still enforced.

Shared and inbound numbers cannot be uncapped by customers because their Apple trust may affect other accounts. Contact support only when the displayed reason appears incorrect; disabling limits is an exception, not the normal recovery process.

Warning

Apple bans cannot generally be reversed. Recover by changing the sending pattern whenever possible instead of turning protections off.

Integration checklist

1. Branch on the machine-readable code, never the message text.
2. Treat conversation 429 responses as "wait for recipient activity," not "retry after a timer."
3. Treat queue and slow as accepted asynchronous sends and continue tracking the original message ID.
4. Keep existing, replied conversations available during pause_new.
5. In v4, subscribe to safety.state_changed; inspect action, previous_action, and reasons.
6. Escalate review and unexplained delivery-health protections to support.