Documentation menu

/

Integration modules

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.