How to Evaluate Email Service Providers on Their API
Comparing email service providers based on their Application Programming Interfaces (APIs) is like comparing a Thai restaurant to an Italian one: It’s not a straightforward comparison. It depends less on the ESP and what their API offers, and more on what you prefer, like Pad Thai to Spaghetti alla Puttanesca. Both dishes involve noodles, but that’s where the similarity ends, and choosing between them means looking beyond the noodles. This is true of APIs too.
Why APIs are important
ESP APIs offer a programmatic way to automate actions inside the ESP. Those actions can do almost anything depending upon what level the ESP offers.
The most popular APIs are used for: Sending transactional email, Adding records to the system, Pulling reporting and Integration with a back-up company system.
APIs allow for different systems to connect and be controlled from outside the system-all without human intervention. Obviously APIs are important, but more so for some businesses than others.
Marketing starts the conversation
When evaluating an ESP’s API, there are the primary items you’ll want to know, like speed, stability, features, functionality, how you’ll be connecting, etc. But marketing is the real starting point and the driver of all this.
When choosing between the restaurants, you have to start with the question, “What do I want to eat?” In the case of ESPs, marketing starts the conversation by answering the question, “What do I want to do?” Marketers must be crystal clear on what they want to be able to do through the API, both now and in the future. You must also know your overall strategy, message calendar and budget. Only then can the developers start an API evaluation.
API: single call or multiple steps?
What needs to be controlled in an ESP is primarily dependent on what the marketer wants to do. For example, if a marketer wants to send an automated daily email with a correctly formatted RSS feed located on their website, the ESP might need an API to expose an email to be updated with the newly formatted RSS feed before the send occurs.
There are other ways to accomplish this. However, it highlights a specific way an API might be used. In this example, there are enterprise-level ESPs that do not allow this to occur in a single step, however. You would have to break it into the following lengthy process:
1. Authenticate and receive the API session key back
2. Delete the previous email
3. Add a new email with HTML content
4. Indicate the correct segment for the email
5. Schedule the message for deployment
Other enterprise ESPs break this into a single call: update HTML email. Still others do not support adding or updating email via the API. If your developers didn’t know that a marketer wanted to send the daily RSS feed when they were asked to evaluate the API, they would be clueless and unable to evaluate the API on its ability to accomplish this task.
Productized integrations and plug-ins
Other times, your IT resource doesn’t need to get involved in the nuts and bolts because the ESP has a productized integration into the other system of interest already. The integration could have been produced by the ESP, the other system, or a third party.
These types of productized integrations with the ESP are typically for a CRM (such as Salesforce.com, Microsoft Dynamics or Sugar), ecommerce (for example, Magento or Hybris), analytics (like Google or Adobe Omniture), and reporting and business analytics (for example, Tableau Software).
Get the developers involved
The first item of business is to make sure you know what you want to do with the API. The next is to make sure you have your developers at the table. By having them at the table, I mean having a conversation with them. Just handing them an API documentation won’t cut it.
You might laugh at this thought, but it happens. In fact, it happens to our technical team at ClickMail fairly regularly, that a client hands over an API guide for our team to figure out how to do an integration or ESP customization. But the developers need to know more than that. They need to know the integration strategy, the data that will power the email (segmentation and personalization), the calendar, the budget, and the context at the very least.
Once you’ve provided the developers with all of that information, then you can let the developers start asking their own questions, about the programming language, for example, and the nitty gritty about how it will all work.
Specific questions to ask an ESP about their API
As the Chief Technology Officer, I can’t stress enough that your conversations need to start in the marketing department before you start making technical comparisons. Once you’re past that point and your developers are involved, you get started with your evaluation. And even though I am unable to provide you with an exact list of questions because every API need is different, I do have some specific questions for you to consider when evaluating the API of an email service provider:
Scalability
• How frequently can you connect to the API? How many times per minute, hour, day?
• What data is available for consumption from the API?
• Can the API support the scale you need?
Terms of use
• Does the ESP charge you for API use?
• What does the Service Level Agreement (SLA) stipulate?
• Are there ongoing support costs for managing the integrations?
Integration
• Understand the type of API the platform offers: XML-based, Simple Object Access Protocol (SOAP), REST, Synchronous or Asynchronous.
• Does the ESP offer easy access to clearly written documentation?
• Does the ESP offer example code in the programming language that you are using?
• Will the ESP help with integrations or are you on your own?
API maintenance
• Will the ESP offer assistance if you run into trouble?
• Who monitors the API and how?
• How are API errors handled?
When comparing ESPs based on APIs, keep in mind that different companies have different skill sets and it’s best to ensure that the platform’s API can be easily and effectively employed by your organization. Also look behind the scenes to evaluate the platform’s infrastructure to support the API calls. No API will work for you if it doesn’t have a redundant, scalable infrastructure to support it.
Once you start the process of really figuring out what it is you want to do, and you hand over that kind of detailed information to your development team, you’ll find the API comparison isn’t really that hard—no harder than choosing between Thai and Italian, right? Just make sure you look beyond the noodles…
Images by Beraldo Leal, Fabernovel (cc)
