Shopify is recommending using managed webhooks via the app’s TOML file. This seems problematic when it comes to shops who have not uninstalled the app but their free trial is over, or shops they have canceled their subscription. These shops can generate 10000s of hooks for events like products/update, which has a CPU cost or, when using services like AWS Event bus, higher monthly payments.
When you consider other webhooks these shops generate, you could be looking at 100K+ webhooks a month.
Normally for these shops we would remove their webhook subscription but if managed webhooks are now recommended how is it recommended to deal with this problem? As is we’d have to accept the webhook and the higher costs only to not process it.
You’re right, this is a real pain point with managed webhooks if you have a lot of inactive but not uninstalled shops. The core issue is that as long as the app is installed, Shopify will continue to send those managed webhooks, regardless of the shop’s subscription status with your app.
The most practical approach to mitigate the cost is to implement a very early check in your webhook handler. As soon as a webhook comes in, extract the X-Shopify-Shop-Domain header. Before doing any processing, database lookups, or pushing to an event bus, check your own database for that shop’s status. If the shop’s trial has expired or their subscription is canceled, immediately return a 200 OK response and exit the handler without doing anything else.
This won’t prevent the webhook request from hitting your endpoint (you’ll still incur the minimal cost of the HTTP request and the initial handler invocation), but it will prevent all subsequent, more expensive processing, like pushing to AWS Event Bus, database writes, or any complex business logic. You’re essentially accepting the webhook but immediately discarding its payload if it’s from an inactive shop.
For shops that are truly abandoned and not just temporarily inactive, the only way to completely stop receiving webhooks is for the app to be uninstalled. Some app developers implement a “deactivation” flow where, after a certain period of inactivity or failed payments, they might prompt the merchant to uninstall or, if their terms allow, trigger an uninstall themselves (though this is rare and generally not recommended without clear consent or policy).