Respuesta directa
Al evaluar una API de órdenes, concéntrate en lo que la API realmente hace con las órdenes, cómo puedes confirmar los resultados y dónde el comportamiento puede diferir de tus expectativas. Mantén la lista de verificación objetiva: separa la mecánica estable (estructura de solicitud/respuesta, semántica del ciclo de vida) de las condiciones variables (movimiento del mercado, costos, calidad de ejecución y reglas locales). Dado que los resultados dependen de factores externos, trata los ejemplos como supuestos, no como predicciones.
Cómo funciona una API de órdenes (mecanismo y definición)
Una API de órdenes es una interfaz de programa que se utiliza para enviar, modificar y cancelar órdenes de trading y para recuperar información sobre su estado en el ciclo de vida. En la práctica, normalmente trabajas con:
- Solicitud de orden: los datos que envías (por ejemplo, tipo de orden, lado, cantidad, tiempo en vigor y cualquier identificador requerido).
- Ejecución y confirmación: las respuestas que recibes (aceptación, rechazo o errores).
- Actualizaciones de estado de la orden: cómo informa el proveedor los cambios a lo largo del tiempo (abierta, parcialmente ejecutada, ejecutada, cancelada, expirada, rechazada).
- Identificadores de conciliación: campos que te permiten hacer coincidir tu intención con los resultados informados por el proveedor (como ID de orden del cliente e ID de orden del proveedor, si son compatibles).
Un paso clave de evaluación es traducir la documentación a un modelo de estado explícito para tu sistema: qué estados existen, cómo ocurren las transiciones y qué garantías (si las hay) proporciona la API en torno al ordenamiento, los reintentos y las actualizaciones. La mecánica estable es aquella sobre la que puedes razonar a partir de la especificación; las condiciones variables son todo lo que puede cambiar entre la solicitud y la confirmación.
Lista de verificación de debida diligencia (afvinkpunten)
Utiliza los elementos a continuación para construir un proceso de verificación repetible.
1) Entrada y semántica (lo que envías)
- Confirma los campos obligatorios y las restricciones de datos (tipos de orden permitidos, tamaños mínimos/máximos, valores válidos de tiempo en vigor).
- Documenta cómo interpreta la API las unidades y las reglas de redondeo. Indica tus propios supuestos para la cantidad, la precisión y cómo se manejan los montos de “base” frente a “cotización”.
2) Idempotencia y protección contra duplicados (previene discrepancias de estado)
- Verifica si la API admite solicitudes idempotentes o una estrategia documentada para reintentos después de tiempos de espera agotados.
- Verifica cómo se manejan los duplicados cuando se envía la misma solicitud nuevamente (mismo ID de cliente frente a nueva solicitud). Esto es importante porque la lógica de reintentos es común en sistemas automatizados.
3) Ciclo de vida de la orden y conciliación (evidencia o documentación)
- Verifica el ciclo de vida completo de la orden: qué estados pueden ocurrir y cómo se informan las transiciones.
- Confirma los campos que necesitas para la conciliación (ID de orden, marcas de tiempo, cantidades ejecutadas, cantidad restante y motivos de rechazo).
- Define tus criterios de “finalización” (por ejemplo, consideras que una orden está cerrada cuando recibes un estado terminal, como ejecutada/cancelada/rechazada/expirada, según la semántica documentada del proveedor).
4) Actualizaciones y modelo de entrega (lo que puedes observar)
- Determina si la información de estado llega mediante sondeo, transmisión/webhooks, o ambos.
- Si las actualizaciones son asíncronas, verifica las garantías sobre el orden de los eventos y la integridad de los eventos. Tu lógica de conciliación debe manejar actualizaciones faltantes o retrasadas como un escenario explícito.
5) Costos y supuestos de ejecución (lo que puede cambiar)
- Identifica qué costos y efectos de ejecución pueden cambiar los resultados entre la solicitud y el estado final: comisiones, diferenciales, deslizamiento, ejecuciones parciales y latencia.
- Al ilustrar un ejemplo, indica los supuestos (por ejemplo, “supongamos que las comisiones son X y las ejecuciones ocurren en una sola operación”) y luego señala que las condiciones reales pueden diferir.
6) Modos de fallo (rode vlaggen)
Busca y prueba estos modos de fallo comunes:
- Órdenes rechazadas (errores de validación, permisos insuficientes o parámetros no válidos).
- Tiempos de espera agotados y errores transitorios (tu cliente puede reintentar mientras el proveedor ya puede haber procesado la solicitud).
- Ejecuciones parciales (la orden se ejecuta parcialmente, lo que requiere lógica para la cantidad “restante”).
- Estado inconsistente (tu sistema ve una fuente de estado mientras la otra fuente se retrasa).
Si la documentación no especifica claramente cómo se comportan estos casos, trátalo como una señal de alerta y planifica una conciliación y un monitoreo conservadores.
Limitaciones y riesgos (lo que puede salir mal)
La ejecución de órdenes y los resultados del estado de las órdenes dependen de las condiciones del mercado y del comportamiento del proveedor, que no son totalmente controlables. Las relaciones históricas no garantizan resultados futuros, e incluso las especificaciones cuidadosas pueden fallar bajo estrés (alta volatilidad, problemas de red o mantenimiento del lado del proveedor). Las limitaciones materiales que debes reconocer explícitamente incluyen:
- Incertidumbre entre la intención y la ejecución: la confirmación no significa necesariamente la ejecución final.
- Resultados no atómicos: las ejecuciones parciales y las cancelaciones posteriores pueden crear múltiples estados para una sola instrucción.
- Brechas de observabilidad: los retrasos o las actualizaciones omitidas pueden hacer que tu sistema malinterprete el estado actual.