I’m the Product Owner for Sky Pilot, a digital delivery app, and I’m reaching out because we’ve hit a wall with a really strange synchronization issue for one of our merchants. We’ve done a lot of digging, but we’re seeing some behavior that has our Dev Team (and me!) a bit stumped.
To give you the full picture, here is how our app handles delivery:
Regular Orders: A file is attached to a product in our app. The moment a customer completes their order on a merchant’s store, Sky Pilot generates a download URL (a Shopify proxy page) and sends the customer a branded email with an “Access Files” button. When they click the button, they are taken to the download URL and can download their files. This is working perfectly.
Subscription Orders: This is slightly more complex because it relies on a bridge between a 3rd-party subscription app and Sky Pilot:
Merchant Setup: The merchant configures their subscription app to add a specific tag (e.g., active_sub) to a Customer’s Profile in Shopify when they have an active subscription.
Sky Pilot Setup: The merchant attaches the files to a subscription product and adds that same tag (active_sub) to the plan settings.
The Sync: Sky Pilot listens for the customers/update webhook. When Shopify notifies us that the customer profile has been tagged by the sub app, we grant access to the files.
The Delivery: Just like regular orders, the customer completes the order (subscribes to the product), receives our email, and clicks the “Access Files” button.
The Logic: If the webhook successfully syncs the tag, they see their files. If the webhook is never received, Sky Pilot sees “no tag” and assumes the subscription has been canceled or has lapsed. Because the app thinks the subscription is no longer active, the customer is met with an “Expired Subscription” message on the download page.
Now, when it comes to the issue for this specific merchant, the bridge mentioned above seems to be broken because the webhooks are missing. After investigating the logs between January 7 and January 9, 2026, here is what our developers found:
Missing Webhooks: They checked the activity logs and did not find any customer tag added/removed webhooks triggered at the time these subscription orders were created. It appears the webhooks were simply not delivered to our app.
API vs. Manual: This doesn’t affect every scenario—manual tag updates in the Shopify Admin do trigger the appropriate webhooks correctly. However, for these subscription-related updates (where the sub app updates the tags via API), the webhook events are missing.
The Discrepancy: The Shopify Admin shows several subscription tags on the customer profile, but our internal admin shows no subscription tags because we never received the signal to sync.
We need immediate access at order completion. A daily background sync doesn’t work for us because if a customer clicks that “Access Files” button right after paying and sees an “Expired” message because the webhook is missing, it’s a failed experience for the customer and a major headache for the merchant.
Does anyone know why an API mutation for a customer tag (coming from a sub app) might not be triggering a standard webhook broadcast? We’re trying to confirm if this is a known issue related to subscription-based tag updates.
As a final note, only one merchant is facing this; we haven’t had any issues with anyone else.
Hey @nejla - I think @Eric_Han ‘s idea is great as a workaround if you haven’t tried it yet.
For the issue with the tags seemingly not triggering your webhook subscription, do you know how and when the subscription app is adding the tags to the customer profile? Specifically, is it happening immediately at checkout or is there a delay? Also, can you confirm that Sky Pilot’s webhook subscription for customers/update is still active for this specific store? That would help us rule out whether the issue is on the webhook delivery side or if the tags aren’t being written as expected. Happy to dig into this to help if needed.
@Eric_Han We already use the customer.tags_added and customer.tags_removed webhooks to sync customer tags. The issue is that when tags are added, we do not receive the customer.tags_added webhook. Instead, we only receive the customers/update webhook. According to the expected behavior, we should receive both webhooks: customers/update and customer.tags_added.
@Alan_G I believe the subscription app (Loop Subscriptions) is adding tags to the Shopify Customer Profile immediately after checkout. In our normal testing (creating a test Shopify Order for a subscription product), we’ve never noticed a delay longer than one or two seconds. We’ve worked alongside Loop for a long time and haven’t seen this behavior before.
It’s possible there is something specific to their setup, but because our logs show the webhooks are missing entirely at the time of the event, we wanted to start here to rule out a platform-level broadcast issue.
Regarding the second part—yes, I can confirm that the customers/update webhook subscription is active for this specific store (552e47-2.myshopify.com). Our developer checked and confirmed we are still receiving webhooks for manual tag updates in the Shopify Admin. It is only the API-initiated updates from the sub app that seem to be “silent.”
The worst part of this investigation is that after several days, the two orders we were tracking (#19564 and #19565) are now finally showing as accessible. This implies that while the webhooks were missing from our logs during the Jan 7–9 window, they may have been delivered with a massive delay, or the system eventually synced. However, for a digital delivery app, a delay of days is a total failure for the customer.
Thanks @nejla , I appreciate the extra info here. When you mentioned that those orders are now showing as accessible’, just out of curiosity, do you know how that happened? Did you eventually receive the webhooks (delayed), did a background sync on your end pick it up, or was there any manual intervention? Trying to understand if the webhooks came through late or if something else resolved it. I think my next step will be to investigate things on our side with the info you shared, but just wanted to confirm this first.
@Alan_G regarding the orders showing as accessible—that was almost certainly due to manual intervention. The merchant has been performing their own tests by removing and re-adding tags to get customers back in while we investigate.
As our developers confirmed: manual tag updates in the Shopify Admin trigger the appropriate webhooks correctly. However, for the automatic API-initiated updates (via the subscription app), the customer.tags_added webhook events are missing entirely.
I also wanted to clarify our setup to skip the standard configuration checks. We migrated to the dedicated tag webhooks mid-last year and use them reliably across all other stores. We are currently listening to:
customer.tags_added
customer.tags_removed
customers/update
The issue is that for these API-driven events on this specific store, we might receive the customers/update payload, but the customer.tags_added webhook is never broadcasted to our endpoint.
Our developers asked me to share these specific logs with you from the January 7–9 investigation window as well:
To reiterate, the specific orders we used for this troubleshooting were #19564 and #19565, but I am currently in touch with the merchant to run two more fresh test orders today so we have up-to-the-minute data.
Please let me know if you’d like me to notify you here as soon as I have those new order numbers!
@Alan_G Hey, hope you’re well! Just wanted to check in and see if you’ve had any luck digging into those logs?
I know these things can be a bit of a rabbit hole, so just let me know if you’ve found anything yet or if you need any other info from our side to help narrow it down.
Hey @nejla - thanks for following up. Still looking into this, but I’ve reached out to some folks internally to investigate further. I’ll keep you in the loop
Hi @nejla - just following up here. I spoke with our developers and they confirmed that webhooks should be triggering for API-created tag updates on customers. From the screenshots of the logs there, could you let me know whether the customer.tags_added event on Jan 7 at 2:45 PM (and any other tag events in that window) was triggered by an API mutation or a manual change in the admin? Trying to verify if API-initiated tag changes are actually emitting webhooks as they should be. Thanks again for your patience on this, it’s appreciated!
@Alan_G, that specific event at 2:45 PM was almost certainly a manual update.
The merchant has been jumping into the admin to manually add/remove tags as a workaround to get their customers back into the system while we troubleshoot. This aligns exactly with our findings: manual changes in the admin trigger the customer.tags_added webhook as expected, but the automated updates performed via the subscription app’s API are being suppressed or skipped entirely.
This seems to be the core of the issue—the “pipe” is open for manual actions, but the event broadcast isn’t firing for these specific API mutations.
Hey @nejla thanks for confirming that, this is really helpful. So we know the webhook pipeline is likely working for manual admin changes,. I do think we’d need to look into what’s happening on the API mutation side when Loop adds those tags.
Could you check with Loop Subscriptions on exactly which API method and version they’re using to add the tags? Specifically whether it’s the REST PUT /customers/{id}.json endpoint, the GraphQL tagsAdd mutation, or customerUpdate, that distinction could change how events are emitted..If they’re able to share any request/response logs (specifically a request ID from the response headers for an example) for one of the affected orders that would be super helpful too, just so we can trace a specific event end to end.
I know you mentioned running fresh test orders as well, if you’re still able to do that, having a clean test case alongside Loop’s API details would make it a lot easier to pinpoint what’s going on. Hope to hear from you soon.
