A2P SMS atcarrier rates
One-time codes, alerts and notifications on routes you choose, with the price of each message visible before you send it.
One API for transactional, OTP and marketing messages.
Pin a route you bought, or let Smart Routing pick the cheapest, the best quality or a balance of both for each destination. Segments are counted for GSM-7 and Unicode before the message goes out, and every message is billed from your balance at the route rate plus a capped platform fee.
A2P SMS
Application-to-person alerts, notifications and transactional messages.
Smart Routing
Cheapest, best quality or balanced on each request, or pin a route you bought.
Bulk sends
Up to 1,000 recipients in one request, with a status for every message.
Sender IDs
Numeric or alphanumeric senders, validated on every request.
Message history
Look up any message, or page through everything you sent, by API.
Unicode & long messages
GSM-7 and UCS-2, split into segments and counted before you send.
Live traffic in four steps
Nothing to sign and nobody to wait for. The sandbox runs the same routing and pricing as live traffic, so the integration you build is the one you ship.
- 01
Create your keys
Open a free account and create a live key and a test key. Limit either one to the Send SMS permission, so it can message and do nothing else.
- 02
Build in the sandbox
$50 of sandbox credit for test keys, added when you redeem an invite code. A test send is routed, counted and priced on a real route, then simulated, so no message leaves and your balance is never touched.
- 03
Fund it and pick your routing
Top up from $5 by card or crypto. Pass cheapest, best_quality or balanced on each request, or name an SMS route you bought on the marketplace.
- 04
Send, track, reconcile
Every reply carries the message ID, the segment count and the exact cost. Subscribe to webhooks and page through your history by date whenever finance asks.
The price of every message, worked out before it leaves
Each request is resolved to a route, measured and priced before anything is sent. The body is counted in its real encoding, the per-segment rate comes from the route's own rate deck by longest matching prefix, and the charge is taken in one atomic step with the platform fee beside it. If the route refuses the message, the charge is reversed and the reply comes back with a cost of zero.
- GSM-7: 160 characters in one segment, 153 per segment once a message splits
- Unicode (UCS-2): 70 characters in one segment, 67 per segment once split
- Extension characters such as € and { count twice, exactly as the network counts them
- The platform fee is 2% of the carrier cost and stops at $0.001, however long the message
{ "status": "sent", "segments": 2, "cost": "0.061000" }A sandbox that runs the real path
Test keys are not a mock server. A send on a test key goes through the same validation, Smart Routing and rate lookup as live traffic, then stops short of the carrier and draws on sandbox credit instead of your balance. You see a real route's segment count and cost while you are still writing the integration, and going to production is a change of key.
- Live and test keys side by side, each with its own permissions
- Bulk sends on a test key are simulated message by message, with nothing delivered
- The simulated reply carries simulated: true, so test traffic can never be mistaken for live
- ProductionLive keyUsed 2 minutes agowmmn_live_sk_…3f9aSend SMS
- StagingTest keyUsed just nowwmmn_test_sk_…81c2Send SMS
{ "status": "accepted", "simulated": true,
"segments": 1, "cost": "0.031620" }Your app on REST, your platform on SMPP
Applications post one JSON request per message. Messaging platforms that already speak SMPP bind straight in: every SMS route you buy comes with its own system ID and password, the bind is metered to the throughput the route carries, and each submit_sm is billed on the same segment and fee rules as an API send. Both doors lead to one account and one balance.
- Bind on port 2775 with the credentials issued when you buy the route
- A burst above the route's throughput gets a throttle response your client can retry
- Receipts posted to your HTTPS endpoint as each message is accepted or refused
- Your do-not-contact list is enforced on SMPP binds as well as the API
- One balance
- One suppression list
- One segment counter
Send the first one in a minute
No onboarding call and no waiting for an account manager. Create an account, take your API key and post to the endpoint below, the same one that carries live traffic. Test keys let you try it without sending a real message or call.
curl https://packetexchange.io/api/v1/comms/sms \ -H "Authorization: Bearer $PE_KEY" \ -d to="+447700900123" \ -d from="PacketEx" \ -d message="Your order has shipped" \ -d strategy="balanced" # Smart Routing
Everything a messaging integration needs
The parts you would otherwise build around an SMS provider, already on the send path and reachable from one API.
Routing per request
Leave out the route and Smart Routing picks one for the destination: cheapest by rate, best_quality with the best-rated route first, or balanced for quality per unit of cost. The most specific prefix always wins.
Pin the route you bought
Pass a routeId and the message goes over that purchase. Deck routes bill each destination at its own prefix rate, and a flat-rate route bills any price you agreed through an offer.
Sender IDs, validated
Numeric or alphanumeric senders of up to 30 characters, checked for a safe character set on every request. Each SMS route states whether it carries alphanumeric, numeric or pre-registered senders.
Retries that never double-send
Add an X-Idempotency-Key and a retried request replays the original reply for 24 hours instead of sending, and billing, the message a second time.
Signed webhooks
Point an HTTPS endpoint at sms.sent, balance.low and the rest of the catalogue. Every delivery is signed with an HMAC SHA-256 of its exact body, so you can prove where it came from.
History you can reconcile
Page through every message by date range with a cursor, look any one up by ID for its status, cost and reference, and find SMS beside calls in your CDRs.
Sends from AI agents
The PacketExchange MCP server exposes SMS sending as a tool, so an agent sends on your key with the same permissions, prices and test mode as your code.
Guardrails on every request
Embargoed destinations are refused before any routing or billing, and each key is held to 10 send requests a second, so a runaway loop cannot flood a route.
Built for teams who read the invoice
Transactional messaging is a cost line and a commitment to your users. Both are easier to keep when the platform shows its working.
The route's rate, not a retail price
You pay what the route charges per segment, plus a platform fee of 2% of that, never more than $0.001 a message. On a $0.03 message the fee is $0.0006. No monthly fee sits on top.
Every fraction of a cent accounted for
The charge, the route's share and the platform fee are booked together in one balanced ledger journal before the message is handed over. Nothing is billed twice, and a refused message is reversed in full.
From sandbox to production with one key
Test keys walk the live path, so the integration you finish in the sandbox is the one you deploy. Swap the key, fund the balance, and real traffic flows through the code you already tested.
SMS, voice and numbers on one account
The balance that pays for messages also pays for calls, phone numbers and Dialer campaigns. One login, one set of keys, one ledger, and one suppression list across your SMS and Dialer campaigns.
What changes when the platform shows its working
| A typical SMS API | On PacketExchange | |
|---|---|---|
| Price per message | A retail price per message, set by the provider and revised on its schedule | The route's own per-segment rate plus 2%, capped at $0.001 per message |
| The route | Unstated: the message takes whichever path the provider chooses | Tier stated on every route, and chosen by you or by Smart Routing on each request |
| Segments | Discovered on the invoice at the end of the month | Counted in the real encoding before sending, and returned in every reply |
| A refused message | Can still appear on the bill as a send | Reversed in the same request, with a cost of zero in the reply |
| Testing | Test credentials that return canned responses | Test keys that route and price on real routes, then simulate the send |
| Commitment | Monthly minimums or prepaid bundles to unlock a better rate | No monthly fee and no minimum: top up from $5 and pay per segment |
| Protocols | REST only, or SMPP under a separate agreement | REST and SMPP on the same account, balance and suppression list |
Transactional alerts
Order updates, receipts, appointment reminders.
OTP delivery
Best-quality routes for codes that cannot wait.
Notifications at scale
Bulk operational and service messaging.
Per segment, at the route's rate
An SMS costs the route's rate multiplied by its segments, plus a platform fee of 2% of that amount, capped at $0.001 per message. The rate is the route's own for the destination, or on a flat-rate route, a price you agreed through an offer.
You pay from a prepaid balance: top up from $5 by card or crypto, or from $100 by bank wire. There is no monthly fee, no minimum volume and no charge for holding a key.
Browse SMS routes on the marketplaceRoute rate per segment
Shown on every SMS route in the marketplace before you buy, and matched to the destination's longest prefix on deck routes.
Platform fee
2% of the carrier cost, never more than $0.001 per message, however many segments it has.
Refused messages
Charged before hand-off and reversed in full if the route refuses, so the reply shows a cost of zero.
Sandbox
Test keys draw on $50 of sandbox credit and never touch your balance.
Numbers on your do-not-contact list are refused before routing, so a suppressed send costs nothing.
What developers ask first
How is the price of a message worked out?
The route rate for the destination, multiplied by the number of segments, plus 2% of that amount, capped at $0.001. It is calculated before sending and returned in the cost field of the reply, to six decimal places.
How are segments counted?
A message made only of GSM-7 characters fits 160 characters in one segment and 153 per segment once it splits, with extension characters such as €, [ and ~ counting as two. Anything outside GSM-7, including emoji and non-Latin scripts, goes as UCS-2: 70 characters in one segment, 67 per segment once split. Messages can be up to 1,600 characters.
What status does a send return?
sent when the route accepted the message, or failed when it refused it, in which case the charge is reversed and the cost reads zero. Test keys return accepted, with simulated set to true. Any message can be looked up later by its ID.
Can I use my brand name as the sender?
Yes, on routes that carry it. Sender IDs can be numeric or alphanumeric, up to 30 letters, digits, spaces and the characters . + _ -, and every SMS route on the marketplace lists whether it carries alphanumeric, numeric or pre-registered senders.
Do you support SMPP?
Yes. Buying an SMS route issues a system ID and password you can bind with on port 2775, metered to the route's throughput. SMPP traffic is counted, billed and checked against your suppression list exactly like API traffic.
Is there a sandbox?
Redeem an invite code for $50 of sandbox credit on the API Keys page, and a test key then simulates. Test sends are routed and priced on real routes but never delivered, and they never touch your balance.
What happens if my balance runs out?
Sends are refused with an insufficient balance error and nothing is charged. Set a low-balance alert, subscribe to the balance.low webhook, or turn on auto-recharge with a saved card so your balance is topped up when it falls below the threshold you choose.