Increasingly as Email Marketers get more sophisticated and look to push more data into their ESP, trigger emails and download reporting into their own systems, they need an API to achieve this. API stands for Application Programming Interface – essentially it is a set of commands that allows a 3rd party system to use functionality of the ESP with no human involvement.
Here is my guide on what to look for when assessing the API of an email vendor:
Does it do everything?
Not all API’s are equal in terms of their capabilities, as some have been developed to only handle a few minimal features. However if there is missing functionality in the API it can stop an integration project in its tracks – and despite how much scoping you do, you may not find this out until it is too late. If an API is important to you, look for an ESP with a fully featured API that means anything you can do in their interface can be achieved with their API.
Is it simple?
Ideally each command in the API should be as simple as possible, and cover as much detail in one single call rather than breaking it down into several separate calls. For example, an API should have a command to load a customer record, check to see if it exists or not before adding or updating the information and then sending the email of your choice to the record. Some systems will require you to do several API calls to achieve this, which takes far greater development time, so make sure the API you choose supports key use cases like this as a single API call.
Is it modern?
Historically most API’s worked with SOAP, a protocol for accessing web services. However this is increasingly being seen as outdated and JSON is becoming the preferred choice for API’s. Nearly all the major Social Networks and Web Apps use JSON and not SOAP. A lot of legacy ESP’s still only support SOAP and not JSON.
Do you need an API?
Often clients ask about our API before understanding what they need to do. Sometimes an API is complete overkill and you don’t need to involve your IT team, saving everybody time and effort. For example, Maxemail’s existing web forms can be integrated with our form handler URL’s, product data feeds could be pulled from the existing one sent to your affiliate network or Google Shopping, transactional emails can use our SMTP service rather than making API calls and reports can be pushed to an FTP location of your choice rather than writing code to request data.
Every ESP should offer 1st line support to people using their interface but support for the API usually comes from a different department. Check what the support SLA is, and what is available for the API specifically. Your developers are going to want fast responses to their questions as they might not be able to move on until they get their code working.
Uptime, Response Speeds, Limits and SLA
When you integrate with your ESP via an API it usually becomes a mission-critical piece of technology. Therefore the reliability, speed and limits need their own separate service level agreement.
To find out more about the Maxemail API talk to our team who will be happy to answer any questions and provide you with any documentation you require.