Photo: free stock photography (Unsplash licence) — see imprint
The registration handshake
When a shop installs your app, Shopware calls your registration URL, you answer with a proof and a shop secret, and Shopware confirms. Get this wrong and the app installs but never receives an event — with no obvious error anywhere. Log both sides of the handshake from day one.
Verify every request, without exception
Every webhook Shopware sends is signed. If you do not verify that signature, your app server is an open endpoint that anyone on the internet can use to move your customers' orders around. This is fifteen lines of HMAC code and it is not optional.
One app, many shops
Your server will hold credentials for every shop that installed it. Store the shop ID, the shop URL and the secret as a proper record, and never let a webhook from shop A touch data from shop B. Multi-tenancy bugs in an app server are the kind that end up in the press.
Answer fast, work later
Shopware expects a quick HTTP response to a webhook. Do not do the ERP sync inside the handler — acknowledge, push a job onto a queue, and let a worker do the real work. Otherwise a slow supplier API becomes a timing-out shop.
- Log both sides of the registration handshake.
- Unverified webhook signatures = open endpoint.
- Acknowledge fast, queue the real work.
Frequently asked questions
Almost always a registration handshake that half-succeeded. The shop calls your registration URL, you answer with a proof and a shop secret, and the shop confirms. If any step is wrong the app still appears installed and simply never gets an event — with no error to find anywhere. Log both sides of that handshake from the first day; without it you are guessing.
Yes, and there is no reasonable argument on the other side. Shopware signs every webhook it sends. An app server that skips the check is a public endpoint that lets anyone on the internet push events about your customers' orders. It is a small amount of HMAC code, it belongs in middleware so nobody can forget it on a new route, and it is not a nice-to-have.
Treat every shop as a proper tenant record: shop ID, shop URL, secret. Then make it structurally impossible for a webhook from one shop to touch another shop's data — scope every query by the tenant you just authenticated, never by whatever ID happened to arrive in the payload. Multi-tenancy bugs in an app server are the kind that get written about.
Fast enough that the shop is not waiting on your suppliers. Acknowledge the webhook, put a job on a queue, and let a worker do the ERP sync or whatever else takes seconds. If you do the real work inside the handler, every slow third-party API you depend on turns into a timing-out shop — and the retries that follow make it worse, not better.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer