Feature: Expose custom identity provider (OIDC) configuration in CustomerAccountsV2 and customer_account_settings_update webhook

GraphQL Admin API Troubleshooting
1

Summary

We’d like to request that the custom identity provider (OIDC) configuration be exposed via the Admin API — specifically in the CustomerAccountsV2 object and the customer_account_settings_update webhook payload.

Background & Use Case

We provide an identity provider (IdP) integration service for Shopify merchants using Customer Accounts. We want to trigger usage-based billing at the point when a merchant activates their custom IdP configuration (i.e., clicks the “Enable” button in the settings).

Currently, there is no way to retrieve the IdP connection status via the Admin API, making it impossible to distinguish between:

  • A merchant who is testing the connection, and

  • A merchant who has completed setup and gone live.

This makes it very difficult to determine the appropriate timing for billing.

Proposed Solution

We’d suggest adding the following fields to CustomerAccountsV2:

type CustomerAccountsV2 {
  # existing fields...
  customIdentityProvider: CustomIdentityProvider
}

type CustomIdentityProvider {
  enabled: Boolean!
  providerName: String
  clientId: String
}

Additionally, it would be ideal if these fields were included in the customer_account_settings_update webhook payload, so that we can react to changes in real time without polling.

Workaround

We are currently not aware of any way to retrieve this information indirectly. If there is an existing method to get the IdP activation status, we’d love to know.

3

Hi @Terao! You’re right - neither CustomerAccountsV2 nor the customer_account_settings_update webhook exposes the custom identity provider config or its activation state at this moment in time.

There’s one adjacent thing worth knowing, though it won’t solve the activation trigger. On the unstable API version, Customer.identityProviderSubjects now returns per-customer IdP links including the providerName. Once real customers start authenticating through the provider they accumulate these subject records, so their presence is an indirect signal that the IdP is live and in use. There are some big caveats though. It only lives on the unstable version, so it’s unsupported and can change. It’s also protected customer data, and it tells you nothing until after the first login, so it can’t fire at the moment a merchant clicks Enable.

Your feature request is well specified, so I’ve logged it as a feature request with the product team for them to weigh against other API work. I can’t promise if or when it would land, but it’s on their radar now. Thanks for raising this with us!

4

Thank you for sharing that!

However, Customer.identityProviderSubjects doesn’t quite address our core need directly. We’re still hoping to see this feature implemented in a future stable release.

5

Hi, @Donal-Shopify

I took a look at the Shopify developer documentation for the CustomIdentityProvider available in the unstable API version.

We’re currently planning to migrate from Multipass to OIDC(with custom identifier provider). I noticed that the Customer.identityProviderSubjects object appears to provide information that could serve as a replacement for the multipassIdentifier property that was available with Multipass, so I’m looking forward to seeing it become available in a stable API version.

I do have one question, though. Are there any plans to add these fields to webhook (REST resource JSON) payloads as well?

Since some webhooks currently include the multipass_identifier property, we will need an equivalent field in webhook payloads to support our migration from Multipass to OIDC.

6

Hi @TaeHee_Kim, thanks for your question. For the per-customer identifier, the current Admin API surface is Customer.identityProviderSubjects. If your goal is to have that value included when another customer event fires, rather than to trigger specifically when the subject changes, then Events is the path to evaluate. Events payloads are GraphQL-shaped and can be customized with a query, so a Customer event payload can select the identity provider subjects.

[events]
api_version = "unstable"

[[events.subscription]]
handle = "customer-with-oidc-subjects"
topic = "Customer"
actions = ["create", "update"]
uri = "https://your-app.example.com/events/customers"

query = """
query customer_with_oidc_subjects($customerId: ID!) {
  customer(id: $customerId) {
    id
    email
    identityProviderSubjects {
      providerName
      subject
      createdAt
      updatedAt
    }
  }
}
"""

The caveats are that Events is currently developer preview on unstable, and this gives you a GraphQL-shaped Events payload rather than adding the field to the existing REST webhook JSON. It also doesn’t create a dedicated trigger for identityProviderSubjects changes. It lets you include that field in the payload for another supported Customer event.

I’ve logged your request for the ID to be included in webhook payloads, but can’t promise if and when they’d be added. Let me know if you try this out!