Skip to main content
Para colocar una o más órdenes, envía un mensaje placeV3 por la conexión WebSocket. Una sola solicitud puede contener un lote de órdenes; los resultados por orden vuelven en un array data, de forma posicional respecto a tu array orders.
Cada objeto de orden incluye:
string
requerido
El ID único del juego.
number
requerido
El importe a arriesgar en la apuesta.
string
requerido
El tipo de mercado: uno de moneyline, spread, total o moneyline1x2. moneyline1x2 es solo fútbol (moneyline a tres vías: local / visitante / empate).
string
requerido
Depende de type:
  • moneyline, spread — el ID del participante al que apoyas.
  • total — "over" o "under".
  • moneyline1x2 — "yes" o "no" sobre el resultado indicado por market.
string
Obligatorio solo para moneyline1x2. "draw" o un ID de participante: nombra el resultado sobre el que apuestas yes/no. Por ejemplo, side: "yes" + market: "draw" significa el partido termina en empate; side: "no" + market: "<homeTeamId>" significa el equipo local no gana.
string
requerido
Uno de limit, post, postArb, fillAndKill o fillOrKill. Consulta Tipos de orden más abajo.
number
requerido
Las cuotas en formato americano (p. ej., +150 o -110).
number
El número de spread o de total. Obligatorio para spread y total; no se usa en moneyline ni moneyline1x2.
string
Un identificador definido por el cliente para ayudarte a seguir la orden de tu lado.

Tipos de orden

limit

El tipo de orden por defecto. Se ejecuta contra cualquier liquidez coincidente a tu precio o mejor como taker (con comisión de taker) y deja el resto en el libro como maker. Una orden limit puede quedar totalmente cruzada, totalmente en espera, o parcialmente cruzada con el resto en espera.

post

Crea una oferta en espera. Si la orden se cruzaría con liquidez existente al colocarla, el servidor la rechaza (normalmente rejected_order_type_rules, por ejemplo "post order cannot have matches").

postArb

Se comporta como post, pero puedes colocar incluso cuando la orden se cruzaría, solo si tus cuotas americanas están dentro del 1% de las cuotas de la orden en espera con la que te cruzarías. Si esa diferencia de precio es mayor al 1%, la colocación se rechaza. Ejemplos:
  • Mejor oferta +100 y colocas +100 — post se rechaza (se cruzaría); postArb puede estar permitido.
  • Mejor oferta +200 — postArb a +190 se rechaza (demasiado lejos de +200). Alrededor de +198 está en el borde de la banda del 1% frente a +200.
  • Mejor orden −200 — la banda se extiende hasta alrededor de −202 en el lado negativo (la misma regla del 1%).
  • Con +100 en el libro, −101 es el límite de referencia en el otro lado para la tolerancia del 1% (según las reglas del producto).
postArb evita las comisiones de taker de un cruce normal: no se te cobran comisiones de taker en este flujo como sí ocurriría si tomases o golpeases liquidez en espera como taker. Las órdenes colocadas como postArb se marcan con isPostArb: true en sus actualizaciones del feed de usuario y del feed de precios; el campo se omite en los demás tipos de orden. La propia respuesta de colocación no incluye el indicador.

fillAndKill

Ejecuta de inmediato como taker contra el tamaño disponible a tu precio o mejor y cancela el resto. Un fillAndKill nunca queda en el libro. Un cruce parcial es un resultado correcto: envía bet: 1000 contra 400deliquidezcruzableysetecruzapor400 de liquidez cruzable y se te cruza por 400 con los $600 restantes cancelados: un éxito, no un error. La orden solo se rechaza ("fill and kill has no matches") cuando no hay liquidez cruzable en absoluto. Consulta los escenarios de Fill And Kill en los ejemplos más abajo.

fillOrKill

Todo o nada. Tu bet entero debe cruzar de inmediato a tu precio o mejor; de lo contrario se rechaza toda la orden, incluidos los cruces que hubiera hecho por el camino, que se revierten. Un fillOrKill nunca queda en el libro y nunca te deja parcialmente cruzado. Úsalo cuando una posición parcial sea peor que ninguna posición, por ejemplo cuando la orden es una pata de una cobertura que solo puedes ejecutar por completo. Los rechazos llevan errorType: rejected_order_type_rules con uno de dos mensajes, que distinguen «no había nada» de «no había suficiente»:
  • "fill or kill has no matches" — no hay liquidez cruzable a tu precio.
  • "fill or kill matched but not fully" — parte de la liquidez cruzó, pero no tu tamaño completo. Esos cruces se revirtieron.
Un residual de **10omenos∗∗cuentacomocompleto:un‘fillOrKill‘de10 o menos** cuenta como completo: un `fillOrKill` de 1,000 que cruza 992tieneeˊxito,porquelos992 tiene éxito, porque los 8 que no se pudieron cruzar están por debajo del tamaño mínimo que podría quedar en el libro. Un residual mayor de $10 rechaza la orden.

Respuesta

El servidor responde con tu requestID y una lista de resultados por orden.

Ejemplos

Escenario 1: Órdenes que cruzan sin liquidez restante

Coloca 3 órdenes que cruzan al instante con la liquidez disponible.
Respuesta:

Escenario 2: Orden limit con liquidez restante

Coloca 1 orden de 300 que cruza parcialmente al instante y deja el resto de liquidez en espera en el libro de órdenes. La respuesta muestra una porción cruzada y una porción sin cruzar.

Escenario 3: Orden Fill and Kill con cruce

Una orden fill-and-kill con cruce completo.

Escenario 4: Orden Fill and Kill sin cruce

Una orden fill-and-kill sin cruce. El servidor responde con un error y un error_type.

Escenario 5: Orden Fill or Kill que no se puede cruzar por completo

fillOrKill es el homólogo de todo o nada de fillAndKill. Donde un fillAndKill de 1,000contra1,000 contra 400 de liquidez cruza 400ycancelaelresto,un‘fillOrKill‘rechazatodalaordenyrevierteesos400 y cancela el resto, un `fillOrKill` rechaza toda la orden y revierte esos 400: nunca te deja parcialmente cruzado.
Sin liquidez cruzable en absoluto, la misma orden se rechaza con "fill or kill has no matches" en su lugar.

Escenario 6: postArb frente a post cuando el libro cruzaría

post rechaza una orden que cruzaría liquidez en espera (por ejemplo, mejor oferta +100 e intentas colocar +100). postArb permite esa situación cuando tus cuotas están dentro del 1% de la orden con la que te cruzarías, de modo que la misma colocación a +100 puede tener éxito como postArb y evitas las comisiones de taker que pagarías en un cruce normal si tomases esa liquidez como taker. Si tu precio está demasiado lejos de la cotización en espera (p. ej. mejor oferta +200 pero envías +190), postArb se rechaza; un precio alrededor de +198 está cerca del límite frente a +200. Usa "orderType": "postArb" en el objeto de orden igual que limit, post, fillAndKill o fillOrKill.

Escenario 7: moneyline1x2 (fútbol a tres vías)

moneyline1x2 es el mercado de fútbol a tres vías — local / visitante / empate — colocado como una apuesta yes/no sobre el resultado indicado por market. Abajo, yes sobre el empate a +250.
Para apostar a que el equipo local no gana, envía side: "no" y pon market al ID del participante local.

Retraso en vivo

Las órdenes colocadas en un juego marcado como live siguen estas reglas:
  1. Si la orden no cruza ninguna liquidez existente, se coloca de inmediato.
  2. Si la orden sí cruza liquidez existente, incurre en un periodo de retraso antes de ejecutarse.
  3. Distintas ligas tienen distintos periodos de retraso en vivo:
    • NFL, UFCMMA, NCAAF — 3 segundos.
    • NCAAB, NBA — 5 segundos.
    • ATP, WTA — 8 segundos.
    • Por defecto — 10 segundos.
  4. Tras el retraso, la orden intenta ejecutarse:
    • Si las cuotas mejoran, cruza al instante.
    • Si las cuotas empeoran, no cruza.

Respuestas de error

Cuando el servidor no consigue colocar una orden individual, la entrada por orden en data[] se devuelve con esta forma:
Si recibes un mensaje de error, la orden no se ha procesado y es seguro enviarla de nuevo. Los errores se devuelven de forma posicional en el array data, coincidiendo con el índice de la orden de entrada en tu array orders.
  • error no está estandarizado; es una cadena descriptiva y puede variar.
  • error_type es un enum en el que puedes apoyarte para el manejo programático:
    • validation_error — el payload o el estado no superó la validación (p. ej. campos ausentes, cuotas/número incorrectos, lado inválido, juego inactivo).
    • rejected_liability — restricciones de usuario, cuenta o liability impidieron la colocación o la ejecución.
    • rejected_order_type_rules — las reglas del tipo de orden prohíben la ejecución (p. ej. fillAndKill no encontró liquidez ejecutable, así que no se pudo cruzar nada y la orden fue rechazada; fillOrKill no se pudo cruzar por completo; post encontró cruces cuando los cruces no están permitidos; o postArb se rechazó porque tus cuotas americanas difieren de la orden en espera con la que te cruzarías en más del 1%).
    • system_error — error transitorio o interno; reintentar puede funcionar.
Ejemplo con varias colocaciones de órdenes, algunas de las cuales devolvieron un error: