4. Colocar una orden límite en Coinbase Pro

Nivel 13: Conectar con Brokers Reales

Ya tenemos autenticación. Vamos a colocar una orden límite. Una orden límite te permite especificar el precio al que quieres comprar o vender un activo, dándote más control sobre el precio de ejecución.

Esa frase esconde el compromiso central de la ejecución: la orden de mercado garantiza ejecución pero no precio; la orden límite garantiza precio pero no ejecución. Si pones un límite de compra por debajo del mercado y el precio nunca baja hasta ahí, tu orden se queda en el libro para siempre sin llenarse. Para una estrategia sistemática eso no es un detalle menor: significa que tu posición real puede no ser la que el modelo asume.

El endpoint para crear órdenes es POST https://api.pro.coinbase.com/orders y el cuerpo de la petición describe la orden:

API_URL = 'https://api.pro.coinbase.com/orders'

body = {
    'size': '0.0005',        # cantidad de BTC a comprar
    'price': '10000.00',     # precio limite al que quieres comprar
    'side': 'buy',           # buy o sell
    'product_id': 'BTC-USD', # el par
    'type': 'limit'          # orden limite
}
body_json = json.dumps(body)

response = requests.post(API_URL, headers=headers, data=body_json, timeout=10)

if response.ok:
    print('Orden enviada:', response.json())
else:
    print('Fallo al enviar la orden:', response.status_code, response.text)

Fíjate en dos detalles del código anterior. El primero: size y price van como cadenas de texto, no como números en coma flotante. Es deliberado. Un float no representa exactamente muchos decimales y un redondeo silencioso en una cantidad monetaria es un error que puede costar dinero; por eso las APIs financieras serias trabajan con cadenas o con decimales exactos. El segundo: el timeout en la llamada. Sin él, una petición puede quedarse colgada indefinidamente, y en el módulo 6 verás por qué eso es peligroso.

Enviada no es ejecutada

Una respuesta correcta del servidor significa que la orden ha sido *aceptada* y colocada en el libro, no que se haya ejecutado. La respuesta trae un identificador de orden y un estado, normalmente pending u open. Para saber si se llenó tienes que consultarlo después, con GET /orders/:order-id, o recibirlo por el canal de WebSocket de ejecuciones. Confundir aceptación con ejecución es una de las causas más frecuentes de que un sistema en vivo crea tener una posición que no tiene.

El resto de la API sigue la misma lógica REST. Estos son los endpoints que más vas a usar:

• GET /products y GET /products/:product-id/ticker: instrumentos disponibles y último precio.
• GET /products/:product-id/book: el libro de órdenes.
• GET /products/:product-id/candles: velas históricas.
• GET /accounts y GET /accounts/:account-id/ledger: saldos y movimientos.
• POST /orders: crear una orden.
• GET /orders y GET /orders/:order-id: órdenes abiertas y estado de una concreta.
• DELETE /orders/:order-id: cancelar una orden.
• GET /fills: tus ejecuciones reales, con precio y comisión de cada una.
• GET /time: la hora del servidor, útil para detectar desfases de reloj.

Donde veas :product-id, :order-id o :account-id, sustitúyelo por el valor real (por ejemplo BTC-USD).

Dos opciones más que conviene conocer desde el principio. post_only rechaza la orden si fuera a ejecutarse inmediatamente contra el libro, lo que garantiza que siempre seas *maker* y pagues la comisión más baja. Y el tiempo en vigor: GTC mantiene la orden hasta que la canceles, IOC ejecuta lo que pueda al instante y cancela el resto, y FOK exige llenado completo inmediato o nada. Elegir mal esta opción cambia por completo el comportamiento de la estrategia.