A “Shopware gateway” is a specialized communication layer between the shop and connected App Servers.
Each gateway defines a specific integration domain (e.g., checkout, customer context, or in-app purchases) while sharing the same underlying request handling mechanism — a synchronous call to the external App server and direct response processing inside Shopware.
So where do gateways fit in?
There are two main ways to extend the functionality of a Shopware shop. You can use either the Plugin system or the App system.
One of the big advantages of the App system, apart from seamlessly working in all Shopware cloud instances, is the way the business logic of the extension is provided. All code lives on your own server, separate from the shop’s code base. That allows for updates without touching the shop, and vice versa. When upgrading your shop to a new major version, extensions created via the App system are only minimally affected, if at all.
One of the limitations of the App system is the asynchrony of executing functionality. There is more information on that in the documentation, but here is a brief concept: There are events defined within the Shopware core, like “a customer logs in”, or “order cancelled”. You can define webhooks (URL endpoints on your App server) for these, and every time an event occurs, your defined webhook is called. But you only get the information “that thing happened, here is the data”, and are then able to do things on your side or via the shop’s API. You can’t change the logic of how Shopware is processing the event - until now.
Well, technically, you already can do that via App Scripts, but then the logic is in the shop’s code base again. With all the feedback we got from you, we built something to give you the ability to get asynchronous functionality, allowing you to change the logic in Shopware while events occur, all on your App server. We call this addition to the App system: Shopware gateways.
What can gateways do?
In a nutshell, this is how gateways work:
Something happens → Shopware calls your gateway → waits for a response → applies the result.
There are different gateways, and each type serves a specific purpose. All share the same concept of synchronous requests, but differ in how they are triggered, what response they expect and what they can do. At the time of writing this article, there are three gateways: Checkout, Context, and In-App Purchase.
At the time of writing, the context gateway is the most interesting for most extension developers, and also the most powerful one. It can show messages to customers in the Storefront, register new customers, change their language, currency, address, and more.
A full overview is in the documentation for the commands of the context gateway.
How do Gateways work?
Since it is likely the most interesting for the majority of the community, let’s focus on the context gateway. The others work in the same way in that you need to define a gateway endpoint in your App’s manifest file, but differ in how and when they are triggered and what response they expect.
There is an extensive overview with an example in the documentation of the context gateway, but the general concept is quickly explained.
You trigger the context gateway from the Storefront via JavaScript. This can be done whenever you need it, reacting to events in the Storefront or when a button is clicked that you have added yourself. It can be triggered by a timer or whatever you come up with. Also, you can include any custom data in the request that is sent to your App server.
After sending the request, the shop is waiting for a response from your server, expecting a command in the response. The command is executed, and the operation resumes.
Of course, Shopware provides a service in the form of a JavaScript client to make it easier, in addition to the already existing SDKs for App development.
With this concept, using the context gateway is as easy as calling a JavaScript method with some data. All the logic behind that, how you react to the data, is happening on your App server.
What to build with Gateways?
The currently available gateways, as well as their functionality, are based on the feedback we got from you, the community, about the App system.
Taking a look at the command reference for the context gateway, you can see that things like address validation, deciding on payment methods, or single sign-on implementations work well with the gateway.
The thing is: We at Shopware build Shopware. You, the community, build functionality on top of that. So we need to know your needs to create new commands or even new gateways.
The App system is the best way to extend Shopware while having close to zero work with shop upgrades. The more powerful the gateways and the App system get, the less work is spent on upgrading, and more can be spent on building what matters: Functionality that makes your customers' shops better.
We are already planning to expand the gateway system, adding new types for advanced checkout flows such as external tax provider integration or a more granular basket manipulation.
But the future depends on the community. If you have a use case in mind, now is the time to share it!
Make it yours!
We are looking for real-world use cases from developers like you.
If there is a scenario where your App could benefit from synchronous, server-side context handling, tell us! Your feedback helps shape which gateways Shopware adds next.
Share your ideas and needs! Use our feedback portal or create an issue on Github. We really want to hear from you.
