`app/uninstalled` webhook coming in through wrong route

Webhooks and Events
,
1

We recently found out on our app’s dev dashboard that app/uninstalled webhook were failing. Our logs indicate that webhooks are coming in from our old configured webhook route, instead of our current configuration.

Background

Previously, our app used webhookSubscriptionCreate - GraphQL Admin to create webhook subscription for each merchant, where we registered app.example/webhook/shopify/app_uninstalled for our endpoint.

After that, we transitioned to AWS EventBridge integration, defined with shopify.app.toml.

Problem

Our logs indicate that instead of receiving via EventBridge, we received app/uninstalled webhook at app.example/webhook/shopify/app_uninstalled , which we already removed, causing a 404 response.

However, Dev Dashboard shows that the topic is configured with EventBridge.

app_uninstalled_subsc
app_uninstalled_subsc1802×266 18.8 KB

What could be the cause for this?

2

Hey @shunten31, did you manually delete those old subscriptions when you migrated? If not, you can query webhookSubscriptions on each affected shop to find the legacy app/uninstalled subscription and remove it with webhookSubscriptionDelete. The migration steps are outlined here.

TLDR; The reason the old endpoint is still getting hit is that the per-shop subscriptions you created with webhookSubscriptionCreate still exist separately from your new shopify.app.toml config.

3

@KyleG-Shopify Hi, thanks for the reply.

We actually did the migration steps when we transitioned to app-specific subscriptions.

We looked in our migration logs and found out that the merchant (shop domain) returned 402 Payment Required / "Unavailable Shop" for our webhookSubscriptionDelete requests at that time.

So it seems that the shop domain was unavailable at that time, but then it came back and uninstalled our app? :thinking: Was this an unlucky edge case, or was there something we could do better?

4

Thanks for sharing that. That would explain it if the merchant was on a frozen plan at the time as that API request wouldn’t have gone through.

It couldn’t hurt to do a query for webhooksubscriptions across all of your shops to see if there area any other outliers that can be deleted.

You can also subscribe to the shop/update webhook to watch for plan changes on those shops that are reactivating after being paused or frozen.