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

# Sending best practices

> Advice for integrations that get replies and keep your Blujay numbers healthy. The hard rules live on Sending rules.

Apple and the carriers decide whether your messages arrive based on how people respond to them. Messages that get replies keep a number healthy. Messages that go unanswered, or get reported as junk, get a number filtered or blocked, for everyone it messages. These rules apply to every message your integration sends.

## Every new contact

**1. Say who you are**

Open with your name and why you're writing, in one short line.

**2. Ask one easy question**

Something they can answer from the lock screen, with no link or attachment.

**3. Wait for a reply**

Don't send more until they answer. A reply is what tells Apple and the carriers your messages are wanted.

**4. Then send links, photos and files**

Once they've replied, follow up with anything you held back, with a sentence that says what it is.

**5. Answer quickly**

Reply soon after they write back, and [show you're typing](#use-typing-indicators) while you prepare a longer answer.

## Dos and don'ts

| Do | Don't |
| - | - |
| ✅ Send messages a person would send: short, specific, one idea each | ❌ Send long, templated blasts |
| ✅ Wait for a reply before sending links, photos or files | ❌ Send links or attachments before they reply (Blujay rejects them) |
| ✅ Spread new conversations across the day and across your numbers | ❌ Start hundreds of new conversations at once from one number |
| ✅ Read `send_status` and `limits` before a batch | ❌ Retry blindly until a send succeeds |
| ✅ Stop after two unanswered follow-ups | ❌ Keep texting someone who doesn't respond (Blujay rejects the 7th in a row) |
| ✅ Opt out anyone who asks you to stop | ❌ Keep messaging after a "stop" |

## Write like a person

Each message should read as if one person wrote it to one other person.

* Say who you are and why you're writing in the first line.
* Ask one question that's easy to answer from a lock screen.
* Keep it to a line or two. Send a second message instead of a paragraph.
* Vary the wording between recipients. Identical messages sent to many people read as automated, to people and to spam filters.

## The rules Blujay enforces

Blujay rejects links, attachments, contact cards and texts over 300 characters until a contact replies to your number, and sends at most 6 texts in a row to anyone who hasn't responded. These are hard rules with their own error codes. They are listed once, with the exact errors, on [Sending rules](/messaging/sending-rules.md). Everything on this page is advice for staying well inside them.

## Pace new conversations

A Dedicated number can message up to 50 people it has never texted before per day. A new or recently reassigned number may start lower and reaches the full limit over about its first month. People who messaged you first never count against it, and you can always keep messaging people you already talk to. The live values are in `limits` on [`GET /v1/phone-numbers`](/phone-numbers).

* Read [`GET /v1/phone-numbers`](/phone-numbers) before a batch, and stop when `limits.new_contacts.remaining_today` or `queue.remaining` reaches zero.
* Spread sends over the day instead of sending them all at once.
* If you have several numbers, spread new conversations across them.
* Keep each person on the same number. Once a number has texted someone, keep using it for that person: switching numbers mid-conversation looks like spam to carriers.
* On [`RATE_LIMIT_EXCEEDED`](/errors/rate-limit-exceeded), wait for `Retry-After` or schedule the send for the next day. Don't switch numbers to get around a limit for the same recipient.

## Follow up sparingly

* At most two follow-ups a week to any one person, and stop after two follow-ups with no reply. That's well under Blujay's limit of 6 in a row, which is a backstop, not a target.
* Count everything a person gets from you, including messages from automations and from teammates on other numbers. Blujay counts them all toward the limit.
* To restart a quiet conversation, ask something short: *"Still worth keeping this open?"*

## Respect opt-outs

When someone asks you to stop, [opt them out](/opt-outs.md) right away. Blujay then refuses API sends to them with [`RECIPIENT_SUPPRESSED`](/errors/recipient-suppressed), so a bug in your code can't message them again.

## Aim for replies

A number stays healthy when the people it texts write back. Aim for **at least 3 in 10** of the people you start a conversation with to reply. Below that, the number's [health score](/phone-numbers.md#number-health) drops. Short, personal, specific messages get the most replies.

## Use typing indicators

Before you send a reply in an iMessage chat, start a typing indicator with [`POST /v1/chats/{chat_id}/typing`](/messaging/typing-and-read-receipts). The other person sees the typing bubble, so an automated answer feels attended. It's best effort and shows only in iMessage chats; SMS and RCS chats accept the request and show nothing.

## Watch your numbers

* Check `send_status.allowed` and `health_status` on [`GET /v1/phone-numbers`](/phone-numbers#number-health) regularly. A `degraded` or `critical` number needs fewer new conversations and more replies.
* Reply quickly when someone answers. Conversations with real back-and-forth are what keep a number healthy.
* Subscribe to [`message.failed`](/webhooks/events#message-lifecycle) and watch for a rise in failures.

## Check your integration with AI

When your integration works, have your AI coding assistant review it against these docs. The prompt is on [Build with AI](/build-with-ai.md#review-your-integration).

## Next steps

> **[Sending rules](/messaging/sending-rules.md)**
>
> The hard rules and their error codes.

> **[Phone numbers and limits](/phone-numbers.md)**
>
> Live sending status, limits and health.

> **[Rate limits](/rate-limits.md)**
>
> How limits work and how to back off.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.