A Marketer's Guide to APIs

Six key points e-mail marketers should understand about APIs.

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

Subscribe to get your daily business insights

Whitepapers

US Mobile Streaming Behavior
Whitepaper | Mobile

US Mobile Streaming Behavior

5y

US Mobile Streaming Behavior

Streaming has become a staple of US media-viewing habits. Streaming video, however, still comes with a variety of pesky frustrations that viewers are ...

View resource
Winning the Data Game: Digital Analytics Tactics for Media Groups
Whitepaper | Analyzing Customer Data

Winning the Data Game: Digital Analytics Tactics for Media Groups

5y

Winning the Data Game: Digital Analytics Tactics f...

Data is the lifeblood of so many companies today. You need more of it, all of which at higher quality, and all the meanwhile being compliant with data...

View resource
Learning to win the talent war: how digital marketing can develop its people
Whitepaper | Digital Marketing

Learning to win the talent war: how digital marketing can develop its peopl...

2y

Learning to win the talent war: how digital market...

This report documents the findings of a Fireside chat held by ClickZ in the first quarter of 2022. It provides expert insight on how companies can ret...

View resource
Engagement To Empowerment - Winning in Today's Experience Economy
Report | Digital Transformation

Engagement To Empowerment - Winning in Today's Experience Economy

1m

Engagement To Empowerment - Winning in Today's Exp...

Customers decide fast, influenced by only 2.5 touchpoints – globally! Make sure your brand shines in those critical moments. Read More...

View resource