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.