October 27, 2026 · Muhammad Rehan · More by Muhammad Rehan
Shopify's identityProviderSubjectDelete, Explained
Shopify's new mutation unlinks a customer from an SSO identity provider and signs them out everywhere — but it isn't a permanent block. Here's why that matters.
A new mutation, narrower than its name suggests
Shopify's changelog entry for October 23, 2026 introduces identityProviderSubjectDelete, a GraphQL Admin API mutation shipped in API version 2027-01. It lets you unlink a customer from a third-party identity provider — the kind of federated SSO link enterprise and B2B storefronts use when customer accounts authenticate through an external provider rather than Shopify's own login. The name reads like a hard disconnect. It isn't one. Read literally, the mutation's documented behavior is a session reset with an automatic re-link attached, and that distinction matters a lot if you're building an offboarding or incident-response flow around it.
What the mutation actually takes and returns
The mutation requires the write_customers access scope and takes two arguments: customerId, the ID of the customer the subject belongs to, and id, the ID of the identity provider subject to delete. That subject ID doesn't come from the customer record directly — it comes from Customer.identityProviderSubjects, an array of IdentityProviderSubject objects (gated behind read_customers) that each expose providerName, the merchant-configured name of the identity provider; subject, the unique identifier the provider assigned to the customer; and createdAt / updatedAt timestamps. In practice, that means a real integration reads identityProviderSubjects first to find the right subject ID, then calls identityProviderSubjectDelete with it. On success, the mutation returns the customer, a deletedIdentityProviderSubjectId, and the standard userErrors array.
Sign-out now, re-link on next sign-in
Shopify states this plainly: unlinking signs the customer out of all of their existing sessions, and the next time they sign in through that same identity provider, they're linked again. So the mutation does two real things — it immediately terminates every active session, and it removes the stored provider-subject link — but the link isn't gone for good. It reforms automatically the moment the customer authenticates through that provider again. There's no flag or state that blocks the relink from happening; the mutation simply deletes the record, and Shopify's own sign-in flow recreates it on the next successful authentication.
Where this belongs in an incident-response toolkit
That makes identityProviderSubjectDelete genuinely useful for one specific case: forcing re-authentication. A lost device, a suspected session compromise, a support ticket where you just need every existing session dead right now — this mutation handles that cleanly, without touching the customer record, order history, or anything else about the account. What it can't do on its own is serve as an offboarding control. If the goal is to permanently cut a customer off from signing in through a specific identity provider, this mutation alone won't hold that line, because the next successful sign-in just re-establishes the link. A real, durable block has to happen on the identity provider's side — revoking the customer's access there — which is outside what this Shopify mutation does. Treat it as a session-hygiene tool that buys you time, not a permanent switch.