In this post, we’ll cover what an eCommerce API is, why you should use one and how you should evaluate an eCommerce API.
Definition of an API
At a higher level, it may help to understand what an API is before we narrow down on what an eCommerce API is.
The official description of what an API is:
"An application program interface (API) is a set of routines, protocols, and tools for building software applications. Basically, an API specifies how software components should interact. Additionally, APIs are used when programming graphical user interface (GUI) components."
Put simply, an API declares an interface for you to interact with its logic without you having to know what is happening under the hood, masking the complexity and making it easy to consume and use.
What is an eCommerce API
Ok, so now we’ve defined an API at a high level so let’s get down to what an “eCommerce API” is. An eCommerce API is a collection of eCommerce functionality exposed via API, fairly straight forward. To break down the specific eCommerce functionality this includes at the very minimum, cart, checkout, payments and orders - or in other words a way to transact. One point of confusion that we sometimes hear is that a payment gateway is a commerce API, when in reality these providers offer a single service, namely a payments API, eCommerce is a broader journey comprised or more steps.
In headless commerce architecture, eCommerce APIs act as the connecting tissue between the frontend (head) and backend (body).
Why use an eCommerce API
So as we just defined above, APIs allow you to interact with the logic without needing to know what is happening under the hood. This is great for eCommerce because there is a ton of logic that you need to access but at the same time you don’t want to have to handle the complexity that supports all of this logic.
An API is the ideal delivery mechanism for eCommerce because eCommerce logic and functionality can be inherently complex.
This creates a natural split between your frontend and backend operations and the underlying commerce engine. This turns ordinary developers into super-charged developers thanks to increased efficiencies and productivity. No longer do you need an expensive full-stack or proprietary eCommerce platform developer. This allows you to deploy new commerce solutions and get to market faster whilst enjoying access to a wider developer talent pool.
Evaluating an eCommerce API
Not all commerce APIs are created equal.
Below you’ll find some key areas to consider and explore when you come to evaluating an e-commerce API that will fit your business and/or project requirements.
Location & response times
Whether this be for legal, security, or compliance reasons the location of the eCommerce API and it’s databases is something else you will likely need to consider.
While edge caching can certainly ensure your content & data is located close to your end customers, the types of data that can be pushed to the edge can be limited for eCommerce use cases and data and only really works for GET requests (retrieving data). When it comes down to commerce logic and interactions (e.g. the critical purchase path through cart and checkout) this can not be cached. If an eCommerce API is located halfway around the world this can impact latency, your application performance, and ultimately the conversion rate of your store.
You’ll ideally want to ensure the location of your eCommerce API is within or close to the location of your customers and the response rates are below 200-300ms for the most part, although there are some exceptions for more complex queries.
By default the Elastic Path multi-tenant public API is hosted in EU west. If you would like an instance located closer to you and your customer base, please reach out and we would be happy to explore a path forward with you.
API-first or API bolt-on
There is another key difference to be aware of when evaluating eCommerce APIs and that is to go back to understand how the API first came to be.
Many traditional eCommerce platforms did not start out with an API and instead built APIs as a bolt on to their core platform, primarily to enable an ecosystem of third-party integrations. This key difference affects the feature/functionality coverage area of the API in terms of what is available and also how the API fundamentally works as it has to interact with this more closed, restrictive platform core.
On the other hand, API-first means exactly that, the entire product has been designed from the ground up to be consumed via APIs (as Elastic Path has been). This leads to 100% (or close to) coverage in feature functionality.
We usually find that those that adopt an API-first eCommerce service implement their projects far faster than with a solution that uses bolt-on APIs, as there are less workarounds and hacks required to achieve your desired results.
Feature / functionality
So we mentioned in the definition that a commerce API is comprised of a few core elements, products, carts, checkout, payments, and orders. Outside of this core functionality, there are multiple other services that you may need to call upon. Sometimes these may exist inside the eCommerce API itself. A drawback here is that this feature/functionality might be tightly woven into the core services meaning you'll be back to hacky workarounds when you’re looking to branch out to other best in class providers or writing your own logic - for example, you want to replace the tax functionality inside the commerce API with a best in class vendor like TaxJar.
Feature functionality (or the lack of) leads onto the next and arguably one of the most important things to consider when evaluating an eCommerce API.
Interoperability & extensibility
Most eCommerce APIs tend to enable custom data in two different ways. The first is as simple key value pairs which is great if you’re just storing some simple data but can fall short for more complex scenarios as the onus on validation rests entirely with the development. The second way that traditional eCommerce platforms handle customization is on a case by case, specific feature/functionality basis. I.e. How you extend the product catalog is completely different from how you extend the customer record or an order. This greatly increases the learning curve of the platform and slows down development time as you find yourself hopping from one dashboard page, directory, file, or line of code to the next.
Here at Elastic Path we understand that commerce data likely needs to be well defined, structured with data types, and relatable. It also needs to be universal. One single way to implement and easy to pick up, learn, and implement without a lengthy learning curve.
Beyond extensibility of the schema comes interoperability, or in other words the way in which the API integrates with other providers and vendors. With structured custom data as part of the puzzle you also have to look towards how the events and communication work between other best in class services.
The standard here is webhooks, and just like API-first vs bolt-on APIs, the coverage and types of webhooks available can vary wildly. The other more traditional approach is a rigid plugin driven system design which can again lead to hacky workarounds. Webhooks pair up well with a more open and modern integration pattern that revolves around serverless functions.
Here at Elastic Path we have bundled up the concept of structure data, real-time events/webhooks, and serverless functions into what we call Flows. For more on Flows can check out our flows overview page or for more hands, experience follow one of our flows guides.
Developer Experience & Documentation Quality
The quality of the developer experience is another important factor to consider as a poor experience can negatively impact your time to market, significantly increase maintenance and ultimately development cost.
A few key considerations you should explore & questions you should ask when it comes to the developer experience include:
Is the eCommerce API consistent, standardized and human read-able to requests and response objects across all endpoints or is each API endpoint different and require it's own learning curve? i.e. Can a developer read the documentation in a couple of minutes for one endpoint and re-use that knowledge across all API endpoints.
Has the eCommerce logic and complexity been well abstracted or are there multiple endpoints and features spread across multiple requests. i.e. it takes several API requests to process an action that could be handled in a single request. Having to make several round trip calls can slow down implementation and your web application performance.
Are there examples and SDKs in your language available and supporting high-quality accurate documentation to help you onboard quickly?
How easy is it to navigate and browse the documentation to find answers to your questions?
Is there a change log and status page? Knowing when something has changed or when services encounter issues is critical to the smooth operation of your business.
Is there a community forum or ticket-based support system for questions, best practice advice or for when things go wrong?
Is there a high-quality Postman or Paw collection that covers the entire breadth of the commerce API that you can download to rapidly test drive the API?
All of the above questions outlined above around the developer experience will directly impact implementation time and ultimately the development cost. In other words, a positive developer experience will lead to faster implementation times and lower costs whereas a negative or sub-par developer experience will lead to longer implementation cycles and higher costs.
As you can see, when it comes to understanding what an eCommerce API is and how to evaluate what makes a great eCommerce API there are many things to consider. This article is in no way an exhaustive list and is simply some of the top areas you should consider when evaluating an eCommerce API.
Hopefully, this article gave you some insights into how you should approach and think about eCommerce APIs.