How the integration works

The path of an assessment

1. The approved Web SDK, bundled into your frontend, collects browser signals through your active collection domain and returns to your frontend an opaque event_context_token for each business action (a login, a withdrawal, a trade order). The platform prepares the collection domain’s certificate, routing and ownership challenge by itself; you publish the DNS records it shows, and it verifies them and activates the domain (collection domain).

2. Your frontend sends that token to your backend, together with the business request it already makes.

3. Your backend calls POST /v1/assessments, signed with HMAC, with the token (or null when there was no collection) and pseudonymous references for the person and the account.

4. FingerTrackID assesses, stores and answers in the same call with the assessment status, the score (trust_score) when there is one, the indicators and a recommendation (recommended_action).

5. Your system decides and acts. During shadow validation, observe the recommendation and compare it with your current decision. When your company configures its own active risk rules, a BLOCK_RECOMMENDED comes from your rules and your bands; your backend still executes it (recommended action).

When the SDK cannot provide a context in time, send event_context_token: null. That means no browser evidence was supplied for the action; it does not guarantee an HTTP success or a particular assessment status. Read the actual response or Problem under your issued policy, and continue your product’s normal authentication and fallback behavior.

Prepare browser and backend together

Prepare the approved private SDK package and the signed backend call together. The documentation URL does not issue credentials, an approved archive or a collection domain. Follow the implementation handoff and availability.

What lives in each system

System	Responsibility	Never put here
Your customer’s browser	Load the approved SDK, collect before the assessed action’s submit, obtain one opaque context per business action within the application’s evidence window (60 or 300 seconds)	The HMAC secret, authority over the account, blocking based on the score
Your backend	Authenticate your user, resolve the pseudonymous references, create the event IDs, request the assessment and execute its own decision	Trust in an identity, score or flag coming from the browser
FingerTrackID	Authenticate the integration, assess the available evidence, apply the managed policy or your company’s own rules, return an explainable recommendation	Approving a login, releasing a withdrawal, executing an order or blocking an account

The HMAC secret lives only in your backend. Apart from its single reveal in the console, where you copy it straight into your secret vault, it never goes to a browser, an app, a log, analytics, a support ticket, a code repository or a frontend environment variable.

Public identifiers and secrets

Item	Public?	Where it is used
Application public key (pub_app_…)	Yes — it is a locator, not a secret	Web SDK initialization
Credential key_id	Yes	X-FTID-Signature header
HMAC secret	No	Only in your backend’s secret vault
event_context_token	Must not go to logs or analytics	From the browser to your backend, and from there to the API

Next step: onboarding.