Retailer API: part one

We’re currently developing an entirely new API that will replace both our current API’s (Order and Offer). This will be the first part of a series of posts. In these articles, we’ll explain what we’re currently developing and why we’ve decided to take a certain route. Not only do we want to inform you through these posts of what’s to come, we also want to give you a peek into our thought and development process.

A new root path

With the transit to our new and modernized API, we will change the root path from “” to “”. We did this because of two simple reasons: The first reason is that we simply want to differentiate from the current API and we want to make it clear that we’re going to stop development on the current API. The second reason is that we’re going to share the root path with another external API (the Open API) and possibly other new external API’s in the future.

Response formats

With the release of the Retailer API, we will support both XML and JSON as response formats. This is a minor modification, but a welcome one for our user base and for us as well.

Adopting an open standard for authentication – phase one

Since the launch of the first API version, we’ve had a custom implementation for authentication. We’re going to abandon it entirely in favour of OAuth 2.0 for the new Retailer API. This means that the current authentication implementation will not work for the Retailer API. You can only authenticate yourself through OAuth 2.0 on the Retailer API. Why did we go this route? Over the years we’ve received a lot of feedback on our custom authentication implementation. And it basically boils down to confusion, frustration and sometimes even endless troubleshooting. This happens because our current authentication implementation can be quite tricky, or fickle if you will. Basically, one little mistake would quickly result in a “Client signature mismatch” error.

However, that’s not our only reason to embrace an open standard for authentication. We’re also investigating the possibility of having scopes inside our authentication. In short, making it possible to have multiple API client credentials for different business processes. For instance, it would then be possible to have one API client credential solely for retrieving your orders while a second API client credential could be used only for updating your stock

In the next blog post, we’ll visit the following subjects

  • Why did we choose to go for an entirely new API?
  • How to continue with future versions?
  • The introduction and the use of SDK’s.

Thank you for reading and until next time!

Geplaatst in Offer API, Open API, Plaza API