Evidence in. Clarity out.

Server-side keys stay server-side. Scoring is authenticated with a secret sk_ key in an Authorization: Bearer header. Browsers never hold a secret key; the collector's evidence reaches the API through your own backend.

Endpoints

Workspace data — projects, keys, sessions, stats, audits, members, and usage — is served to the portal through Firebase-authenticated routes under /api/portal/*.

How the pieces fit

The collector runs in the visitor's browser and hands its evidence to your own server. Your server calls the scoring endpoint with your secret key and decides what to do with the result. Volance never hosts the relay and never enforces anything on your behalf.

That means the integration needs somewhere server-side to score from — your existing backend, or a small serverless or edge function if you host statically. A script tag on its own is not enough, because sk_ must never reach a browser.

Scoring request

The request fields are publicKey, sid, manifest, page, clientSignals and events. They identify the session and carry evidence; a public key does not replace secret-key authentication.

Two optional fields carry what the browser cannot: requestSignals for what your edge observed about the visitor — their IP address, header order, proxy headers and whether a cookie came back — and disclosureHeaders for a signed agent request. Both are bounded and validated; omit them and the corresponding checks simply do not run.

Keep sk_ keys server-side. Send it as Authorization: Bearer sk_…. Browser-originated manifest requests are checked against the workspace's allowed origins; server-to-server calls are not origin-gated.

{
  "score": 96,
  "verdict": "human",
  "action": "allow",
  "classification": {
    "label": "human"
  }
}

This excerpt is illustrative, not measured traffic or a live response. The target full response also includes confidence, signals, overrides, consistency checks, cascade information, agent details, a trust token, enforcement settings, and a request ID.

Provisional verdicts and default actions

These boundaries follow the frozen target contract. They are provisional and have not been reconciled with every engine behavior. Classification remains separate from verdict and policy.

The target configuration starts with enforcement disabled and thresholds of 70 for allow and 40 for block. The contract names hard overrides for webdriver, cdp_artifacts, a non-browser client, and spoofed disclosure. One strong contradiction caps the score at 68; two or more cap it at 50. These are provisional contract rules, not a production guarantee.

Evidence and agent identity

Each signals[] entry has id, layer, value, fired, and optional detail. Layers 1–6 cover client integrity, behavior, agent-tell, network, disclosure, and consistency. A fired signal is evidence to inspect, not proof of identity.

Web Bot Auth is verified. A signed request is checked against the agent's published key directory — the .well-known JWKS that Web Bot Auth agents publish — and against any key you register yourself. A signature that verifies returns authorized_agent: automation allowed through without being called human. A known key whose signature fails is treated as spoofed disclosure and capped hard. A signer we cannot resolve is ignored rather than penalised, so an agent that has not published keys yet is never punished for trying. Volance's own key material is published at /api/trace/http-message-signatures-directory; your application still owns its access policy.

Return statuses and errors

The contract describes a 200 scoring response and JSON errors shaped as { "error": "<human-readable sentence>" } with a 4xx or 5xx status. It specifies 401 for a bad key, 404 for unknown routes or methods, and 429 for rate limits. Rate limits apply per key and per route; specific thresholds are not published. Quota state is returned on each scoring response in the quota field.