Any system that can make an HTTPS request can send SMS. Here is what that takes, and what to watch out for.
The iSMS API speaks plain HTTPS. Your application makes a request with your credentials, the destination number and the message body; the API returns a response code and a transaction ID. There is no SDK to install and no library to keep updated — if your language can call a URL, it can send SMS.
Two APIs are available. The JSON API is the current one: it accepts up to 50 recipients in a single call, each with its own message text, and returns structured per-recipient results. The classic GET/POST API sends one shared message per call and returns plain text. Both use the same credentials, sender IDs and billing.
-1003. This is the most common reason a first integration appears broken.
Use the API directly. Most teams have a working send in well under an hour — it is a single HTTPS call with six parameters.
Start from a sample in your language, then read the full reference for response codes and delivery callbacks.
If you would rather not touch the code, our team can design and embed SMS into your existing application or system.
Scoped and quoted per project depending on what your system needs.
Working examples, each with the full request, the response format and error handling:
Code 2000 means the message reached the telco SMSC and returns a transaction ID. In Malaysia, operators do not confirm arrival on the handset by default, so do not build logic that treats 2000 as delivered. Store the transaction ID and match it against the delivery callback instead.
One ASCII SMS is 153 characters; one Unicode SMS is 63. A single emoji in an otherwise plain message switches the whole thing to Unicode and can turn one credit into three. If your messages are templated, check the length of the longest realistic output. Message size and credit boundaries →