Platform

The messaging platform behind senderZ

senderZ is what shows up when you stop treating messaging as an endpoint and start treating it as infrastructure. Four pillars hold the platform together.

Start free trial Talk to sales

✦

Agent-native messaging

senderZ treats AI agents as first-class clients. Every tool the MCP server exposes — send_message, list_contacts, check_optout — is auditable, scoped to a single tenant, and safe to put in front of a human approval. Auto-reply personas, suggested replies, and human-in-the-loop controls are built into the same primitives your developers use. This is what separates a messaging endpoint from a platform that an agent can operate.

See the docs

◫

Tenant-first architecture

Every message, contact, template, and webhook belongs to exactly one tenant. Phone pools, API keys, and subaccounts map cleanly onto the boundaries your customers already think in. Agencies and resellers get isolation that stops at the right layer — customers can see their own data, never anyone else's, while operators retain a single pane of glass. The tenant model is not a feature bolted on top; it is how the platform is built.

See Agency OS

🛡

Compliance by default

STOP, START, HELP keywords are processed before they ever reach a tenant webhook. Quiet hours are enforced per-recipient with time zone awareness. Every inbound message carries a consent log entry. None of this is optional, and none of it requires custom code. The platform ships safer operational rails than most teams would build on their own.

See Trust Center

◌

Transparent economics

Plans are priced on new contacts, not per message. Messages to customers you have already reached are unlimited. Trials are fourteen days, no credit card required, and there are no per-message overage fees. The number on the pricing page is the number on the invoice. Operators get a predictable cost model; developers get a billing surface that does not require a calculator.

See Pricing

How a message travels

Your app calls the senderZ API. The API enqueues the message and returns a message ID. A background router picks up the job, resolves the tenant's phone pool, runs compliance checks (opt-outs, quiet hours, warming limits), and hands the payload to the right delivery backend — iMessage first, then RCS or SMS as fallback. Delivery events and replies flow back through webhooks to your tenant's configured URL.

Your app
   ↓
senderZ API   (auth, validation, enqueue)
   ↓
Queue         (durable, idempotent, retry-safe)
   ↓
Router        (phone pool, compliance, warming)
   ↓
iMessage  /  RCS  /  SMS
   ↓
Webhooks      (delivery, reply, status events)

Read the full architecture