A Marketer's Guide to APIs

• Tweet
• Buffer

In recent months, I've had many conversations with marketers around the subject of triggered messaging. Inevitably these discussions get into the technical details and we start talking about APIs and such. Most e-mail service providers (ESPs) offer an API (define). However, what that API can do and how it does it can vary enormously. The devil in such situations is in the details. Unfortunately, it seems marketers have often been left out (or perhaps tuned out) of the conversations about what APIs are, how they work, and why they're important.

So, here's my guide to the key things marketers should understand about APIs:

API stands for application programming interface.

This is perhaps the biggest area of confusion. APIs have been around for a long time and are simply standardized protocols (interfaces) that allow one computer program to directly communicate with another.

In the context of triggered messaging and ESPs, we're usually talking about Internet-enabled APIs and you'll hear mention of terms such as SOAP (simple object access protocol), REST (representational state transfer), and XMLRPC (extensible markup language remote procedure call). There's no need to be too concerned by those. They're just the mechanisms by which your systems can connect to those of the ESP. What really matters is what you can do once you're connected.

Knowing that an API is available doesn't tell you anything about what capabilities are available to you.

The capabilities will vary from provider to provider. While the core capabilities are fairly consistent, there may be details that are provider specific. In addition, how those capabilities are utilized can vary enormously. When specifying a project that depends on API integration it's important to ensure you have your development/IT staff vet the solution early on in the process.

APIs aren't new, but public, Internet-accessible APIs are.

APIs have been around for a very long time in computer programming, however it's only in recent years that providers have started to make them publicly accessible over the Internet. The standards for such protocols (SOAP, REST, etc.) are relatively new, as are the tools for using them. This means many programmers are relatively inexperienced and there are often incompatibilities to be resolved and learning required to use them effectively.

To take advantage of the API will require programming effort on your part.

While your systems may support the API protocol, how you use it and what you use it for is specific to your requirements. Therefore you'll need to have computer code written to utilize the API - integration isn't going to be automatic or point and click.

This may not be a problem if you have a capable development/IT department. But if you're a smaller organization this may incur significant costs. Your ESP will provide documentation, however, as mentioned above, determining how to utilize an API will require learning, experimentation, and time. Software development and systems integration is a notoriously laborious process; don't expect it to be completed overnight.

APIs aren't consistent.

If you change providers, the new provider's API will almost certainly be different than your old provider's.

That means there's some level of lock-in from using an API. Changing will require a carefully managed migration and will incur additional development costs. In some circumstances, there may be a substantial amount of rework and capabilities may simply not be available with a new provider.

APIs are the only game in town for real-time integration.

All this may sound like reasons not to use APIs, however they're the only solution for real-time needs. Their most common use is to trigger real-time transactional or behavioral messages. If you wish to send out such messages you'll need to use an API.

It's possible to use frequent batch process and "drip" messaging for near real time, but it's never going to match an API for immediacy. Furthermore, the complexity of API usage is the systems integration (getting two completely independent computer systems to communicate with each other effectively) and the batch process is really just another form of systems integration and so suffers from many of the same issues.

In the end, APIs provide some extremely powerful capabilities to enhance e-mail marketing programs, however, they're not necessarily an easy path and it takes significant effort to reap the benefits.

Until next time,

Derek