How the two services split the work
AuthenticationService(client.auth) owns identity and sessions: register, log in, log out, password reset, OTP, magic links, session refresh, and a “who am I?” check (getCurrentUser→ returns the user id and a few identifying fields).CustomersService(client.customers) owns the customer profile resource: provision a customer record, read the full profile (with addresses, store metrics, purchase history, status), update profile fields, and link to an external identity viaexternal_id.
CustomersService. The auth service resolves who the customer is; the customers service holds what the customer looks like.
Where Path A and Path B differ is how you prove the caller is the customer when calling CustomersService:
Any one of these headers authorises the same operation. The customer-self endpoints (
getCustomer, updateCustomer) accept all three — you pick whichever matches your integration. Bring-your-own-auth comes in two shapes that differ only in who checks the identity-provider token: with xExternalAuth, your backend verifies the shopper’s login and signs a short assertion Galactic Core checks; with xIdpToken, you hand Galactic Core the raw token and it asks a verifier you run to confirm it (see the two BYO-auth modes below).
The two paths
Path A — Galactic Core handles auth
UseAuthenticationService (client.auth) for registration, login, password resets, OTP, and session refresh. Each successful registration also creates the customer record automatically — you don’t call CustomersService for creates.
Best when:
- You’re building a storefront from scratch and want the fastest path to a working “create account / sign in” UX.
- You don’t already have an identity provider.
- You’re happy with email/password + OTP + magic links as the auth surface.
Path B — Bring your own auth provider
Authenticate users in your own identity system (Auth0, Clerk, Cognito, Firebase Auth, NextAuth, your own SSO) and useCustomersService (client.customers) to provision the matching Galactic Core customer record from your backend.
Best when:
- You already use Auth0/Clerk/Cognito/Firebase/NextAuth/SSO and don’t want a second login system.
- You need MFA flows, social logins, enterprise SSO, or other features your provider already does well.
- Your buyers exist in an upstream system (ERP, CRM, accounting platform) and are projected into Galactic Core via integration.
The two BYO-auth modes: who verifies
Both modes let a shopper authenticated in your identity provider act on their own Galactic Core customer record, and both resolve to the same record byexternal_id. They differ in who verifies the identity-provider token, and therefore what you have to run:
Use
xExternalAuth when you already run a backend: it authenticates the shopper against your identity provider and signs a short-lived assertion { external_id, iat, exp }, which Galactic Core verifies with a signature check. Nothing leaves your side except the signed claim.
Use xIdpToken when you’d rather not build the signing step — a thin or serverless storefront that only holds the identity provider’s client-side token. You send that raw token; Galactic Core forwards it to a verifier endpoint you register as an Auth provider, which validates it and returns the identity. Verification is fail-closed: if the verifier rejects the token or can’t be reached, the request is treated as signed-out, never signed-in. Registering the verifier is done through Custom Integrations; see the Auth provider capability on the Extensions page.
Decision matrix
You can mix both if you need to (e.g. start with Path A and migrate to Path B later). The customer record is the same row either way.
How Path B works end-to-end
external_id — the join key
external_id is an optional string on every customer record. It’s unique per store + environment, which means you can rely on (store_id, environment, external_id) as a stable lookup key for the lifetime of the customer.
createCustomer, update it on updateCustomer if the upstream identifier changes (e.g. provider migration).
Customer-self endpoints in Path B — the x-external-auth assertion
GET /v1/customers/{id} and PATCH /v1/customers/{id} are customer-self operations: the caller must prove they ARE that customer. In Path A this is a Galactic Core JWT (x-auth-token). In Path B the customer has no Galactic Core session — they have your session — so we accept an equivalent: an HMAC-signed assertion from your backend.
Wire format:
- Signed with your store’s
hmac_secret(the same secret used for orders/payments signing — find it under Integrations → API Keys). exp - iatmust be ≤ 300 seconds.- The
external_idin the claim must resolve to a Galactic Core customer whoseidmatches the{id}in the path — otherwise403. - Provide
x-external-authORx-auth-token, not both. Both →400.
hmac_secret. The 300-second cap on exp - iat bounds how long a leaked assertion remains valid.
What Path B still doesn’t give you
- No password reset, magic link, or OTP delivery. Those live in your identity provider.
- No customer sessions. Galactic Core never issues a JWT to the customer; your provider does. The
x-external-authassertion is a per-request claim from your backend rather than a long-lived customer token.
What Path A doesn’t give you
- No external identity reuse. Galactic Core mints its own JWTs; it doesn’t accept tokens issued by Auth0/Clerk/etc.
- No social logins or enterprise SSO out of the box.

