Introducing Customer Account API tooling

[scottdixon]

Hydrogen now includes a built-in client for interacting with Shopify's Customer Account API, which allows customers to have a consistent, logged-in experience across Liquid online stores, Hydrogen, and checkout. Because of its strong privacy focus, the Customer Account API has to be accessed over a secure HTTPS connection, even in development.

To make this development process easier, we've introduced automatic SSL tunneling in the Hydrogen CLI, available today as an unstable preview. The dev server will automatically start a tunnel through our secure tryhydrogen.dev domain, and sync all the required credentials with your Shopify store.

Try it out today: run npx shopify hydrogen dev --customer-account-push__unstable and be sure to share your feedback.

[jamalsoueidan]

** ...which allows customers to have a consistent, logged-in experience across Liquid online stores, Hydrogen, and checkout. **

Didn't work on fresh new hydrogen

[blittle]

Hi @jamalsoueidan could you please create an issue with steps to reproduce the problem? I've been unable to do it on our end.

[jamalsoueidan]

To get it to work!

Go to your Shopify admin > Settings > Customer Account:

You should be using New customer accounts version in order for checkout logged in to work

[aprkpnk]

hello! which version of "@shopify/hydrogen" is supporting the update and what are needed dependencies and their versions?

[frandiox]

You can upgrading with the h2 upgrade command. The latest version (2024-0 and cli@8) support these features.

[jamalsoueidan]

Why did we remove the email from the new customer Api, i tried to request it using emailAddress object but didn't work either.

[michenly]

I see you are talking about the removal of the email input field from customerUpdate mutation when going from SF API to CA API.
I was confuse myself at first doing the switch, however, this is purposeful.

With the password-less customer account login flow, email/phoneNumber are being use as identification for buyer during login.
This means changing email/phoneNumber is a much higher security risk and has legal concern. The Customer Account team's decision is to remove this capability.

There might be a gap in terms of customer migration from the old system to new. My suggestion would be to send your existing customers communication to inform them of the new passwordless flow and offer one last chance to change their email/phoneNumber before certain date.

[jamalsoueidan]

It would have been better to keep those fields, and just disable them, meaning they cannot be changed.

[michenly]

those field was remove from the mutaiton input but is still queryable. I am not sure what disabled in a graphql query input perspective would mean.

Is deprecated what you are looking for maybe? but since CA API is brand new, there is no such thing as deprecated since the input never existed in this API

[jamalsoueidan]

@michenly

We are crossing each other.

1. In the UI their was email and phone number you can update, and they are removed since you can't update these information anymore. What I'm suggesting is that they should have been kept in the UI and just being disabled, so the user can still see them.

2. My first comment was that even when I add

query CustomerDetails {
  customer {
    id
    emailAddress {
      emailAddress
      marketingState
    }
  }
}

I was not abel to get the emailAddress, but I will give it another shot again, just to confirm and be 100% if it will work or not :)

[michenly]

In the UI their was email and phone number you can update, and they are removed since you can't update these information anymore. What I'm suggesting is that they should have been kept in the UI and just being disabled, so the user can still see them.

I actually disagree, the audience for the skeleton template is for someone to scaffold a brand new Hydrogen project. For a brand new project, since the email is not editable, displaying email on an "editing" page only invite more questions.

We did however, keep the UI for displaying email in our demo-shop to demonstrate a UI where the displaying & the editing of the customer details are very de-couple.

Our internal rules of thumb had been, if the feature is used by 90%+ of the merchant we will add it into the skeleton. If its not used by 90%+ but is complex to set up then we will add an example. Adding a display of email address back into the template is easy enough, but I would like to hear some more reasoning on why this feature is necessary.