Foxbit FIX API (1.0)

Welcome to the official Foxbit's FIX API documentation. The FIX (Financial Information eXchange) API targets institutional clients, market makers and trading systems that already speak FIX and require a low-latency, persistent session for order entry and market-data consumption.

The endpoint accepts standard FIX v4.4 messages over a single TCP session. Authentication, order entry, market data and reference data are all multiplexed onto the same connection, there is no separate trade vs. market-data channel.

Please contact our customer relationship team to obtain the access URL, the default port, and to request IP whitelisting in order to access the FIX API from your server.

Features

• Persistent FIX v4.4 session with HMAC-SHA256 authenticated Logon.
• Order entry with synchronous accept/reject and asynchronous fill / cancel / reject events.
• Real-time order book streaming via snapshot + incremental refresh.
• Reference-data discovery for tradeable instruments.

Wire-Format Notation

Examples throughout this document show messages in the canonical FIX wire format tag=value with | standing in for the field separator byte SOH (0x01). Replace | with 0x01 when writing bytes to the socket.

BodyLength (9) and CheckSum (10) are computed by the FIX engine, the values in the examples are illustrative; do not copy them verbatim into hand-built messages.

Need More?

If you don't find something here, check our other API documentation:

See all available APIs

The FIX endpoint is exposed exclusively over TLS, plain-text TCP is rejected at the listener and never reaches the FIX engine. Clients must complete the TLS handshake before sending Logon (35=A).

Requirements

• TLS version: 1.2 or 1.3. Earlier versions (SSL 3.0, TLS 1.0, TLS 1.1) are refused.
• Authentication: server-side TLS only. Clients verify the server certificate during the handshake; no client certificate is requested. Session-level authentication is performed at Logon (35=A), see the Authentication section.

Obtaining the Server Certificate

The server certificate needed to validate the TLS handshake is distributed by Foxbit. To request the current certificate contact Foxbit support through the Help Center.

Install the provided certificate in the trust store used by your FIX client. Do not disable certificate verification, an unverified connection bypasses the only transport-layer protection against a man-in-the-middle.

Inbound application messages are rate-limited per MsgType. Each MsgType has its own bucket, so a burst of one kind of request does not consume another's budget.

MarketDataRequest (35=V) is the exception: it is not rate-limited, and is bounded by a ceiling on concurrently subscribed markets instead — see Market-data subscription limit below.

The Logon (35=A) limit is keyed by source IP and enforced before authentication. The remaining limits are keyed by the authenticated trading account and enforced after it; the bucket is shared across every session of the same account, so opening additional sessions does not multiply the budget.

MsgType	Limit	Scope
Logon (35=A)	10 per 2 seconds	per source IP
MarketDataRequest (35=V)	25 subscriptions	per message
NewOrderSingle (35=D)	30 per 2 seconds	per account
OrderCancelRequest (35=F)	30 per 2 seconds	per account
OrderStatusRequest (35=H)	30 per 2 seconds	per account
RequestForPositions (35=AN)	5 per minute	per account
SecurityListRequest (35=x)	6 per second	per account
TradeCaptureReportRequest (35=AD)	5 per second	per account

Behaviour on rejection

When the limit is exceeded the response depends on the inbound message:

• Logon (35=A) is rejected with a Logout (35=5); the connection is closed.
• NewOrderSingle (35=D) is answered with an ExecutionReport (35=8) carrying OrdStatus=8 Rejected, OrdRejReason=3 Order exceeds limit and Text=Request limit exceeded. Try again later..
• OrderCancelRequest (35=F) is answered with an OrderCancelReject (35=9) carrying CxlRejReason=99 Other and Text=Request limit exceeded. Try again later..
• SecurityListRequest (35=x) is answered with a SecurityList (35=y) carrying SecurityRequestResult=4.
• OrderStatusRequest (35=H) is answered with an ExecutionReport (35=8) carrying ExecType=8 Rejected, OrdStatus=8 Rejected and Text=Request limit exceeded. Try again later..
• RequestForPositions (35=AN) is answered with a RequestForPositionsAck (35=AO) carrying PosReqResult=99 Other, PosReqStatus=2 Rejected.
• TradeCaptureReportRequest (35=AD) is answered with a TradeCaptureReportRequestAck (35=AQ) carrying TradeRequestResult=99 Other, TradeRequestStatus=2 Rejected.

Market-data subscription limit

MarketDataRequest (35=V) is not rate-limited (bursts are paced server-side and serviced over a few seconds). What is bounded is concurrently subscribed markets: 150 per account, shared across all sessions. It counts markets, not requests: every market in NoRelatedSym is charged, so batching buys nothing, and a 35=V is accepted or rejected in full. Independently, a request may name at most 25 markets; splitting is fine as long as the account limit holds.

Only SubscriptionRequestType=1 Snapshot + Updates charges capacity; 0 Snapshot is free. Capacity returns on SubscriptionRequestType=2 and on logout. Cancels are exempt from both caps, so any subscription unwinds in one request, and capacity frees the moment the cancel is accepted, not when the broker confirms it, so a client at the limit can rotate by sending 2 then 1 without waiting. A cancel naming no symbols frees the whole subscription; one naming symbols frees only those, and the rest stay charged. Re-subscribing under a streaming MDReqID replaces its market set, but is charged in full while the old set is still counted, so a near-limit re-subscribe may be refused now and accepted a moment later; if it is rejected, the previous set keeps streaming.

Both failures return MarketDataRequestReject (35=Y) with MDReqRejReason=2 Insufficient bandwidth, as FIX 4.4 has no distinct value; Text tells them apart. Over the account limit: Text=Subscription limit exceeded. Unsubscribe before subscribing to more markets., not retryable until markets are canceled. Over 25 in one request: Text=Too many markets in one request. A MarketDataRequest may name at most 25 markets. Split the request.

Every FIX session is authenticated at Logon (35=A) with an HMAC-SHA256 signature derived from the session's API secret. The signature is presented in RawData (96) and verified server-side against the API key declared in Username (553).

Credentials

Credentials are issued per integration and bound to a role. Only API keys carrying the trade role are accepted by the FIX endpoint; keys without that role are rejected with a generic Logout even if the signature is otherwise valid.

A single API key may also restrict the IP addresses allowed to authenticate with it. When configured, the Logon is rejected if the source IP is not on the trusted list.

Signature Construction

The signature input (the prehash) concatenates five fields from the Logon message, separated by the FIX field-separator byte (SOH, 0x01):

prehash = SendingTime(52) + SOH + MsgType(35) + SOH + MsgSeqNum(34) + SOH + Username(553) + SOH + TargetCompID(56)

The signature is then:

RawData(96) = Base64( HMAC-SHA256( apiSecret, prehash ) )

RawDataLength (95) carries the byte length of the Base64-encoded signature.

Example (Python):

import base64, hmac, hashlib

sending_time   = "20260508-12:00:00.000"
msg_type       = "A"
msg_seq_num    = "1"
api_key        = "<your-api-key>"
target_comp_id = "FOXBIT-FIX-API"
api_secret     = "<your-api-secret>"

prehash = "\x01".join([sending_time, msg_type, msg_seq_num, api_key, target_comp_id])
signature = base64.b64encode(
    hmac.new(api_secret.encode(), prehash.encode(), hashlib.sha256).digest()
).decode()

Time Synchronization

SendingTime (52) must carry the current UTC timestamp at the moment the Logon is sent and must be unique per attempt. Keep the client clock synchronized via NTP, large clock skew can cause timestamp validation failures.

Recommended Client Flow

1. Open the TCP connection to the FIX endpoint.
2. Send Logon (35=A) with Username, RawData, RawDataLength, SendingTime and MsgSeqNum.
3. Wait for the inbound Logon echo before sending application messages.
4. On any Logout (35=5) carrying Text, treat the session as terminated and inspect the reason before reconnecting.

Authenticates the session. Must be the first application-level message sent after the TCP connection is established. See the Authentication section for the signature construction and the recommended flow.

On a successful authentication the server replies with a Logon (35=A) echo. From this point on, application messages are accepted on the session.

Authentication failures fall into two categories:

A protocol-level rejection is sent as a BusinessMessageReject (35=j) with BusinessRejectReason=5 Conditionally required field missing and RefTagID=96 when the signature is mathematically invalid for the supplied prehash.

All other failures (missing required tag, unknown API key, role mismatch, IP not whitelisted) are reported as a Logout (35=5) carrying a generic Text="could not process logon". The connection is then closed.

Common causes:

• Incorrect API key, secret or signature concatenation.
• Client clock skew beyond the allowed window.
• API key without the trade role.
• Source IP not on the API key's trusted-IP list.

Submits a new order to the matching engine. Only Limit orders are supported on this version of the API; OrdType (40) must be set to 2 Limit. Orders carry one of two time-in-force values:

• IOC (TimeInForce=3 Immediate Or Cancel): match what is available, cancel the remainder immediately.
• FOK (TimeInForce=4 Fill Or Kill): match the entire size or cancel; no partial fills.

Decimal precision is preserved end-to-end: OrderQty, Price, StopPx and CashOrderQty are decimal strings and are forwarded to the matching engine without floating-point conversion.

Every NewOrderSingle is acknowledged with at least one ExecutionReport (35=8). Subsequent fill, cancel and reject events are also delivered as ExecutionReport. See the ExecutionReport section for the full response schema.

Cancels a single working order (for example a resting GTC limit order). The order is located by one of two lookup keys, at least one of which must be present:

• OrderID (37): the numeric exchange id assigned on order creation (echoed on every ExecutionReport). Preferred key.
• OrigClOrdID (41): the original numeric client order id.

When both are supplied OrderID (37) takes precedence. ClOrdID (11) identifies the cancel request itself and is required.

Cancellation is asynchronous: submitting 35=F only registers the request; there is no synchronous confirmation that the order left the book. Order Cancel/Replace (35=G) is out of scope.

An accepted request is acknowledged synchronously with an ExecutionReport (35=8) carrying ExecType=6 PendingCancel / OrdStatus=6 Pending Cancel. The order actually leaving the book is reported asynchronously as a later ExecutionReport with ExecType=4 Canceled / OrdStatus=4 Canceled — which also carries the final CumQty (14) when the order was partially filled before cancellation. See the ExecutionReport section.

A cancel that cannot be honored is refused with an OrderCancelReject (35=9) carrying CxlRejResponseTo=1, a coded CxlRejReason (102) and the reason in Text (58):

• Unknown order → 102=1, Text=order not found.
• Already executed / already canceled → 102=0 Too late, Text=order already executed / Text=order already canceled.
• Already pending cancel → 102=3, Text=order already pending cancel.
• Not authenticated, backend failure, or rate-limit denial → 102=99.

A message carrying neither OrderID (37) nor OrigClOrdID (41) is rejected at the protocol level with Reject (35=3).

ExecutionReport is the outbound message that carries every state change for an order. The same MsgType is reused with different ExecType (150) and OrdStatus (39) combinations to express acceptance, fills, cancellation and rejection.

All variants always populate: OrderID (37), ExecID (17), ExecType (150), OrdStatus (39), Side (54), LeavesQty (151), CumQty (14) and AvgPx (6). Other fields are populated when applicable to the variant.

Sent immediately after the matching engine accepts the order; the order is now live on the book.

Emitted on every fill, partial or full. LastQty (32) and LastPx (31) carry the fill, while CumQty (14) and LeavesQty (151) carry the running totals. OrdStatus is 1 Partially filled or 2 Filled depending on whether LeavesQty reaches zero.

Emitted when the order is canceled, by user request, by the engine (e.g. unfilled remainder of an IOC) or by external constraints. OrdRejReason (103) is populated only when the cancellation was driven by an engine-side condition (no liquidity, price out of range, etc.); user-initiated cancels do not carry tag 103.

Emitted when the order cannot be accepted. The same ExecType=8 Rejected covers synchronous rejections (validation failures, rate-limit denial, insufficient funds) and asynchronous rejections raised by the matching engine after the initial accept.

OrdRejReason (103) is mapped from the underlying error code; Text (58) carries a human-readable reason. See the table below for the supported OrdRejReason values.

OrdRejReason (103)	Meaning	When
1 Unknown symbol	The market in Symbol (55) does not exist.	Sync reject.
2 Exchange closed	Trading on the requested side or market is currently disabled.	Sync reject.
3 Order exceeds limit	Insufficient funds, too many open orders or rate-limit denial.	Sync reject.
30 Last look	Limit price is outside the protective band; the order would have crossed at an off-market price.	Sync or async reject; also async cancel.
32 No liquidity	IOC with nothing to match, FOK with insufficient resting volume, or insufficient remaining size on the book.	Async cancel for IOC/FOK; sync reject for "market not deep enough".
99 Other	Catch-all for any reason not represented above.	Any reject path.

Fetches the current state of a single, already-submitted order on demand. Use it to reconcile an order whenever needed — for example after a reconnect, or when an expected ExecutionReport was missed. It queries live order state directly and does not replay the order's past execution events.

The order is located by one of two lookup keys, at least one of which must be present:

• OrderID (37): the numeric exchange id assigned on order creation (echoed on every ExecutionReport). Primary lookup key.
• ClOrdID (11): the client-supplied order identifier.

When both are supplied both filters are applied. OrdStatusReqID (790) is optional and echoed on the response for correlation.

The order is returned as a single ExecutionReport (35=8) carrying ExecType=I Order Status — distinct from the ExecType values used by the execution events pushed as the order works. OrdStatus (39) reflects the order's current state; OrderQty (38), CumQty (14) and LeavesQty (151) carry the original, filled and remaining quantities.

Failures are reported as a rejected ExecutionReport (35=8) with ExecType=8 Rejected, OrdStatus=8 Rejected and the reason in Text (58), echoing the request identifiers so the rejection stays correlated:

• No order matches the supplied key → Text=order not found.
• Session not authenticated, or API key revoked mid-session → Text=not authenticated / Text=authentication revoked.
• Backend/transport failure (retryable) → Text=internal error.
• Rate-limit denial → Text=Request limit exceeded. Try again later..

A message carrying neither ClOrdID (11) nor OrderID (37) is rejected at the protocol level with Reject (35=3), since there is no identifier to echo on an ExecutionReport.

Lists every tradeable market exposed on the API. Useful at session start to discover symbols, currencies and tick / lot sizes.

Only SecurityListRequestType=0 All Securities is supported. Other values are answered with SecurityList (35=y) carrying SecurityRequestResult=4 Invalid or unsupported request.

A successful request returns a single SecurityList (35=y) with SecurityRequestResult=0 Valid request and one NoRelatedSym block per market. Each block contains the symbol, currency, minimum tradeable volume and price/volume increments.

Failure modes:

• Unsupported SecurityListRequestType → SecurityRequestResult=4 Invalid or unsupported request.
• Underlying reference-data store unavailable → SecurityRequestResult=2 Instrument data temporarily unavailable.
• No markets configured → SecurityRequestResult=1 No instruments found that match selection criteria.
• Rate-limit denial → SecurityRequestResult=4 with Text=Request limit exceeded. Try again later..

Subscribes or unsubscribes the session to a level-2 order-book stream. Subscriptions are scoped to the session that issued the request; closing the session terminates all of its subscriptions automatically.

SubscriptionRequestType (263) selects the operation:

• 0 Snapshot: one-shot full book.
• 1 Snapshot + Updates: initial full book followed by incremental updates.
• 2 Disable previous snapshot + updates: unsubscribe a previously requested stream identified by MDReqID (262).

MDUpdateType (265) must be 1 Incremental refresh when subscribing with updates. 0 Full refresh is not supported on the stream and is rejected.

The first response is always a MarketDataSnapshotFullRefresh (35=W). On SubscriptionRequestType=1, subsequent updates are streamed as MarketDataIncrementalRefresh (35=X).

A MarketDataRequestReject (35=Y) is emitted on any of the following:

• Missing MDReqID or SubscriptionRequestType.
• No symbols specified in NoRelatedSym.
• Unsupported MDUpdateType (i.e. 0 Full refresh).
• Unknown SubscriptionRequestType value.
• Unsubscribe targeting an MDReqID that the session never opened.
• Order book temporarily unavailable for the requested symbol.
• The markets named would take the account past its subscribed-market limit (see Rate Limit).

See the MarketDataRequestReject section for the response schema.

Carries the full state of a level-2 order book at a point in time. Sent once on subscription and as the first message after SubscriptionRequestType=0 Snapshot only requests.

Each MDEntry describes one price level on either the bid or the ask side. MDEntryPositionNo (290) is the depth rank within the side, starting at 1.

Streams individual book updates after the initial MarketDataSnapshotFullRefresh. Sent only when subscribing with SubscriptionRequestType=1 Snapshot + Updates.

Each MDEntry carries an MDUpdateAction (279) describing the operation to apply to the local book:

• 0 New: new price level.
• 1 Change: quantity update at an existing level.
• 2 Delete: level removed from the book.

The recipient is expected to apply each entry in order to the local book mirror keyed by (Symbol, MDEntryType, MDEntryPx).

Sent in response to a MarketDataRequest (35=V) that cannot be served. The original request is identified by echoing MDReqID (262).

The textual reason is delivered in Text (58); MDReqRejReason (281) is not used on this version of the API.

Requests a snapshot of the authenticated member's account balances. Balances are exposed through the FIX position family: each currency the member holds maps to one position entry whose LongQty (704) is the available (spendable) balance.

PosReqType (724) must be 0 Positions. SubscriptionRequestType (263) selects 0 Snapshot or 1 Snapshot + Updates; on this version both are served as a one-shot snapshot (continuous push is a future milestone). An optional Currency (15) restricts the snapshot to a single ISO-4217 asset (matched case-insensitively).

The request is acknowledged with a RequestForPositionsAck (35=AO) carrying PosReqResult=0 Valid request, followed by one PositionReport (35=AP) per currency. A valid request that matches no currency yields the accepted AO and zero PositionReport messages — an empty snapshot is not an error.

A RequestForPositionsAck (35=AO) with PosReqStatus=2 Rejected is emitted on:

• Unsupported PosReqType (anything other than 0 Positions) or SubscriptionRequestType (e.g. 2 Disable) → PosReqResult=1 Invalid or unsupported request.
• Session not authenticated, or API key revoked mid-session → PosReqResult=3 Not authorized to request positions.
• Backend/transport error or rate-limit denial → PosReqResult=99 Other (retryable).

A malformed message missing PosReqID (710) or PosReqType (724) is rejected at the protocol level with Reject (35=3).

Acknowledges a RequestForPositions (35=AN). On success it precedes the PositionReport (35=AP) sequence; on failure it carries the rejection reason in Text (58) and no reports follow. The original request is identified by echoing PosReqID (710).

PosReqResult (728) distinguishes the outcome: 0 valid, 1 invalid/unsupported, 3 not authorized, 99 other (including rate-limit denial). PosReqStatus (729) is 0 Completed when accepted and 2 Rejected otherwise.

Carries the balance for a single currency. One message is sent per currency in the snapshot, after the optional Currency (15) filter on the request.

The balance is LongQty (704) inside the NoPositions (702) group — always exactly one entry — with PosType (703)=POS. Currency (15) identifies the asset and TotalNumPosReports (727) is the number of reports in the snapshot, so the client knows when the sequence is complete.

Requests a point-in-time snapshot of the authenticated member's trades (fills). Use it to reconcile fills — for example after a reconnect, or when an expected fill ExecutionReport was missed. It reads current trade state on demand and does not stream: live fills continue to arrive on the asynchronous ExecutionReport path.

A request must be scoped in one of two ways.

By order. One of two lookup keys:

• OrderID (37): the numeric exchange id assigned on order creation (echoed on every ExecutionReport). Primary lookup key.
• ClOrdID (11): the client-supplied order identifier, resolved to the numeric order id first.

OrderID (37) takes precedence when both are supplied (ClOrdID is then ignored).

By time window. A NoDates (580) group carrying one or two entries: the first entry's TransactTime (60) opens the window, the second closes it. Omit the second entry to run the window up to the moment the request is received. Both bounds are inclusive, evaluated to whole-second precision and rounded outwards, so the window served is never narrower than the one requested.

Both bounds are UTC, as FIX defines TransactTime (60). A local wall-clock time sent in its place shifts the window by the offset and silently reconciles the wrong period; where the shift puts the whole window ahead of the current time the request is rejected rather than answered with an empty snapshot.

Every NoDates (580) entry must begin with TradeDate (75), the YYYYMMDD date of that entry's bound. It is the group delimiter: an entry beginning with TransactTime (60) is not recognized as an entry, and the request is rejected.

A window is how fills missed during a disconnect are recovered. Sequence numbers reset on every logon, so a session-level ResendRequest cannot replay the ExecutionReports sent while the session was down.

A window may span at most 24 hours and match at most 1000 trades. Exceeding either is a rejection, not a truncated snapshot — a snapshot that arrives is always complete. Narrow the window and retry.

Symbol (55) is not a supported filter on this message, and TradeRequestType (569) must be 1 Matched trades matching criteria provided on request. Only a snapshot is served (SubscriptionRequestType (263) = 0 or omitted).

The request is acknowledged with a TradeCaptureReportRequestAck (35=AQ) carrying TradeRequestResult=0 Successful and TotNumTradeReports (748), followed by one TradeCaptureReport (35=AE) per trade, in ascending time order. Each report echoes TradeRequestID (568) and carries the same TotNumTradeReports (748); the final one is marked with LastRptRequested (912)=Y. A request that matches no trade yields the accepted AQ with TotNumTradeReports=0 and no reports — an empty snapshot is not an error.

A TradeCaptureReportRequestAck (35=AQ) with TradeRequestStatus=2 Rejected is emitted on:

• Unsupported TradeRequestType (anything other than 1) → TradeRequestResult=8.
• Session not authenticated, or API key revoked mid-session → TradeRequestResult=9.
• Unsupported SubscriptionRequestType; a request carrying neither an order key nor a time window; a window that ends before it starts, starts in the future, spans more than 24 hours, or matches more than 1000 trades; a backend or transport error; or rate-limit denial → TradeRequestResult=99.

A malformed message missing TradeRequestID (568) or TradeRequestType (569), or carrying a NoDates (580) group that is not encoded as described above, is rejected at the protocol level with Reject (35=3), so is a group whose TransactTime (60) is not a usable bound.

Acknowledges a TradeCaptureReportRequest (35=AD). On success it precedes the TradeCaptureReport (35=AE) sequence and states the count in TotNumTradeReports (748); on failure it carries the rejection reason in Text (58) and no reports follow. The original request is identified by echoing TradeRequestID (568).

TradeRequestResult (749) distinguishes the outcome: 0 successful, 8 trade request type not supported, 9 not authorized, 99 other (including rate-limit denial). TradeRequestStatus (750) is 1 Completed when accepted and 2 Rejected otherwise.

On rejection the same AQ carries TradeRequestStatus=2 Rejected, TotNumTradeReports=0 and the reason in Text (58); no TradeCaptureReport messages follow.

Carries a single member trade (fill). One message is sent per trade in the snapshot, after the TradeCaptureReportRequestAck (35=AQ) that states the total count.

The member's own side is the single NoSides (552) entry, carrying Side (54) and OrderID (37). A non-zero fee is reported on that entry as Commission (12) with CommType (13)=3 Absolute and CommCurrency (479).