An SMS API built for applications, not campaigns

An SMS API is an interface your application calls to send and receive text messages programmatically. Instead of opening a web dashboard and typing a message, your software makes a request to the provider over HTTPS, passes the destination number, the text and any options such as sender ID or encoding, and receives a response describing the outcome.

The difference that matters is what happens after the request. Campaign tools are built around lists, scheduling and open rates. Application traffic is different: verification codes, appointment reminders, order updates and alerts are triggered by events, must be traceable, and are often part of an operational record. That changes the requirements.

Infrastructure for application-generated traffic differs from a campaign tool in concrete ways. Messages need delivery receipts so you know the final state. Encoding must be explicit so a message is not silently corrupted when it contains Unicode. Callbacks must be dependable so your system can act on them. High-volume senders need a protocol designed for persistent connections. And rates should not be guesswork: supported rates depend on destination, sender type, registration and upstream connectivity, and they are published per destination rather than hidden behind a single marketing figure.

WorldText exposes application messaging through interfaces built for integration rather than manual use.

The primary interface is an HTTP API over HTTPS. Every account has its own credentials, and the API is documented as a rendered OpenAPI specification at developer reference, with an overview at /http-api/. Helper libraries for common languages are listed at /docs/libraries/, so you can spend your time on your product rather than on request plumbing.

For high-volume traffic, SMPP v3.3 and v3.4 is available on request. SMPP is the protocol used between carriers and aggregators: it keeps persistent connections open, which avoids per-request overhead at scale and suits systems that already speak SMPP. Activation usually takes under 24 hours once you contact us, and it is not enabled for trial accounts. SDKs for Java, C/C++, Perl and Visual Basic are available, along with a free SMSC simulator for testing.

Email interfaces are part of the platform too. Email-to-SMS accepts messages over SMTP, documented in the SMTP API for single messages and the SMTP bulk API for bulk jobs. That suits monitoring systems, legacy applications and anything that can send mail but is not wired to an HTTP API, without changing how those systems work.

Application messaging only works when the outcome is knowable. WorldText provides delivery receipts through a callback URL configured in the portal Configuration tab. The platform sends a final-state callback when a message reaches a terminal state, and message states and error codes are documented at /message-state-errors/ so you can map each outcome to business logic rather than guessing from a vague success flag.

Encoding is explicit, because text message encoding is where most silent failures happen. You set the data coding scheme per message. dcs 0 and 1 are GSM default encoding (GSM-7), which carries 160 characters per part in the classic single-part view; dcs 8 is UCS2 Unicode, 70 characters per part; and concatenated messages are split at 153 and 67 characters per part respectively. If your application sends emoji, accented characters or other non-GSM content, you control whether the message is delivered as Unicode or rejected, rather than discovering corruption after the fact. SMS length and concatenation and the GSM character set are documented for exactly this.

Combined with per-account credentials and HTTPS transport, this is what makes the API usable inside production systems: your code knows what was sent, what was accepted, what each encoding decision did and what the final state was.

The easiest way to lose trust in a messaging integration is to test against a fake and assume the results mean something. WorldText keeps testing honest.

For SMPP, a free SMSC simulator is available for integration testing. It is clear about what it is: it speaks the protocol so you can exercise connections, submission flows and receive-side handling, but it does not deliver to real handsets. Delivery to a real network is a separate step.

For the HTTP API, the portal supports a simulation mode for testing, so you can exercise your integration and callback handling without consuming credits on real numbers. The caveat is worth stating plainly: coverage publishes per-destination rates, and real-world delivery can only be observed with real sends, which is exactly why delivery receipts exist.

Before launch we recommend the obvious steps that are often skipped: test with a real number in each destination you target, confirm your callback URL accepts requests, check what your code does with each documented message state, and send a Unicode test message. Credentials stay per account, access stays over HTTPS, and nothing about the test path should change when you go live.