Órdenes de negociación, una evaluación por orden

Para seguir cada orden, evalúe cada orden una vez, con la solicitud v1.1 y la etiqueta trade. El cuerpo no lleva datos de la orden: ni instrumento, ni sentido, ni cantidad, ni precio, ni importe. FingerTrackID evalúa el dispositivo y el acceso detrás de la orden; su sistema ya tiene la orden.

Dimensionamiento

Un flujo de órdenes de alta frecuencia necesita una revisión de capacidad con FingerTrackID antes de salir a producción: la tasa de solicitudes, la retención y el volumen de la consola se dimensionan para su flujo, no se dan por supuestos.

Flujo

1. Prepare en el navegador. Con la receta de captura, llame a prepareNextAction() ante la actividad en el formulario de la orden (sus focusin y pointerdown), nunca cuando se carga la pantalla de negociación. El helper mantiene la captura reciente dentro de la ventana de evidencia de su aplicación (60 o 300 segundos, la ventana de evidencia) y vuelve a capturar solo cuando la captura caducaría.
2. Para cada orden, obtenga un contexto del evento. Llame a takeActionContext() una vez por orden, en su envío; espera como máximo su propio tope (el ciclo de vida del SDK). Cada orden obtiene su propio evento a partir de la captura más reciente, con un presupuesto de 5000 ms por consulta desde el SDK 0.2.0. Si ningún contexto llega a tiempo, continúe con null: la evaluación vuelve sin puntuación, y la falta de contexto nunca es motivo para retener la orden. Una sesión del SDK emite como máximo 128 contextos del evento; el helper vuelve a capturar antes de eso.
3. Evalúe desde su backend. Envíe POST /v1/assessments con el cuerpo v1.1 y "tag": "trade". Derive external_event_id e idempotency_key del ID de su orden, para que un reintento de la misma orden sea la misma operación. Ambas referencias son obligatorias.
4. Informe lo que hizo. Envíe la acción y el resultado por assessment_id, como en cualquier otra evaluación (feedback).

Ninguna orden provoca una consulta externa ni una nueva captura: cada orden reutiliza la evidencia reciente de la sesión.

Un cuerpo sintético para una orden, formateado para su lectura:

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_trade_0001",
  "idempotency_key": "idem_evt_trade_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_trade_0001",
  "tag": "trade",
  "deadline_ms": null
}

Qué mirar en la consola

Lectura	Qué muestra
Eventos con la misma etiqueta en la cuenta	La ráfaga de eventos trade de una cuenta en el último minuto, los últimos cinco minutos y la última hora
Eventos con la misma etiqueta en el dispositivo	La ráfaga de eventos trade de un dispositivo, en todas las cuentas, en las mismas ventanas
Indicadores del dispositivo	BOT_AUTOMATION, EMULATED_ENVIRONMENT, BROWSER_SPOOFING y los indicadores de red

Estas lecturas son contexto para sus analistas. No entran en la puntuación y la API no las devuelve. Las lecturas de órdenes del recorrido v1 TRADE cuentan solo órdenes v1; las órdenes v1.1 se cuentan por etiqueta.

Uso

La unidad de uso es una captura del navegador completada, no una orden. Las órdenes que reutilizan la misma captura no suman uso, por lo que el uso sigue el tiempo durante el que sus usuarios negocian activamente dividido por la ventana de evidencia, no el número de órdenes. Las cifras de uso en la consola son estimaciones, no facturas (estado en producción).