Limits

BlueBot sends from your own number through your own Mac, so its limits are there to keep that number in good standing with Apple and the carriers, and to keep one runaway loop from becoming a problem. They come in two kinds:

• Sending rules are yours. Pace, new people per day, quiet hours and expiry each have a default you can change in Settings → Sending rules or with PATCH/v1/settings.
• Fixed limits are the same for every account: the daily ceiling, sizes, the API's rate limit and how long things are kept.

Almost nothing here refuses a send. A text that can't go yet is accepted and waits with a hold that says why and until when, then goes on its own. The few limits that do refuse a request answer with an error code before anything is queued, so nothing is half done.

Every limit

Limits that hold a text

These four never cause an error. The text is answered 201, comes back queued with a hold, and goes by itself when the hold clears, unless its expires_at passes first.

Here is how they add up. Dana runs a small cleaning company and sends 120 texts at 2:00 PM to remind clients of next week's visits. 80 of the clients have never texted with her through BlueBot.

• Only 50 of the 80 new people can be texted today. The other 30 wait with daily_new_people_limit until midnight. Midnight is inside her quiet hours, so at midnight their hold becomes quiet_hours, and they go from 8:00 AM.
• The 90 that can go today leave her Mac 20 seconds apart, so the last of them goes about 30 minutes after the first. While they wait their turn, their hold is pacing.
• The 30 held overnight still have until 2:00 PM tomorrow before their 24-hour expiry, so they go in time.
• None of this needs a retry. Her loop sent 120 requests, got 120 answers and is done.

A text to someone you already have a conversation with never counts against new people, so a reply to a client who texted you a minute ago goes at once (after the pace).

Limits that refuse a request

These answer with an error and queue nothing. Fix the request and send it again.

The rate limit counts requests, not texts. A send that goes through but is held still counts as one request, and reading a message back counts as one too. If you poll for state, poll slowly or use webhooks instead. Every answer carries RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset, so a program can slow down before it's refused. Rate limits has the details.

Limits on time

The expiry setting runs from 1 to 168 hours (a week). Per text, expires_at can be any time after the text is due.

See where you stand

GET/v1/device answers today's counts against the daily limits, and how many texts are waiting:

curl "https://usebluebot.com/api/v1/device" \
  -H "Authorization: Bearer $BLUEBOT_API_KEY"

{
  "object": "device",
  "status": "online",
  "held_count": 2,
  "queued_count": 5,
  "today": {
    "sent": 14,
    "new_people": 3,
    "new_people_limit": 50,
    "daily_limit": 1000,
    "resets_at": "2026-11-14T05:00:00.000Z"
  }
}

resets_at is the next midnight in your account's time zone, written in UTC. Today's counts start again then.

Why the daily ceiling isn't a setting

1,000 texts a day is far more than one person's business sends, and a number that sends more than that looks like a bulk sender to Apple, whatever the reason. BlueBot is for texting people who know you. If you need to text thousands of people a day, a hosted service with its own numbers is the better tool, as What BlueBot is not explains.

The new-people setting is yours, from 0 to 1,000. The dashboard warns above 100, because Apple flags accounts that message many strangers, and once an account is flagged no setting brings it back.