Issue: After a fulfillment service’s webhook/callback fails and hits the max retry limit (100000), Shopify stops sending fulfillment requests. Updating the service with a new callback URL does not resume requests. Deleting/recreating the fulfillment service is highly disruptive (products must be moved between locations and shipping profiles).
Key terms:
Fulfillment service: a third‑party service that ships orders for a merchant.
Callback/webhook: the endpoint Shopify calls to send fulfillment requests.
Order GID: the unique global identifier for an order.
Shopify response:
No current self-serve workaround beyond removing and re-adding the fulfillment service.
Possible case-by-case contingencies: provide an affected order GID privately for investigation.
Recommended to contact Partner Support via the Partner Organization dashboard to engage technical teams.
A feature request will be filed to enable more efficient “re-registration” after failures (no guarantees).
Additional input: Another participant requested the ability to resuscitate failed callbacks.
Status: Unresolved/ongoing. Next steps depend on Support escalation; no built-in way to resume without deleting the location at this time.
The new fulfillment service API’s doesn’t have documentation on how to handle new registrations of fulfillment services after they’ve been errored out. It’s an edge case, but can sometimes happen unexpectedly.
“Fulfillment requests from shop [host] to fulfillment service [service_name] failed. The maximum number of retries (100000) has been reached and the request will not be retried.”
If I register an update to the fulfillment service on the merchant’s store with a new callback url it won’t resume submitting fulfillment requests to the service.
Deleting the fulfillment service and re-creating it would really hurt a merchant’s storefront as every single product would have to be moved to a new location, moved out of a shipping profile, and then migrated back into the new shipping profile.
Is there any way we can resume fulfillment requests without deleting the entire location?
Hey @keiraarts - definitely understand where you’re coming from here in terms of use-case. You’re right that it most likely won’t happen too often, but it could happen by accident (let’s say your fulfillment app handles massive volume and goes down for a few hours, etc.). At the moment, you are correct that there isn’t a workaround on the partner/3P development side of things other than removing the fulfillment service from the shop and then re-adding it like you mentioned - this could be a big blocker for you and the merchant for sure.
That said, we do sometimes offer contingencies in certain cases. I can’t guarantee anything specifically - but if this is currently an ongoing issue for you, could you share an order GID for an order that returned the error, that we can use to look up the relevant info (just don’t want to share private merchant information on the forums here)? I’d be happy to get in touch with our product team to take a look if that’s the case here.
The other recommendation I’d have is that if you do encounter an issue like this in the future, reach out to our Partner Support team through your Partner Organization dashboard and they can get in touch with one of our technical teams who can then take a deeper look and see if there’s anything we can do on our end to streamline things (so that you and the merchant don’t necessarily have to “rebuild” everything to get fulfillments up and running again). I’m also going to put through a feature request for our product team to consider offering a way to “re-register” fulfillment services more efficiently in cases where something like this might happen. I can’t guarantee anything on that front either, but happy to put through a report, so we have it on the radar as well.
Hope this helps - let us know if we can clarify anything further on our end.