Limits

Request rate

Each server client (integration client) has its own limit: a sustained rate in requests per second and a burst that fits on top of it. The limiter is a token bucket per client, shared by every instance of the API: the bucket holds up to the burst, refills at the sustained rate, and each authenticated request takes one token. A peak of logins at 9 a.m. is absorbed by the burst; a steady flow above the sustained rate is not.

Tier	Sustained	Burst	When
Standard	5 per second	10	Default for every new application and new server client
10	10 per second	20	On request in the console, approved at once and applied automatically
Legacy	1 per second	1	Applications set up before 2026-10-07, until a change is requested

The console shows the limit in force for each server client under Integração e saúde → Limite de requisições. The limit belongs to the server client, not to the credential: rotating the secret keeps it, and changing it keeps the key_id and the secret.

Above the limit: 429

Exceeding the rate gives 429 rate-limited with Retry-After in whole seconds (today always 1). The request was authenticated and its request_id is already consumed, so a retry is a new attempt: same body, new request_id, current timestamp and new signature (see idempotency and retry). Reusing the old request_id gives 401 request-replayed.

Every authenticated attempt, including those answered 429, also spends a security budget that is twice the tier (10 per second with a burst of 20 on the standard tier). Honouring Retry-After never reaches it. A client that keeps retrying without waiting exhausts it, and the credential is then blocked for at least 10 minutes, during which every request is refused with 401. Back off on 429; do not retry in a tight loop.

Momentary service saturation shows up as 503 assessment-unavailable, also with Retry-After; retry it the same way, as a new attempt.

Headers of a 429

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 1
X-Correlation-Id: <opaque, for support>

429 · body

{
  "type": "https://fingertrackid.dev/problems/rate-limited",
  "title": "Limite de assessments atingido",
  "status": 429,
  "correlation_id": "corr-problem-rate-limit-0001",
  "retryable": true
}

Asking for a higher rate

In the console, open Integração e saúde → Limite de requisições, choose the server client and click Pedir aumento de limite. A member with the Administrador da empresa or Gestor de integração role can ask. What happens next:

1. Approval: the request is approved as soon as it is sent, every time, including the first time a tier is used in the application. Nobody has to review it.
2. Applying it: the platform applies the new limit automatically within moments, even while that client keeps sending assessments; nothing changes in your integration (same key identifier and secret). A request only ever raises the limit, so requests already in flight stay valid under the higher one.

The console offers up to 10 per second. For more than 10 per second, contact support at contato@fingertrackid.com with the application name and the server client identifier. A new server client created in the console receives the application’s current tier.

Web SDK sessions

The browser SDK has its own per-application limits, separate from the server client’s request rate:

Limit	Value
New SDK sessions	5 per second, burst of 20
Concurrent live SDK sessions	Up to 1000 per application
SDK session lifetime	30 minutes, never extended
Collections per SDK session	1; SDK 0.2.0 and later open a new session for each new collection, at most one per second per client
Collection and event-context requests per SDK session	One per 250 ms, which the SDK respects by itself
Event contexts per SDK session	128
Browser evidence and event context	Per application: 60 seconds for applications provisioned before the 300-second window was introduced (October 2026), 300 seconds for those provisioned since, from when the collection reaches FingerTrackID (the evidence window)
Request headers	Exactly those the SDK sends; any header added by page instrumentation makes the CORS preflight fail (tracing headers)

A refused session makes collect() return status: 'UNAVAILABLE'; the assessment is still sent with event_context_token: null. Details are in collection and event context, and the SDK’s own request deadlines in timing and latency.

Other limits

Limit	Value	Note
Signature timestamp window	±300 s	401 timestamp-out-of-window
occurred_at window for a new operation	±300 s	400 occurred-at-out-of-window
request_id retention	At least 601 s	Never reuse one, not even after the window
Request body	16384 bytes	413 payload-too-large
Response body	65536 bytes	Never larger; above that, treat it as indeterminate
event_context_token	4096 characters	400

None of these numbers is a commercial quota or a throughput guarantee, and the deadline_ms of the journeys is not an SLA.