Identity and continuity
How a returning shopper is recognised, and what that identifier is not for.
A shopper who reloads the page, or moves between your store and the Neomi storefront, should not become a new person in the data.
Deterministic session identity
Where your storefront passes a customer identifier and a store identifier, the session id is derived deterministically from the pair, so the same shopper at the same store produces the same session id across reloads. Without those parameters the session id is random.
What it is for
This exists for analytics continuity. It is explicitly not an authorization mechanism, and any endpoint exposing customer data enforces its own auth rather than trusting an identifier that arrived in a query string. We are stating that plainly because it is the sort of assumption that quietly becomes a security problem.
Account linkage
Recognising a signed-in customer against your account system is a separate, scoped conversation and depends on what your identity layer supports.
Note on this page
Described from the current implementation rather than from a published contract. Field names and shapes are what Neomi normalizes to today; our engineering team confirms the public naming when the reference is finalized.