Log in
Integrations
Talk to sales Start the demo

Migrating From Twilio API

Seemlessly migrate from Twilio API to Omnichannel API

Overview

Migrating from other messaging platforms can be frustrating and time-consuming. To make the process more pleasant, Messente is offering a Twilio-like API, which minimizes the efforts required to make the switch from Twilio API to using Omnichannel API. Our API exposes an HTTP endpoint, that replicates Twilio's most relevant SMS sending features in a way that is almost indistinguishable to the users and requires minimal changes to your existing Twilio implementation to work properly.

Getting Started

Messente's API exposes an HTTP endpoint, that imitates Twilio's "Send SMS message" endpoint (described in detail here). The URL is purposely set to be as similar as possible to Twilio's, while the parameters for the POST request are completely identical, so the experience is as though you were using the original Twilio API. We then convert the request internally to Messente's Omnichannel API format and proceed normally from there. The responses you receive while sending the message, as well as the subsequent status callback will all follow the original Twilio API format, which should provide for a smooth transition between the APIs. 

The only preparations needed in order to switch to using this Twilio-Omnichannel API are:

  1. Create a Messente account here
  2. Generate API credentials for your account in the API setup and change it in your existing code
  3. Change the original Twilio URL in your existing code to: https://api.messente.com/2010-04-01/Accounts/<MessenteAccount>/Messages.json


What's supported?

  • Sending SMS messages
  • Scheduled messages
  • Status callbacks - receive status update regarding the messages
  • Smart encoding - automatic conversion to GSM-compatible characters
  • Content retention - decide whether to store message contents in history

Limitations and differences

Although this API replicates the core features of Twilio's SMS sending functionality, it's not a perfect copy and is missing some concepts available in the Twilio API. Some of those are:
  • TwiML Applications and the concept of custom Messaging Services
  • MMS messages
  • automatic shortening of URLs found in the message contents (ShortenUrls)
Generally, if there's a parameter that's described in the Twilio API documentation and it cannot be found on this page, you can assume that it's not supported along with it's functionality.

Additionally, there are some differences in behavior between the APIs, that might be worth mentioning here. These are:
  • our usernames do NOT follow Twilio's convention of adding the AC prefix, but the message IDs do follow the SM prefix
  • in contrast to the original Twilio API, we do NOT inform the user whether it was the username or the secret token that failed validation, as we deemed it to be a security flaw, hence the same error response is returned in both cases
  • we support the most common Twilio error codes, but NOT ALL off them
  • even though we don't support the concept of Messaging Services, we do support scheduled messages. You just need to pass in ScheduledType and SendAt parameters, just as for the Twilio API


Status callbacks

The StatusCallback parameter can be passed to specify a callback URL, which will be used to send status updates, which we call delivery reports . The delivery reports for messages sent using this Twilio-like API will also follow Twilio's status callback specification for SMS messages. This means, that a POST HTTP request with form data (Content-Type set to application/x-www-urlencoded) will be sent to the specified URL and the response you receive will be identical to Twilio's status update response body. The supported message statuses are: queued, scheduled, sent, failed, delivered, undelivered, and they directly correspond to the exact same statuses in the Twilio API.

Your response to the status callback should have an HTTP status code of 2xx. In case we don't receive a successful HTTP response, Messente will retry sending the status callback request up to 10 times, and will discard it afterwards.

The status callback request is signed using the same algorithm as the original Twilio callbacks, which is described in more detail in their documentation. This means the same signature validation code can be used for our API, with no changes needed.

Example response body


 AccountSid: "a88xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 ApiVersion: "2010-04-01"
 From: "example_sender"
 MessageSid: "SMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 MessageStatus: "delivered"
 SmsSid: "SMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 SmsStatus: "delivered"
 To: "+123xxxxxx"


Send a message

Endpoint URL: 
POST https://api.messente.com/2010-04-01/Accounts/<AccountSid>/Messages.json


Request body parameters

encoding type: application/x-www-form-urlencode
PropertyTypeInfo
FromrequiredstringPhone number in e.164 format
TorequiredstringPhone number or alphanumeric sender name
BodyrequiredstringText content of the SMS
StatusCallbackurlURL where the delivery report will be sent
SmartEncodedbooleanWhether to convert Unicode to GSM-compatible characters
ScheduleTypestringInclude this parameter with a value of fixed in conjuction with the SendAt parameter in order to schedule a message
SendAtdatetimeThe time at which you want the message to be sent. Must be in ISO 8601 format.
ValidityPeriodintegerThe maximum duration in seconds that the message remains valid until it expires. A status callback is sent for expired messages.

Example successful response

{
    "account_sid": "a88xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "api_version": "2010-04-01",
    "body": "hello, world!",
    "date_created": "Thu, 20 Feb 2025 22:34:59 +0000",
    "date_sent": null,
    "date_updated": "Thu, 20 Feb 2025 22:34:59 +0000",
    "direction": "outbound-api",
    "error_code": null,
    "error_message": null,
    "from": "example_sender",
    "messaging_service_sid": null,
    "num_media": "0",
    "num_segments": "1",
    "price": null,
    "price_unit": "EUR",
    "sid": "SMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "status": "queued",
    "subresource_uris": null,
    "to": "+123xxxxxx",
    "uri": null
}

Example error response

{
    "code": 21602,
    "message": "Message body is required",
    "more_info": "",
    "status": 400
}