Server-side API & Queries

Everything on this page runs server-to-server under your access token: Authorization: Bearer <at_live_…>. The tenant is derived from the token's merchant — you never pass a merchant id, and you only ever see your own data. Use this surface to analyze sessions where the browser SDK is not appropriate, to ingest events, and to read back analyses for investigation and reconciliation.

Identity is an evidence provider: every analyze call returns a risk snapshot (scores, signals and an identityRiskLevel verdict) — it never blocks. You decide what to do with the verdict.

Server-side vs the Web SDK

Use the Web SDK when…	Use the server-side API when…
The subject is in a browser you control and you can run the headless SDK	The signal originates server-side — a backend job, a mobile backend, an API-to-API flow
You want the browser to collect device/behavioral telemetry directly	You already hold the context and just need a snapshot, an ingest, or a query
Session calls authenticate with a short-lived SDK session token	Calls authenticate with your secret key as a Bearer JWT

The two are complementary: the SDK collects rich browser telemetry, while the server-side API is the system of record you read from and the entry point when there is no browser.

Analyze a session

Two shapes, same snapshot:

Synchronous — `analyze-sync`

POST /identity/live-sessions/analyze-sync returns the computed snapshot in the response. Use it inline when a decision is waiting on the result.

Asynchronous — `analyze`

POST /identity/live-sessions/analyze returns a traceId immediately and computes the snapshot in the background. Use it for audit trails and high-throughput ingest where you don't need the result on the hot path; read it later with GET /identity/live-sessions/:traceId.

curl https://api-gateway.lunixi.com/api/v1/identity/live-sessions/analyze-sync \
  -H "Authorization: Bearer at_live_5f3e2b1a..." \
  -H "Content-Type: application/json" \
  -d '{
    "subjectType": "customer",
    "subjectId": "cus_8f2a9c",
    "productContext": "checkout",
    "paymentId": "9c6f2b1a-4e8d-4a3f-b5e6-2d7c1a9b8e30",
    "session": { "token": "<sdk-session-token>" }
  }'

The async variant returns just the trace:

curl https://api-gateway.lunixi.com/api/v1/identity/live-sessions/analyze \
  -H "Authorization: Bearer at_live_5f3e2b1a..." \
  -H "Content-Type: application/json" \
  -d '{ "subjectType": "customer", "subjectId": "cus_8f2a9c", "productContext": "signup" }'
# → { "data": { "traceId": "trc_01HV3K9X..." } }

See The Risk Snapshot for the full field reference of the returned data.

Ingest events

Enrich the behavioral signal by streaming interaction events:

POST /identity/live-sessions/event — a single event.
POST /identity/live-sessions/events/batch — a batch of events in one call.

curl https://api-gateway.lunixi.com/api/v1/identity/live-sessions/events/batch \
  -H "Authorization: Bearer at_live_5f3e2b1a..." \
  -H "Content-Type: application/json" \
  -d '{
    "traceId": "trc_01HV3K9X...",
    "events": [
      { "type": "wallet_transfer_click", "at": "2026-07-09T12:00:01.000Z" }
    ]
  }'

Event type is a free-form string — there is no fixed enum.

Query analyses

Every analysis is stored, merchant-scoped and redacted. Read them back:

Method	Path	Returns
`GET`	`/identity/live-sessions`	Recent analyses. Filter with `paymentId`, `checkoutSessionId`, `fingerprintId`, `deviceId`, `limit`
`GET`	`/identity/live-sessions/top-sources`	Highest-risk sources, ranked. Tune with `days`, `limit`
`GET`	`/identity/live-sessions/:traceId`	One analysis in full
`GET`	`/identity/live-sessions/:traceId/timeline`	The lifecycle of one session
`GET`	`/identity/live-sessions/:traceId/related-sessions`	Other sessions in the same device cluster
`GET`	`/identity/live-sessions/:traceId/account-links`	Accounts / actors linked to this session

Listing and filtering

# Every analysis tied to one payment
curl "https://api-gateway.lunixi.com/api/v1/identity/live-sessions?paymentId=9c6f2b1a-4e8d-4a3f-b5e6-2d7c1a9b8e30" \
  -H "Authorization: Bearer at_live_5f3e2b1a..."
 
# The 10 highest-risk sources over the last 7 days
curl "https://api-gateway.lunixi.com/api/v1/identity/live-sessions/top-sources?days=7&limit=10" \
  -H "Authorization: Bearer at_live_5f3e2b1a..."

Related sessions & account links

These two queries turn a single analysis into a graph — the difference is what they connect:

related-sessions walks the device cluster: other sessions that Identity attributes to the same physical device or device family. This is how you surface one device driving many "distinct" sessions — device farms and multi-session abuse.
account-links walks the actor across accounts: the accounts or identities bound to the same actor behind this session. This is how you surface trial-actor and multi-account patterns — one person spread across many accounts.

curl "https://api-gateway.lunixi.com/api/v1/identity/live-sessions/trc_01HV3K9X.../related-sessions" \
  -H "Authorization: Bearer at_live_5f3e2b1a..."
 
curl "https://api-gateway.lunixi.com/api/v1/identity/live-sessions/trc_01HV3K9X.../account-links" \
  -H "Authorization: Bearer at_live_5f3e2b1a..."

Cluster and actor links are history-relative: a brand-new device or actor has few or no links, and the graph grows more connected as the same device/actor is seen again. Related sessions reflect the matchedClusterId on the snapshot; account links reflect the same-actor attribution.

Notes

Bearer only. All calls here use Authorization: Bearer <at_live_…>; the tenant is the token's merchant. Do not send a merchant id.
Read is redacted. Query responses are merchant-scoped and stripped of internal metadata — you get the public snapshot surface.

Next steps

The Risk Snapshot — the full field reference
Web SDK — browser-side collection and session tokens
Identity Assertions & JWKS — non-repudiable verification of an analysis
Mobile Threat · POS / Terminal Threat

POS / Terminal Threat Assertions & JWKS