How reliable is ZeroSettle? Uptime, delivery, spam flags and failures

What reliability figures does ZeroSettle publish?

ZeroSettle publishes two homepage stats, latency figures in its API docs, and a spam-flag count in its homepage FAQ; none of them is an SLA. ZeroSettle is an iMessage API: a real phone number on real iMessage, running on Apple hardware we operate for you, that your code texts customers from and hears back on through a bearer token and signed webhooks (what ZeroSettle is, explained).

The send time is measured to the moment the line hands the message to Apple, not to the recipient's screen. Inbound is pushed, so "inbound never delays a send."

Why a homepage stat is not a contract is covered in what 99.9% uptime means for an iMessage API; the ZeroSettle reliability and trust hub links the rest of this series.

What happens when something fails?

When a ZeroSettle send fails, the API returns a specific error code or a message.failed webhook event with a documented next step; a failed webhook delivery is retried, then recorded. Every send the line attempts is stored with record.status set to sent or failed (a send blocked by STOP is neither sent nor stored). What happens after Apple accepts a message is not visible to the API.

A send wrapper that follows the docs retries only the two transient cases and surfaces everything else:

import os, time, requests

BASE = os.environ.get("ZEROSETTLE_BASE_URL", "https://portal.zerosettle.io")
TOKEN = os.environ["ZEROSETTLE_TOKEN"]

def send(to: str, text: str, attempts: int = 5) -> dict:
    backoff = 2
    for _ in range(attempts):
        r = requests.post(f"{BASE}/api/imessage/send",
                          headers={"Authorization": f"Bearer {TOKEN}"},
                          json={"to": to, "text": text}, timeout=90)  # a text can take up to ~75 s
        if r.ok:
            return r.json()                       # "message_sent": handed to Apple
        try:
            err = r.json().get("error", {})
        except ValueError:
            err = {}
        code = err.get("code")
        if code == "line_busy":
            time.sleep(int(r.headers.get("Retry-After", "2")))  # 429; the docs say 2 s
        elif r.status_code == 503:                # phone_offline / phone_timeout
            time.sleep(backoff)                   # retry with backoff
            backoff = min(backoff * 2, 60)
        else:                                     # new_contact_limit, recipient_opted_out, ...
            raise RuntimeError(f"{r.status_code} {code}: {err.get('message')}")
    raise RuntimeError("line still unavailable; queue the message and alert")

More on message.sent, message.failed and the retry schedule is in iMessage delivery status, webhook retries and latency; the ZeroSettle error table lists every code.

How likely is a spam flag, and what happens then?

A spam flag on a ZeroSettle number is rare by ZeroSettle's own account. Its homepage FAQ: "It is rare. The API's rate limits are designed to keep every line out of spam filters, and across more than 10,000 messages a week we have seen it happen only twice." A flag matters more than any single failed send, because it stops the number for everyone at once.

The docs name the fastest way to get flagged: "Repeated messages to people who never answer are the fastest way to get a number flagged by Apple: when that happens every send fails, to everyone." A sudden run of message.failed events across many recipients is the pattern to alert on.

ZeroSettle's homepage states what happens next: "If it does happen, we replace the number right away at no extra charge. Your API token, webhook, and code stay exactly as they are, so your integration keeps running without changes." For accounts with several numbers, the docs add that the line "keeps its line_id, conversations, message ids, name and photo, and STOPs, and only its number (line) changes. Store line_id; show line."

The number itself is new, so recipients see messages from a different number. More in what happens if your iMessage number is flagged as spam.

How do the limits protect reliability?

ZeroSettle caps new contacts per number because unsolicited volume is what gets a number filtered. The docs: "This is what keeps the number out of Apple's spam filters; it applies to every caller, the console included."

On both plans, messages sent within 5 minutes of the first count as one, and anything the contact sends back (a text, photo, voice note or tapback) resets the count.

The docs define the term: "A 'new contact' is a handle the line delivers a text, voice message, or photo to first; reactions, typing, profile shares, and failed sends never count. Anyone who texted the line first is never limited, and neither is an ongoing conversation." On one Pro number, the 6th new contact in a day returns 429 new_contact_limit; on one Growth number, the 4th new contact inside 15 minutes does. With several numbers, a send is refused only when every number is full (or the line the send names is).

The docs call the limits "a floor, not a licence"; the habits that keep a number clean are in how to keep a business iMessage number out of spam filters.

How secure is the API?

ZeroSettle authenticates every API call with a bearer token and signs every webhook with HMAC-SHA256, so your server can reject forged or replayed events. ZeroSettle makes no end-to-end encryption claim.

• Tokens: every call sends Authorization: Bearer <token>. Tokens are minted in the console; "minting again revokes nothing, revoking revokes all."
• Webhook signing: each POST carries X-ZeroSettle-Signature: t=<unix>,v1=<hex>, an HMAC-SHA256 of "<t>." + raw body with your secret. Verify the raw bytes before parsing, compare in constant time, and reject a t more than 300 seconds from now. Ready-made Python and Node verifiers are in the ZeroSettle webhook docs.
• The secret: shown once; registering the webhook again rotates it.
• Privacy: ZeroSettle's terms say content "may not be encrypted and … ZeroSettle cannot guarantee communication privacy."

Data handling and the rest of the security model are in is ZeroSettle's iMessage API secure.

How is compliance enforced?

ZeroSettle enforces STOP itself and suspends lines used for unsolicited messaging; consent and quiet hours are the sender's responsibility. A suspension stops the line, so consent matters for reliability as well as for the law.

• STOP: "When a contact texts STOP, the server records it and blocks your number (every number on your account) from reaching them." A text with the word STOP, or a clear request like “take me off your list”, opts them out across every number on your account. Texts, voice messages, photos, reactions, typing and name-and-photo shares to them return 403 recipient_opted_out; nothing is sent or stored. Only START (or unstop) opts them back in. See how STOP and opt-outs work on a ZeroSettle line.
• Consent: "ZeroSettle suspends lines used for unsolicited messaging. If you are unsure whether you have consent, you don't."
• Quiet hours: the docs say not to send anything promotional before 8 am or after 9 pm in the recipient's time zone.

Consent rules vary by country and by message, so check yours with counsel. This isn't legal advice.

What does ZeroSettle not promise?

ZeroSettle does not promise uptime, delivery of any particular message, or read status, and its terms say so. The quotes below are from the ZeroSettle iMessage API Terms (last modified September 28, 2026) and the docs.

• No SLA. "ZeroSettle does not warrant that the services will meet your requirements or that their operation will be uninterrupted or error-free." The terms include no service credits.
• No delivery promise. The terms say "delivery of any particular message or feature is not guaranteed."
• No read or delivered receipts in the API. message.sent means "A message left the line"; no API event reports delivery to the recipient or a read. The terms add that "message status, delivery and read receipts, typing indicators … may be delayed, incomplete, or inaccurate."
• No Apple affiliation. "ZeroSettle is not affiliated with, endorsed by, or sponsored by Apple Inc." The terms note that the service depends on "third-party platforms, including Apple's iMessage service, that may change without notice," so iMessage availability and Apple's spam filtering sit outside ZeroSettle's control.

ZeroSettle is not a fit if procurement requires a contractual SLA with credits, or if a message must reach someone without iMessage: there is no SMS fallback. For anything critical, keep a second channel.

How are these numbers measured?

Every ZeroSettle figure on this page is ZeroSettle's own published statement, quoted as published; none comes from an independent audit. The homepage stats state no period or method, and the docs' latency figures describe normal behavior ("normally", "about"), not percentiles.

ZeroSettle does not yet publish a monthly send-success rate, median or p95 send latency, or an incident history. When it does, this page will state the period, the number of sends and the method. Until then, measure your own line:

1. Time every POST /api/imessage/send call and log its result: message_sent or the error.code.
2. Count message.sent and message.failed events on your webhook per day; sent ÷ (sent + failed) is your send success rate.
3. Record last_delivery from GET /api/imessage/line (ok, status_code, attempts), or watch the live stream's delivery events.
4. Count 503 responses and line_busy retries as your view of availability.

How does ZeroSettle compare on published reliability evidence?

Messaging providers publish anything from a contractual SLA with service credits (Twilio) to status pages, uptime targets and "as is" terms; ZeroSettle publishes a homepage stat and no SLA.

Status-page percentages are measured by each vendor; a marketing figure may not be backed by contract terms.

To test ZeroSettle against your own traffic, read the ZeroSettle iMessage API docs or get a number.