Skip to main content

Execution API

The Execution API provides a unified interface for order execution across all supported exchanges. Users specify standard parameters (order_type, time_in_force, stop_price, etc.) and the system automatically handles exchange-specific translation.

Key Features

  • Unified Parameters: Same API works across all exchanges
  • Clear Error Messages: If an exchange doesn’t support a feature, you get a specific error
  • Capability Discovery: Query what each exchange supports before trading
  • Pre-validation: Check if your order would be valid before submitting

Unified Order Types

Time-in-Force Options


Exchange Capabilities Matrix

Order Type Support

Kraken splits across two CCXT classes: spot at api.kraken.com (ccxt.kraken) and futures at futures.kraken.com (ccxt.krakenfutures). OEMS routes (kraken, swap|future) to the futures class automatically; the caller uses the same unified API. See Trading on Kraken.

Feature Support


POST /order-execution/execution/order

Execute an order using unified parameters. The system automatically translates to exchange-specific format.

Authentication

Requires a valid API key whose user has the trader or admin role.

Request Body (JSON)

  • exchange_account_id (string, required): The exchange account UUID (e.g., “binance-sandbox-001”)
  • symbol (string, required): Trading pair in CCXT format (e.g., “BTC/USDT”)
  • side (string, required): Order side: "buy" or "sell"
  • order_type (string, required): Order type: market, limit, stop_loss, stop_loss_limit, take_profit, take_profit_limit, trailing_stop, oco
  • quantity (number, required): Order quantity in base asset units
  • price (number, optional): Limit price. Required for limit, stop_loss_limit, take_profit_limit orders.
  • stop_price (number, optional): Trigger price for stop orders. Required for stop_loss, stop_loss_limit, take_profit, take_profit_limit orders.
  • trailing_delta (number, optional): Trailing delta percentage. Required for trailing_stop orders.
  • time_in_force (string, optional): Time-in-force: GTC, IOC, FOK, POST_ONLY. Default: GTC
  • reduce_only (boolean, optional): For perps: only reduce existing position, don’t open new one. Default: false
  • post_only (boolean, optional): Maker only: reject if order would immediately fill. Default: false
  • client_order_id (string, optional): Optional user-defined order ID for tracking.
  • market_type (string, optional): Market type: spot, swap, or future. Default: spot

Request Examples

Market Order
Limit Order with Post-Only
Stop Loss Order
Stop Loss Limit Order
Trailing Stop Order (Binance Futures)
Perp Order with Reduce-Only

Response Examples

Successful Order
Unsupported Feature
Daily Limit Exceeded

GET /order-execution/execution/capabilities

Query what order types, time-in-force options, and features each exchange supports.

Query Parameters

  • exchange (string, optional): Exchange name. If not provided, returns all exchanges.

Request Example

Response Examples

Single Exchange
All Exchanges

POST /order-execution/execution/validate

Check if an order would be valid for a specific exchange before submitting.

Request Body (JSON)

  • exchange (string, required): Exchange name (e.g., “binance”, “gateio”)
  • order_type (string, required): Order type to validate
  • market_type (string, optional): Market type: spot, swap, or future. Default: spot
  • time_in_force (string, optional): Time-in-force option to validate
  • reduce_only (boolean, optional): Check if reduce_only is supported. Default: false
  • post_only (boolean, optional): Check if post_only is supported. Default: false
  • stop_price (number, optional): Include to validate stop order requirements
  • trailing_delta (number, optional): Include to validate trailing stop requirements

Request Example

Response Examples

Valid
Invalid

GET /order-execution/execution/order/

Fetch the current status of an order from the exchange. A successful fetch also writes the live status back to the order’s meta_orders record (order_status, quantity_filled, avg_fill_price, fee, last_traded_timestamp), so a resting order that filled after submission stops showing a stale open in order listings. Error results (e.g. ORDER_NOT_FOUND) never modify the record.

Path Parameters

  • order_id (string, required): The exchange order ID

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, optional): Trading symbol (required by some exchanges)
  • market_type (string, optional): Market type: spot, swap, or future. Default: spot. If the symbol is a derivative (contains :, e.g. BTC/USD:USD) and market_type is omitted, it is derived as swap automatically. On Kraken this routes to the futures instance (ccxt.krakenfutures) instead of spot. Pass future explicitly for dated futures if needed.

Request Example

Response Example


DELETE /order-execution/execution/order/

Cancel an open order on the exchange.

Path Parameters

  • order_id (string, required): The exchange order ID to cancel

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, optional): Trading symbol (required by some exchanges)
  • market_type (string, optional): Market type: spot, swap, or future. Default: spot

Request Example


GET /order-execution/execution/balance

Fetch account balance from the exchange.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • market_type (string, optional): Market type: spot, swap, or future. Default: spot

Request Example

Response Example


GET /order-execution/execution/orders/open

Fetch all open orders from the exchange.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, optional): Filter by trading symbol
  • market_type (string, optional): Market type: spot, swap, or future. Default: spot

Request Example


GET /order-execution/execution/daily-limit

Get the daily trading limit status for an exchange account.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID

Request Example

Response Example


Error Codes


Migration from Legacy API

If you were using the old params object for exchange-specific parameters, here’s how to migrate: Before (Legacy)
After (Unified)
The unified API handles all exchange-specific translation automatically. If you try to use a feature that an exchange doesn’t support, you’ll get a clear error message like “Gate.io does not support trailing_stop orders” instead of a cryptic exchange error.

Futures/Perpetuals Endpoints

The following endpoints are specific to futures and perpetual trading.

POST /order-execution/execution/leverage

Set leverage for a symbol on futures/perp markets.

Request Body (JSON)

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, required): Trading pair in perp format (e.g., “BTC/USDT:USDT”)
  • leverage (number, required): Leverage value (e.g., 1, 5, 10, 20, 50, 100)
  • market_type (string, optional): swap or future. Default: swap

Request Example

Response Example


GET /order-execution/execution/leverage

Get current leverage and margin mode for a symbol.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, required): Trading pair (e.g., “BTC/USDT:USDT”)
  • market_type (string, optional): swap or future. Default: swap

Request Example

Response Example


POST /order-execution/execution/margin-mode

Set margin mode (cross or isolated) for a symbol.

Request Body (JSON)

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, required): Trading pair (e.g., “BTC/USDT:USDT”)
  • margin_mode (string, required): cross or isolated
  • market_type (string, optional): swap or future. Default: swap

Request Example

Response Example


GET /order-execution/execution/positions

Fetch open positions from exchange (futures/perp only).

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, optional): Filter by symbol
  • market_type (string, optional): swap or future. Default: swap

Request Example

Response Example


GET /order-execution/execution/funding-history

Fetch funding rate payments for perpetual futures.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, optional): Filter by symbol
  • since (number, optional): Start timestamp in milliseconds
  • limit (number, optional): Max number of records
  • market_type (string, optional): swap or future. Default: swap

Request Example

Response Example


GET /order-execution/execution/funding-rate

Fetch the current and predicted funding rate for a perpetual symbol, with the annualized APR precomputed. The predicted rate is the venue’s own live estimate of the next print. Responses are served through a server-side cache (about 30 seconds), so this endpoint is safe to poll.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, required): Perp symbol, e.g. BTC/USD:USD
  • market_type (string, optional): swap or future. Default: swap; derived from the symbol’s : convention when omitted

Request Example

Response Example

Field notes:
  • funding_rate / predicted_rate: relative rates per funding window, as normalized by ccxt. For Kraken Futures, ccxt converts the venue’s hourly absolute rate to an 8h-equivalent relative rate, so values are on the same scale as Binance/Bybit.
  • predicted_rate_source: next when the venue publishes a next-window estimate, current when the current rate is used as the fallback.
  • predicted_apr_pct: predicted_rate x windows_per_year x 100. Positive APR means shorts collect.
  • Venues without a funding-rate endpoint return a NOT_SUPPORTED error.

GET /order-execution/execution/realized-pnl

Fetch realized PnL for perpetual futures positions.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • symbol (string, optional): Filter by symbol
  • since (number, optional): Start timestamp in milliseconds
  • limit (number, optional): Max number of records
  • market_type (string, optional): swap or future. Default: swap

Request Example

Response Example


Inter-Wallet Transfer

Transfer Funds

Move balance between two wallets on the same exchange account. Used primarily for Kraken (spot ↔ futures, since they’re separate products at api.kraken.com vs futures.kraken.com), but the unified shape works on any exchange whose CCXT class exposes exchange.transfer(...) , Binance (spot ↔ usdm/coinm), OKX (funding ↔ trading), Gate.io. Bybit UTA and Hyperliquid have a single wallet and return NOT_SUPPORTED.

Authentication

Requires a valid API key whose user has the trader or admin role.

Request Body

string
required
The exchange account UUID
string
required
Asset code, e.g. "USD", "USDT", "BTC"
number
required
Positive amount to move
string
required
Source wallet: spot, swap, future, margin, funding, main, savings
string
required
Destination wallet (same vocabulary as from_account, must differ)

Response

Example, Kraken spot → futures

Example, Binance spot → USDⓈ-M futures


Portfolio Margin Endpoints (Binance)

The following endpoints are specific to Binance Portfolio Margin accounts. Portfolio Margin is a unified margin account that combines cross margin, USDⓈ-M Futures, and COIN-M Futures.

GET /order-execution/execution/portfolio-margin/balance

Get Portfolio Margin balance from Binance PAPI. Returns detailed breakdown of:
  • Cross Margin: Total, free, locked, borrowed, interest
  • USDⓈ-M Futures: Wallet balance, unrealized PnL
  • COIN-M Futures: Wallet balance, unrealized PnL

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID (must be a Binance PM account)

Request Example

Response Example


GET /order-execution/execution/portfolio-margin/account

Get Portfolio Margin account info from Binance PAPI. Returns raw PAPI balance and UM account data.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID (must be a Binance PM account)

Request Example

Response Example


POST /order-execution/execution/portfolio-margin/auto-collection

Trigger auto-collection for Portfolio Margin account. Transfers all positive balances from USDⓈ-M and COIN-M Futures Wallets to Cross Margin Wallet.
BNB in USDⓈ-M Futures Wallet will NOT be transferred.

Request Body (JSON)

  • exchange_account_id (string, required): The exchange account UUID (must be a Binance PM account)

Request Example

Response Example


POST /order-execution/execution/portfolio-margin/asset-collection

Trigger asset-specific collection for Portfolio Margin account. Transfers a specific asset from Futures Account to Margin account.
BNB transfer is NOT supported.

Request Body (JSON)

  • exchange_account_id (string, required): The exchange account UUID (must be a Binance PM account)
  • asset (string, required): Asset to transfer (e.g., “USDT”, “BTC”)

Request Example

Response Example


Portfolio Margin Notes

What is Portfolio Margin?

Portfolio Margin is a margin system that calculates margin requirements based on the overall risk of your portfolio, rather than individual positions. This typically results in lower margin requirements compared to traditional isolated margin.

Key Concepts

Setting Up Portfolio Margin

To use Portfolio Margin endpoints, your Binance account must:
  1. Have Portfolio Margin enabled on Binance (requires manual application)
  2. Be registered in Renesis with portfolio_margin: true
  3. Meet Binance’s minimum equity requirements ($100,000+ in some regions)

PAPI Endpoints Used

These endpoints call Binance’s Portfolio Margin API (PAPI):

GET /oems/tca/report

Account-wide Transaction Cost Analysis over a lookback window: slippage vs mark, maker/taker capture, effective fee rate vs the account’s tier, cost drag as bps of turnover and % of NAV, post-fill markout (adverse-selection signal), a detailed adverse_selection block (markout term structure, spread decomposition, per-fill distribution), a per-symbol breakdown, and a daily time-series for trend charts. Covers all fills (manual, algo, SOR), not just algo runs. Complements the per-algo TCA (which benchmarks a single algo run against its arrival price). Slippage is benchmarked against the mark price at fill time; positive = cost. Maker fills that rest and fill better than mark show negative slippage (price improvement). Slippage and markout require a mark price, which exists only on perps, so the report is perp-first (market_type=swap). On market_type=spot those blocks are null and only fees are reported; spot fees are charged in the base asset and are converted to USD so cost bps is not inflated by 1/price. Markout is the price drift in the minutes after each fill (default horizon 5m), signed so positive = favourable to the position and negative = adverse. A persistently negative maker markout means passive orders were getting run over: maker_net_edge_bps (fee saved by resting + maker markout) below zero flags fills where crossing (taker) would have been cheaper.

Query Parameters

  • exchange_account_id (string, required): The exchange account UUID
  • market_type (string, optional): swap or spot. Default: swap. Slippage/markout are perp-only.
  • symbol (string, optional): Restrict to one symbol
  • start / end (int ms, optional): Window bounds. Default: last 30 days

Request Example

Response Example

rebate_gap_bps = bps of turnover you would save by shifting the taker portion of flow to maker (at your tier’s maker/taker rates). Fills without a mark price are excluded from slippage but still counted in fees and turnover. by_day.date is the day-start epoch ms (UTC); rows are sorted ascending for trend charts. fees.estimated is true when a venue omits per-fill fees (e.g. Kraken Futures /fills) and the fee was computed from your deterministic tier rate (notional x rate) rather than reported per fill.

Adverse selection (adverse_selection)

The detailed post-fill analysis, one level below the scalar markout block. The scalar markout is a single point at the primary horizon (5m); this block adds the shape, the microstructure decomposition, and the distribution.
  • markout_curve_bps (and maker_/taker_ splits): the markout term structure, i.e. volume-weighted signed drift measured at each horizon in horizons_min ([1, 2, 5, 15, 30] minutes). The shape is the read: an early dip that recovers means you crossed into momentum or got picked off at entry; a rise that fades means your resting flow gets faded. Horizons vary per fill (recent fills have not reached the longer ones yet), so each horizon is aggregated over the fills that have it. Horizons below 1m are not available (1m is the OHLCV floor).
  • spread_decomposition: the identity effective_spread = realized_spread + price_impact, from the liquidity taker’s side. effective_spread_bps is the concession paid vs mark at the fill (the slippage). price_impact_bps is the post-fill drift in the trade’s favour (the markout) and is the information / adverse-selection component the resting counterparty bore. realized_spread_bps = effective - impact is what a maker on the other side actually kept; negative means the makers who filled you lost money after the drift, i.e. your flow was informed (“toxic”).
  • distribution: the spread of per-fill markout at the primary horizon (median, quartiles, best/worst, and adverse_fill_pct = share of fills with negative markout). A mean hides that a couple of toxic fills can dominate. low_sample is true when the fill count is too small (< 5) to read as stable.
  • by_symbol: the same curve, decomposition, and distribution per symbol.

GET /oems/tca/metrics

Headline-only variant of /tca/report (the cost, fills, fees, markout, and adverse_selection blocks, without the per-symbol or daily breakdown) for compact widgets and alerts. Same query parameters.