Identity model

Three IDs and when to use which

Every event GetFluxly accepts carries one or more identifiers. There are three. Picking the right one for a given call site is what makes profiles stitch correctly down the line.

| ID | Purpose | Where it's set | Lifetime | | --- | --- | --- | --- | | anonymous_id | First-touch device identifier | Browser SDK at load, cookie/localStorage | Until the user clears storage | | external_id | Your application's user ID | Your code, once the user signs in | Forever | | user_id | GetFluxly's resolved profile ID | Server response after the first stitch | Forever |

The lifecycle

  1. Anonymous visit. Browser SDK generates anonymous_id = anon_a8f3… and persists it. Every event includes only this.
  2. Sign-up / sign-in. Your code learns the application user. Call identify(externalId, traits), the SDK attaches both anonymous_id and external_id to the identify event.
  3. Stitching. The identity worker resolves the pair into a single user_id. Subsequent events use either ID; both route to the same profile.
  4. Across devices. A second device starts with its own anonymous_id. The first identify with the same external_id stitches that device into the existing profile.

Server-side calls

Server SDKs typically know the application user (external_id) already and skip the anonymous_id. That's fine, but it cuts the device-attribution chain, server events come in unattributed to the originating browser session unless your code threads through the anonymous_id from the request.

Where the rules live

The full identity-stitching algorithm and the conflict-resolution rules are in the stitching guide. The contract is locked.