A hub with endless possibilities: the dynamic API layer

Fortunately, digital business operations have already become implemented in many organizations. Companies have been working for longer than today with multiple programs that make life better for their customers and themselves. In my opinion, the real added value lies in connecting those tools, both internally and externally. A true digital ecosystem. But before you can get started, you need an intermediate piece: a dynamic API layer.

Such an intermediary layer is important to make an ecosystem viable. But why is it so important?


You want to be able to manage your offer digitally, and this requires collaboration with several partners. Suppose you are a logistics service provider (3PL) and deliver packages and want to connect to various webshop platforms such as Shopify, Magento or WooCommerce.


In order to achieve this, the creation of integrations is necessary. You want to link with multiple players, so this seems like a big investment at first sight. That's why you might consider pairing with certain partners and not pairing with some. And who will bear those costs? After all, if you have many different customers, each with their own platforms, it will cost too much to build those links individually.
You want to be as flexible as possible towards your customers and at the same time reduce costs, which is why it is interesting to build an intermediate layer, the dynamic API layer. In this case you build a layer between your own logistics software and all possible partners.

On the left you see the existing solution, and on the left of the API layer you provide connections that do specific controls. For example, request orders, follow up, create invoices, ... These are a number of standardized API calls, and this side of the layer does not change in principle.


On the right side are all the different external partners. Instead of providing a new layer for each player, you now work with intermediate blocks. Like those large Lego building plates from the past, instead of plate per customer, you are now going to make 1 standard base plate and we make it dynamic by clicking in a small Lego block for each partner. The only thing the Lego brick does is make the translation between the language of the partner and the common language of the API layer.


The last yellow block is a general block, or generic block that you offer with documentation, so that partners can link to it themselves. Then you put the ball in someone else's court, by making the block simple and documented. In this way, developers can quickly get started with connecting to their own software.


A comparison I like to make is with large multicultural organizations, such as the United Nations. There are several interpreters there, who may not directly translate Mandarin into Spanish, or Hindi into Dutch, but use English as an intermediate language. Instead of having a lot of interpreters interpreting from specific language to specific language, we will use a standard intermediate language: English. This way you can see a Dynamic API layer.
The flexibility of such an API layer means that you can scale faster and it is so much easier to click in new things.

Other insights

Expert Talk: De democratisering van AI

In de reeks Expert Talks, bevragen we verschillende thought leaders in de IT-sector. Deze keer spreken we Jonathan Berte van RoboVision. Hij vertelt over artificiële intelligentie en waarom de democratisering ervan nu net zoveel aan belang wint.

Customer Behaviour Analysis

A 'customer behavior analysis' may sound complicated, but the bottom line is that what you do online as a customer is mapped. And that in turn leads to interesting and substantiated insights into your market.

Do you want to work with us?