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,
Twitter Canada MD Kirstine Stewart to Keynote Toronto
ClickZ Live Toronto (May 14-16) is a new event addressing the rapidly changing landscape that digital marketers face. The agenda focuses on customer engagement and attaining maximum ROI through online marketing efforts across paid, owned & earned media. Register now and save!
Derek Harding is the CEO and founder of Innovyx Inc., a member of the Omnicom Group and the first e-mail service provider to be wholly owned by a full-service marketing agency. A British expatriate living in Seattle, WA, Derek is a technologist by background who has been working in online marketing on both sides of the Atlantic for the last 10 years.
Marketing Apps for Landing Pages White Paper
Marketing apps can elevate a formulaic landing page into a highly interactive user experience. Learn how to turn your static content into exciting marketing apps.
Redefining 'Mobile-Only' Users: Millions Selectively Avoid the Desktop
A new breed of selective mobile-only consumers has emerged. What are the demos of these users and how and where can marketers reach them?
March 19, 2014