ZeroSettle reliability and trust: uptime, spam flags and security

What does ZeroSettle publish about reliability, and what doesn't it promise?

ZeroSettle publishes six reliability figures, on its homepage and in its API docs, and none of them is a contractual commitment.

None of these figures states a measurement period or method, and ZeroSettle publishes no independent audit of them.

ZeroSettle's iMessage API Terms and docs also say what is not promised:

• No SLA or uptime warranty. “ZeroSettle does not warrant that the services will meet your requirements or that their operation will be uninterrupted or error-free.”
• No delivery promise. The Services depend on Apple’s iMessage service, “and delivery of any particular message or feature is not guaranteed.”
• No read or delivered receipts in the API. The API reports message.sent (the message left the line) and message.failed, and no later event.
• No end-to-end encryption. Content “may not be encrypted and … ZeroSettle cannot guarantee communication privacy.”
• No Apple affiliation. “ZeroSettle is not affiliated with, endorsed by, or sponsored by Apple Inc.”

For contrast, as of October 2026, per its public site, Twilio's APIs Service Level Agreement commits to 99.95% monthly availability for its Services APIs, measures API availability rather than message delivery, and pays service credits, not refunds. The iMessage API comparisons cover other providers.

How does ZeroSettle report failures, and what happens to a flagged number?

ZeroSettle reports each failure to your code as an error code or a webhook event, and replaces a flagged number at no extra charge; four pages explain those signals.

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

Every published figure with its source and status, each failure mode in detail, what isn't promised, how the figures are measured, and how the evidence compares with other providers'.

What does 99.9% uptime mean for an iMessage API?

99.9% allows about 43 minutes of downtime in a 30-day month. Why ZeroSettle's figure is a stat, not an SLA, and what Twilio, Linq and others publish instead.

iMessage delivery status, webhook retries and latency explained

message.sent means the message left the line and message.failed means it was not delivered; there is no read event. Plus which errors mean retry and which mean stop.

What happens if your iMessage number is flagged as spam?

Every send fails until ZeroSettle replaces the number, at no extra charge. Your token, webhook and code stay the same, but recipients see texts from a new number.

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. 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.

zerosettle.io FAQ, “What if a number does get marked as spam?”

How does ZeroSettle handle spam limits, STOP and security?

ZeroSettle enforces new-contact limits and STOP on every account and signs every webhook; getting consent and checking the signature stay your job.

• STOP: “When a contact texts STOP, the server records it and blocks your number (every number on your account) from reaching them.” Any text with the word STOP in it counts, and so does a clear request like “take me off your list”; only START opts them back in. Texts, voice messages, photos, reactions, typing and name-and-photo shares to them return 403 recipient_opted_out; nothing is sent or stored.
• Signing: X-ZeroSettle-Signature: t=<unix>,v1=<hex> is an HMAC-SHA256, keyed with your webhook secret, of "<t>." plus the raw body, with a 300-second tolerance. Verify the raw bytes before parsing and compare in constant time. The secret is shown once and rotates when you register again; the docs' webhook steps have Python and Node verifiers.
• Recipients' spam folders: separately from a flag on your number, iOS 26 on a recipient’s iPhone filters messages its spam detection judges to be junk into a Spam folder, on by default and with no notification (Apple Support). message.sent can't tell you whether a text landed there.

How to keep a business iMessage number out of spam filters

What gets a number flagged, the new-contact limits per number (Pro: 5 a day; Growth: 50 a day, 3 per 15 minutes) and why people who text first are never limited.

How STOP and opt-outs work on a ZeroSettle iMessage line

What counts as an opt-out, how START reverses it, and how GET /api/imessage/opt-outs lists every opt-out with its time.

Is ZeroSettle's iMessage API secure? Tokens, webhooks, data

Tokens, signature checks, data retention, and what ZeroSettle does not claim: end-to-end encryption, SOC 2 certification or HIPAA compliance.

iMessage marketing and TCPA consent: a practical guide

Consent records, quiet hours and STOP. Under the TCPA, as generally read, a person can recover $500 per violation (or their actual loss, if greater), and a court can raise that to as much as three times for a willful or knowing violation (47 U.S.C. § 227(b)(3)). This isn’t legal advice; check your obligations with counsel.

What doesn't ZeroSettle publish yet?

ZeroSettle does not yet publish a monthly send-success rate, p95 send latency, webhook delivery success or an incident history, and has not announced a date for them. Until it does, measure your own line (method):

1. Time each POST /api/imessage/send call and log its result or error.code; that gives you your own median and p95 send time.
2. Count message.sent and message.failed events at your webhook each day; sent divided by sent plus failed is your send-success rate.
3. Log the live stream's delivery events, one per webhook attempt with ok, status_code and attempts, or check last_delivery in GET /api/imessage/line for the newest delivery.

New to the product? Read what ZeroSettle is and the API docs, compare plans, or get a number.