MMS stands for Multimedia Messaging Service. Multimedia Messaging Service is an extension of the core SMS protocol, and it was developed to enable the transmission of multimedia content via text message.
MMS messages cost a bit more than SMS messages because it involves the transmission of more data.
In case you’re wondering “Why pay more for MMS?”, the answer is pretty easy: MMS campaigns have a 20% higher opt-in rate than SMS campaigns, and MMS messages are 8x more likely to be shared on social media. Pics and gifs are simply much more engaging than plain old text, and that’s why it’s worth paying more for MMS.
MMS creates a richer mobile experience for your customers or subscribers. A picture is worth a thousand words.
With our MMS messaging API, you can:
Send MMS messages
Receive real time delivery reports (DLR) for all messages sent
Receive replies and inbound MMS message
Our simple REST API allows you to get up and running in minutes, just follow the helpful Quick Start guide. For advanced users, dig deeper into our technology and check our reference guides for more detailed functions and calls. We have a wide range of calls to mirror useful functionality on the site at both user and reseller level. We also offer code samples in order to make your experience using the API suite as clean as possible.
So let’s now look at how to use and get the best out of the REST API.
Security
To ensure security & privacy, the API only works over HTTPS protocol for all requests. Also, for your own security, if you have a website with a form which sends MMS, be sure to send the request from your server and not directly from the browser, otherwise you will be giving away your API secret and opening the floodgates to unwanted charges.
Authentication
All API requests require your API credentials, we will provide you APPKEY. For security, API credentials must be passed as HTTP Basic Authentication headers not as CGI parameters.
Throttling
To provide the best service to all our customers, we limit the number of API calls which can be made by each account to 15 calls per sec. For heavy users, we can increase your throttling speed, but please contact us to discuss your requirements. If you exceed this limit, we will return two indicators which you can use in your code to detect that you have been throttled. The first is the HTTP status code 429 “Too Many Requests”, the second is the error code “OVER_LIMIT” in the error block of the response body.
Pagination
Some responses are too large to be returned in one go so we paginate. To identify which calls use pagination, look for the “page” parameters in the parameter descriptions for each API call. These calls include a “page” block in the response with two values, “count” and “number”. Count tells you how many pages are available and number indicates the page number you are on. The page parameter is used to request a certain page, it defaults to 1. 25 responses will be returned per page.
Error Reporting
Always check if your API call was successful or resulted in error. You may check the following
200 OK response header. It will be 4xx if an error occurred.
error->code structure should equal to ‘SUCCESS’. Note that some API functions can return custom errors of their own (listed in appropriate document sections). Check the error->description for details, e.g. which field caused an error or which resource you don’t have access to.