Send SMS to US numbers from your own code

WorldText is messaging infrastructure rather than a campaign tool, and the API reflects that. You submit messages from your own systems to our HTTPS endpoint, authenticate per account with your API key, and get structured responses back. There is no dashboard dependency at send time: your code decides what goes out, when, and to whom.

The API is documented end to end at the developer reference, which renders the OpenAPI specification, and the HTTP API guide covers the practical details of requests, parameters and responses. Examples and helper libraries exist for common request flows in curl, PHP, Python, Node.js, C# and Java, and our libraries page lists what is available for your stack. Message state and error codes are published separately so your applications can interpret results rather than guess.

The same account and credentials cover our whole coverage footprint, so one integration written for US destinations also works for the UK and the rest of our network.

Sending is only half the job. The API supports a callback or receipt URL configured in the portal Configuration tab, and delivery receipts are delivered to that URL when a message reaches its final state. That means your systems can mark a message delivered, track a failure, and act on it, rather than assuming every submission reached a handset.

Message state and error codes are published at our message state and errors page so you can map results to actionable states in your own code. This matters particularly for US traffic, where carrier-side filtering can stop a message without any error at submission time. Receipts are the difference between believing a message went out and knowing what happened to it.

For two-way flows, replies are handled separately and can be delivered back over HTTP webhook, SMPP or email, which keeps inbound and outbound handling in the same integration if you need it.

US numbers expect the same encodings as anywhere else, and the API gives you control over them. The dcs parameter selects the data coding scheme: values 0 or 1 use GSM, which is the default and the most widely supported, and value 8 selects UCS2 for Unicode content.

GSM classic messages carry 160 characters per part, Unicode messages carry 70 characters per part, and concatenated multipart messages are limited to 153 and 67 characters on the first part. Our SMS length page details the arithmetic, including the impact of the on-the-wire headers, and the GSM character set page lists which characters are safe in classic encoding. Where you need longer content, concatenation is handled by the platform: submit a longer message and it is sent as multiple parts, billed as multiple messages.

Note that characters outside the GSM set, including emoji and some accented letters, require UCS2, so choose the encoding deliberately rather than discovering truncation in production.

The API is usable against real numbers immediately, and testing flows are available without waiting for a production send. An account comes with access to our simulator for testing how your system behaves, and if you are integrating over SMPP, a free SMSC simulator is available for integration work. Be clear on what a simulator does and does not do: it exercises your code path but does not deliver a message to a handset.

The honest approach is to test both layers. Exercise the API and your parsing against the simulator or test sends first, then send to real US numbers and confirm delivery receipts before you treat the integration as done. Registration timing is the other practical constraint: US sender registration is part of going live with 10DLC or toll-free, so start that while your code is still being tested.

Keep a small set of real test numbers and a smoke check in your pipeline, because delivery behavior varies by carrier and is rarely visible at submission time.

The API is sender-agnostic, but US traffic must be carried on registered senders. Application-to-person messaging from a 10-digit number requires that the brand and campaign be registered through The Campaign Registry, and toll-free numbers must be verified before A2P use. Send on an unregistered number and carriers may filter your traffic regardless of how well your API call succeeds. Our 10DLC page covers the registration path in detail.

For very high volumes, an SMPP interface is available on request and is normally activated within 24 hours, though it is not suited to trial accounts. The same account covers HTTP and SMPP, and US destinations are priced at 8 credits per single-part message, with multipart messages charged as multiple messages. See our pricing page for destination rates and credit bundles.

Also remember that an unregistered sender can look perfectly healthy at submission, so confirm registration status before blaming the API when a message does not arrive.