What changes between the four APIs?
Share business logic such as customer lookup and event logging, but give each channel its own request builder and response parser. Field names and success codes are not interchangeable.
Request and recipient differences across the messaging APIs
| Channel | Request format | Recipient | First setup check |
| WhatsApp | JSON POST; Content for a text reply | International phone number | Activated WABA sender, application credentials and message eligibility |
| Messenger | JSON POST; Message for text | PSID associated with your Facebook Page | Registered Page and Messenger credentials |
| SMS | JSON POST or classic form request | International phone number without the + prefix | Whitelisted sending-server IP and available credits |
| Email | Form POST; multipart for attachments | Email address | Verified sender address and domain configuration |
Handle inbound events according to their channel
The supplied WhatsApp reference describes a base64-encoded response parameter. Messenger inbound events arrive as a JSON array. SMS delivery callbacks use query parameters. Use the documented parser for each endpoint and deduplicate events using the identifiers supplied.
Keep fallback decisions in your application
If you plan an SMS fallback for a WhatsApp notification, define which confirmed failure triggers it and how your system prevents repeat sends. A timeout or a missing read receipt alone should not trigger another message. Each channel also needs suitable recipient consent and its own cost estimate.
Use the documented service host
The API reference pages are available here for iwsapp.my customers, while their send endpoints remain on iSMS and Vocotext hosts. Do not replace a documented API host with iwsapp.my. Each reference links to the original iSMS documentation.