Share article:
Accessing REST products and features alongside legacy APIs
We previously wrote about the main difference between SOAP and REST APIs and when businesses should choose one over the other. If you are currently integrating with SOAP or other legacy APIs there may be reasons why you want to stick with that integration for your business messaging. However, that doesn’t mean you can’t experience the benefits of our latest features. We offer different products and features as separate REST APIs; meaning they can be used in a modular way, and you may find some additional benefits to your toolset. That means you can still use your existing integration for sending messages and then our new REST APIs to enhance your operational efficiency. Additionally, there are many features available that may have been launched subsequent to your core messaging integration. These features may enhance your existing integration and allow you to optimise your usage.
When to use our new product & features and what’s available
Lookups API
A prime example of when using adjacent REST API features can decrease your messaging load, is using the Lookups API. Regardless of how you eventually send your messages, you want to be periodically ensuring that your data set is clean and useful. Lookups API can help you Validate the phone numbers you’re sending to by checking their validity, type and carrier records. By ensuring your data set is clean, you can reduce costs across your organisation. This will, reduce the number of failed or undeliverable messages sent and enrich your database, helping you to reach customers more efficiently.
Webhooks
The main reason and a huge benefit to using some of the REST features is webhooks. If you’ve been using a legacy API to both send your messages and receive your replies and delivery reports, this means you have to poll the API periodically. This is unnecessarily taxing on your servers. You could be letting us do the work for you and send you the data that you want, rather than requesting info every so often and working out what’s relevant.
Additional features available to legacy API consumers
In addition to the above REST APIs, there are many features we have released over the last year that can be turned on for all customers. These include:
- Character Converter: Automatically remove special characters that can result in excessive charges and garbled messages.
- Dedicated Numbers: A dedicated number (or virtual number) allows you to send and receive messages from the same number, every time.
- Alpha Tags: An alpha tag gives your messages a unique sender name, including digits, text and some special characters.
- Deduplication: Ensure your business does not send duplicate messages to the same customer.
- Familiar Sender: Deliver SMS to recipients from the same number, without needing a dedicated number.
- Social Sending: Avoid accidentally disturbing customers out of hours and limit messaging to between 8:00 am and 6:00 pm.
These are features that can be enabled in your account by your account manager. Such features can be simple ways to maximise the value you’re getting out of your API usage, and are a phone call or email away. Most of these will require no/minimal code changes to use. Easily enable any of these features by reaching our support team at support@messagemedia.com
Tips for using different web services in the same application
This really depends on your use case, but overall the best way to architect your solution is to prevent “interaction” between the SOAP API and the REST API. This makes sense in the context of MessageMedia services because of the things you will use them for. For example, on one server you can be running server-side code that cleans your data set using the Lookups API, and then on a separate server, you can be using the SOAP Messaging API to send messages using that dataset. The only thing in common is the database, and each server sets up its own connection. The added benefit is that you can be running both applications simultaneously and not have one slowed down by the weight of the SOAP integration.
Avoid having to wait for a response from one API before triggering an action on another API. This would create a situation where you would need to make ‘translation’ code to extract things from XML or JSON make it a suitable payload for the other API. This seems obvious for things like reporting and sending messages, which can be done entirely separately. However, this is less obvious for things like Lookups. Clean your data intermittently or as numbers get added rather than looking up before you send.
In conclusion, there’s no reason you can’t use your existing legacy integrations in combination with newer RESTful web services to enhance the functionality of the same application. The main thing is to make sure you’re using the right service for you. Using web services together, when done smartly, can enhance overall operational efficiency and decrease unnecessary costs.
