Límites

Tasa de solicitudes

Cada cliente de servidor (cliente de integración) tiene su propio límite: una tasa sostenida en solicitudes por segundo y una ráfaga que cabe por encima de ella. El limitador es un cubo de tokens por cliente, compartido por todas las instancias de la API: el cubo contiene hasta la ráfaga, se rellena a la tasa sostenida y cada solicitud autenticada consume un token. Un pico de inicios de sesión a las 9 de la mañana lo absorbe la ráfaga; un flujo constante por encima de la tasa sostenida, no.

Nivel	Sostenida	Ráfaga	Cuándo
Estándar	5 por segundo	10	Predeterminado para toda aplicación nueva y todo cliente de servidor nuevo
10	10 por segundo	20	Mediante solicitud en la consola, aprobado de inmediato y aplicado automáticamente
Heredado	1 por segundo	1	Aplicaciones configuradas antes del 2026-10-07, hasta que se solicite un cambio

La consola muestra el límite vigente de cada cliente de servidor en Integração e saúde → Limite de requisições. El límite pertenece al cliente de servidor, no a la credencial: al rotar el secreto, el límite se conserva, y al cambiar el límite se conservan el key_id y el secreto.

Por encima del límite: 429

Superar la tasa devuelve 429 rate-limited con Retry-After en segundos enteros (hoy siempre 1). La solicitud se autenticó y su request_id ya está consumido, así que un reintento es un nuevo intento: mismo cuerpo, request_id nuevo, marca de tiempo actual y firma nueva (vea idempotencia y reintento). Reutilizar el request_id anterior devuelve 401 request-replayed.

Cada intento autenticado, incluidos los respondidos con 429, también consume un presupuesto de seguridad que es el doble del nivel (10 por segundo con una ráfaga de 20 en el nivel estándar). Si respeta Retry-After, nunca lo alcanza. Un cliente que sigue reintentando sin esperar lo agota, y la credencial queda entonces bloqueada durante al menos 10 minutos, durante los cuales toda solicitud se rechaza con 401. Ante un 429, espere y espacie los reintentos; no reintente en un bucle sin pausas.

Una saturación momentánea del servicio aparece como 503 assessment-unavailable, también con Retry-After; reintente de la misma forma, como un nuevo intento.

Encabezados de un 429

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

429 · cuerpo

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

Pedir una tasa más alta

En la consola, abra Integração e saúde → Limite de requisições, elija el cliente de servidor y haga clic en Pedir aumento de limite. Puede pedirlo un miembro con el rol Administrador da empresa o Gestor de integração. Lo que ocurre a continuación:

1. Aprobación: la solicitud se aprueba en cuanto se envía, siempre, incluida la primera vez que se usa un nivel en la aplicación. Nadie tiene que revisarla.
2. Aplicación: la plataforma aplica el nuevo límite automáticamente en unos instantes, incluso mientras ese cliente sigue enviando evaluaciones; nada cambia en su integración (mismo identificador de clave y mismo secreto). Una solicitud de aumento solo puede subir el límite, así que las solicitudes ya en curso siguen siendo válidas con el límite más alto.

La consola ofrece hasta 10 por segundo. Para más de 10 por segundo, contacte con soporte en contato@fingertrackid.com indicando el nombre de la aplicación y el identificador del cliente de servidor. Un cliente de servidor nuevo creado en la consola recibe el nivel actual de la aplicación.

Sesiones del Web SDK

El SDK del navegador tiene sus propios límites por aplicación, independientes de la tasa de solicitudes del cliente de servidor:

Límite	Valor
Sesiones nuevas del SDK	5 por segundo, ráfaga de 20
Sesiones del SDK activas simultáneas	Hasta 1000 por aplicación
Duración de una sesión del SDK	30 minutos, nunca se extiende
Capturas por sesión del SDK	1; el SDK 0.2.0 y posteriores abren una sesión nueva para cada captura nueva, como máximo una por segundo por cliente
Solicitudes de captura y de contexto del evento por sesión del SDK	Una cada 250 ms, que el SDK respeta por sí solo
Contextos de evento por sesión del SDK	128
Evidencia del navegador y contexto del evento	Por aplicación: 60 segundos para las aplicaciones aprovisionadas antes de que se introdujera la ventana de 300 segundos (octubre de 2026), 300 segundos para las aprovisionadas desde entonces, a partir del momento en que la captura llega a FingerTrackID (la ventana de evidencia)
Encabezados de la solicitud	Exactamente los que envía el SDK; cualquier encabezado añadido por la instrumentación de la página hace fallar el preflight de CORS (encabezados de rastreo)

Una sesión rechazada hace que collect() devuelva status: 'UNAVAILABLE'; la evaluación se envía igualmente con event_context_token: null. Los detalles están en captura y contexto del evento, y los plazos de las propias solicitudes del SDK, en tiempos y latencia.

Otros límites

Límite	Valor	Nota
Ventana de la marca de tiempo de la firma	±300 s	401 timestamp-out-of-window
Ventana de occurred_at para una operación nueva	±300 s	400 occurred-at-out-of-window
Retención de request_id	Al menos 601 s	Nunca reutilice uno, ni siquiera después de la ventana
Cuerpo de la solicitud	16384 bytes	413 payload-too-large
Cuerpo de la respuesta	65536 bytes	Nunca es mayor; por encima de eso, trátelo como indeterminado
event_context_token	4096 caracteres	400

Ninguna de estas cifras es una cuota comercial ni una garantía de rendimiento, y el deadline_ms de los recorridos no es un SLA.