Understanding APIs - the building blocks connecting your marketing systems
What’s an API?
A.P.I is an acronym for Application Programming Interface.
An API can be private or made available for use in the public domain and any accompanying documentation specifies what services are available and how they are to be used.
What does an API do?
In layman terms it offers developers access to the various building blocks (definitions, classes, variables, routines, structure, protocols and calls) that were used in the creation of a software application, this further allows for bespoke implementations and integrations according to need (and author granted permissions). Simply, it lets one system connect, communicate and exchange data sensibly and meaningfully with another system (often this means accessing the functionality from something else, built by someone elsewhere, with usage being made in a different application). In the most simplified terms, it makes a request from one system to another and returns the requested data/function.
Most services used online today will in some way be making use of many API calls between various systems. Imagine you’re booking a train ticket online. That actual service requires information coming from many disparate systems owned by different organisations; e.g. the train company, the rail network operators, their ticketing and CRM system, payment gateway and banking systems; with all these connections being presented through the website GUI (Graphical User Interface) where you as a user actually make your ticket booking. This offers a slightly different way of mentally visualising a website, and further reinforces why the internet is known as the ‘web’.
How can an API be used?
An API, by extension, opens the potential of a product not only to better integration and provisions of functionality for inter-operability between systems, but a product’s API opens new and potentially previously unknown markets. An API also erodes the need for developers to re-invent the wheel and code something from fresh every time they want to implement a new service.
Is an API and a native integration the same thing?
Arguably they are two different flavours of the same thing. A native out-of-the-box integration (e.g: e-shot to SalesForce) can help to save time and should require less technical expertise to implement, where as a developer who makes full use of available API for a particular system will have greater flexibility to satisfy their actual requirements.
Is there a difference between an API and an SDK?
An SDK (Software Development Kit) is somewhat of an API on steroids although it does have its own distinction. The former likely contains the later, but never vice versa – and one SDK may contain many APIs.
As the name suggests an API is just an interface to another platform, accessing existing functionality and transferring data.
An SDK contains additional tools including a compiler and interpreter. These allow developers, (possibly starting from scratch), to build an application for a specific environment or platform. Ergo building a mobile app for both Android and Apple require using the relevant (mobile) SDK for each platform. These also contain the necessary APIs that allow databases to communicate and provide the services and data exchanges the app may require.
What Types of APIs exist?
I read somewhere once that SalesForce and eBay were the pioneers in releasing web-based APIs to allow developers to customize those applications to need. I suspect this reference is specific to the public and commercial arena.
Two of the more popular API methods today are SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). SOAP uses a standardized protocol that sends requests using another standardised protocol e.g. HTTP (Hypertext Transfer Protocol) or SMTP (Simple Mail Transfer Protocol) but only allows data transfer via XML (Extensible Markup Language) packets. All operating systems can work with the HTTP web protocol, this offers universality.
Rather than an official standard, REST is a set of architectural guidelines that give greater flexibility for coders and was developed as an evolution to SOAP that as a standardized offer is less flexible, has more built-in security elements, is more complex and heavier on system load. REST addresses much of this and is generally the more popular choice for interfacing across web services and can transfer data in differing formats other than XML, including; HTML, and the popular human-readable JSON (Java Script Object Notation) format. The JAVA programming language itself has many public APIs.
What are the risks in using an API?
Here in our offices at e-Shot we have a little quotation on one of our notice boards,
“Life’s too short for bad software code” ...enough said!
An API essentially exposes a system, which naturally adds concerns about security compromises or data theft. A verification method often used in cryptography is key pair combinations, one usually public and the other private and when a key pair is resolved the certificate is authenticated.
An SSL (Secure Sockets Layer) certificate (more generally known as TLS - Transport Layer Security) is issued by an authority and contains the private element along with the information pertaining to the certificate’s real owner. Inadequate SSL validation is always a risk, and hackers can validate invalid certificates via certain nefarious methods or infiltrate a network using e.g. XML and SOAP with malicious intent, and hence the importance of SSL/TLS certification in the first place. SSL applied to a website essentially turns the URL from HTTP: to HTTPS, making it secure, i.e
General complacency and not tracking the number and usage of any API integrations could expose a company to potential security risks and surmounting charges. It is it well worth fully appreciating the terms of service and any commercials from the provider of the API.
The release of an API where previously none was available will also require supportive considerations regarding infrastructure to handle the increased calls and transactions that will take place across your network.
As an API involves transfer of data that may be sensitive or relate to individuals and governed by legal regulation or statute, the management of policies covering various aspects from user rights and access to performance and security governance, even data transfer permissions, is a foundational element of API management.
What alternatives to using an API exist?
Integration hubs, such as Zapier, are tools that make working with APIs generally much easier for those less technically gifted, much of the integration work having been done up-front by developers leaving just a simpler field mapping exercise for users creating integrations with such tools.
Email marketing healthcheck
We are confident that we can help you, which is why we offer a free healthcheck to identify potential issues with your current programme and free advice on things that could be done to improve it.