Customer account extensions and the logged-in experience

For years the account area was the part of Shopify you could not really touch. You got an order list, an address book, and a page nobody designed. New customer accounts changed the model: instead of templates you override, there are defined integration points on the order index, order status and profile pages, and apps extend them. Shopify’s own list of what merchants build there is wishlists, subscriptions, rewards, and self-serve order actions like requesting a return or leaving a review.

It also changed how customers get in. New customer accounts use passwordless authentication — the customer enters an email address and receives a one-time six-digit code — with additional sign-in options including Shop Pay, Google and Facebook. That removes the forgotten-password dead end, which is the single biggest reason account areas went unused.

Extensions get a shopify global rather than direct DOM access. shopify.order gives order data, shopify.authenticatedAccount gives customer identity, and shopify.navigation.navigate() moves between pages. Beyond that there are the Metafields API, the Customer Account API, the Storefront API and the Session Token API — the last of which is how you prove to your own back end who the caller is.

Metafield access covers customer, order, product, variant, cart, company, companyLocation and shop resources. That company pair is quietly the most interesting entry on the list, because it is what makes a B2B account area buildable: a buyer’s company, their location, and the data you have hung off both.

Two gates worth knowing before you scope anything. Extensions that access customer data need approved access to protected customer data, and Shopify states that directing customers to pre-authenticated order status pages requires level 2 permission for protected customer data. Neither is exotic, but both are approvals with a lead time, and neither belongs in the last sprint.

Extensions run in an isolated sandbox with limited access to global web APIs, and they build from Polaris components rather than your own CSS. That is a deliberate trade: you get an interface that matches the rest of the account area and keeps working when Shopify changes it, and you give up pixel control. Anyone expecting to reproduce a bespoke design system inside a customer account will be disappointed, and should be — an account page that looks like a different product than the checkout is not a win.

The bundle limit is the constraint that actually bites. Shopify documents a 64 KB maximum compiled bundle, or 128 KB for full-page extensions. That is generous for a panel and tight for an application. It rules out dragging in a chart library, a date library and a state manager, and it rewards fetching from your own API over shipping logic to the browser. If your design does not fit in 128 KB, the answer is usually that too much of the product is living in the extension.

Most stores should leave the account area alone, and this is the section we would rather you read than the previous three.

Ask one question first: what proportion of your orders come from a customer who logged in, and how often does the same customer come back? For a brand where the typical customer buys once a year, the account page is the least-visited page on the site. Rebuilding it is work with a denominator near zero, and the same budget spent on the product page, the collection pages or delivery expectations will move revenue instead.

The businesses where it genuinely pays are the ones where the account is the product surface. Subscriptions, where the account page is where somebody skips, swaps or pauses instead of cancelling by email. B2B, where a buyer needs their company’s price list, their locations and their reorder history in one place. Consumables and high-frequency categories, where a one-tap reorder of the last order is the whole retention strategy. Service-shaped commerce, where an order has a status that changes — bookings, made-to-order, repairs.

There is also a cheap middle path people skip. Self-serve returns and reordering are features of new customer accounts, not things you have to build. Turning those on, tidying the notification emails, and making sure the login link in them actually lands somewhere useful costs a fraction of an extension and captures most of the support-ticket saving. Do that, measure whether anybody uses it, and only then build.

Scope it as an app project, because it is one. Extensions ship inside an app, which means an app to create, a CLI to work with, versioning and releases, and a merchant install step — even when the merchant is you. Teams that treat it as “a page on the site” discover the app scaffolding halfway through and lose a week to it.

Then build the smallest useful version. One block on the order status page that answers the question your support inbox gets most, or one full-page route that replaces one email thread. Ship it, look at whether anyone opens it, and let that decide whether the second one exists. An account area with one thing people use beats a dashboard with six they do not.

• Shopify store development
• Subscriptions on Shopify
• Theme app extensions