# Broker API integration: REST, WebSocket and FIX

URL: https://fincodelabs.com/en/blog/broker-api-integration-fix-rest · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Category: Fintech development · Published: 2026-10-25 · Updated: 2026-11-05

Broker API integration: REST and WebSocket vs FIX sessions, sequence numbers, execution reports, client order IDs, drop copies and certification tests.

**Short answer:** **Broker API integration** connects an application to a broker's order and account systems, usually through REST requests with WebSocket streams or through a FIX session. REST suits app and web integrations, while FIX is a stateful, sequence-numbered session standard used by institutions and exchanges; either way the integration needs unique client order IDs, an order state machine, reconciliation against the broker's records and the broker's certification or test process before going live.

Placing an order through an API looks like one request. In production it is a conversation: the order is acknowledged, partly filled, amended or rejected, the connection drops at the wrong moment, and at the end of the day your records must match the broker's exactly.

This guide is based on the FIX Trading Community's specifications, Borsa Istanbul's public technical pages and the public API documentation of Interactive Brokers and Alpaca, used only as examples and checked in October 2026. No broker is recommended, and automated trading can lose money.

## How apps connect to brokers: REST, WebSocket and FIX

Brokers expose a few kinds of interface, and many offer more than one.

**Broker API styles**

| Style | How it works | Typical users |
| --- | --- | --- |
| REST | Stateless HTTPS requests for orders, positions and history | Apps, web platforms, smaller strategies |
| WebSocket stream | Persistent connection pushing order updates and prices | The same clients, for real-time state |
| FIX | Stateful session with sequence numbers, heartbeats and recovery, often over private lines | Institutions, brokers, exchanges |
| SDK and gateway | Vendor library talking to a local gateway application | Desktop and server strategies |

Interactive Brokers shows the range: its API page describes a REST Web API with WebSocket streaming, a TWS API for C++, C#, Java, Python and other languages, and a FIX connection over VPN, extranet, leased line or cross-connect. Alpaca documents a REST trading API with a separate paper trading endpoint. Exchanges sit one level further down: Borsa Istanbul takes orders from members over FIX 5.0 SP2 and its binary OUCH protocol, not from end clients, as explained in [Borsa Istanbul API and market data](https://fincodelabs.com/en/blog/borsa-istanbul-api-market-data).

## FIX API vs REST API

REST is easier to start with, while FIX is built for continuous, recoverable order flow; the choice depends on volume, latency and the counterparty.

**FIX and REST compared**

| Aspect | REST and WebSocket | FIX |
| --- | --- | --- |
| State | Requests stand alone; streams reconnect and resubscribe | A session whose sequence numbers survive reconnects |
| Recovery | Query open orders and fills after a drop | Resend request for the missing sequence range |
| Liveness | Timeouts and ping frames | Heartbeats at an agreed interval, test requests |
| Connectivity | Public internet with TLS | Often private lines, VPN or cross-connects |
| Onboarding | API keys, often self-service | Session set-up, certification, contracts |
| Messages | Broker-specific JSON | Standard messages and fields plus documented extensions |

FIX's main advantage is standardization and recovery rather than raw speed: the same NewOrderSingle and ExecutionReport semantics apply across counterparties, which matters when one system connects to several brokers.

## Inside a FIX session: logon, heartbeats and sequence numbers

A FIX session is a long-lived conversation in which every message carries a sequence number, and both sides must detect and repair gaps.

- **Logon (35=A)** opens the session and carries HeartBtInt (108), which the FIX Session Layer standard (June 2020) defines as the maximum time allowed between messages from the peer.
- **Heartbeat (35=0) and TestRequest (35=1):** each side sends heartbeats when idle; if nothing arrives within the interval it sends a test request, which the peer must answer with a heartbeat echoing the TestReqID.
- **Gaps:** if an incoming MsgSeqNum (34) is higher than expected, the receiver sends a ResendRequest (35=2). Resent messages carry PossDupFlag (43) set to Y, and a SequenceReset (35=4) with GapFillFlag (123) skips messages that will not be resent. A lower number without PossDupFlag is a serious error that ends the session.

Venues add their own rules of engagement on top of the standard. Borsa Istanbul publishes its Genium INET FIX, FIX drop copy and FIX reference data specifications on its technical documents page, and its cancel on disconnect service, provided to trading members only on request, suspends a FIX or OUCH user's active orders when the connection is lost; suspended orders can be reactivated from the Trader Workstation.

This tested sketch builds a NewOrderSingle with synthetic values, with BodyLength (9) and CheckSum (10), the three-digit modulo 256 sum of the preceding bytes:

```python
SOH = "\x01"

def fix_message(msg_type, fields, begin="FIXT.1.1"):
    body = f"35={msg_type}{SOH}" + "".join(f"{tag}={val}{SOH}" for tag, val in fields)
    head = f"8={begin}{SOH}9={len(body.encode('ascii'))}{SOH}"
    checksum = sum((head + body).encode("ascii")) % 256
    return f"{head}{body}10={checksum:03d}{SOH}"

def checksum_ok(raw):
    head, _, tail = raw.rpartition(f"{SOH}10=")
    return int(tail.rstrip(SOH)) == sum((head + SOH).encode("ascii")) % 256

order = fix_message("D", [                      # NewOrderSingle, synthetic values
    (49, "CLIENT1"), (56, "BROKER1"), (34, 2), (52, "20261023-07:15:00.000"),
    (11, "20261023-0001"), (55, "XYZ"), (54, 1), (60, "20261023-07:15:00.000"),
    (38, 100), (40, 2), (44, "101.25")])
print(order.replace(SOH, "|"))
print("checksum ok:", checksum_ok(order))
print("tampered:", checksum_ok(order.replace("38=100", "38=900")))
```

Output, with the SOH delimiter shown as |:

```
8=FIXT.1.1|9=133|35=D|49=CLIENT1|56=BROKER1|34=2|52=20261023-07:15:00.000|11=20261023-0001|55=XYZ|54=1|60=20261023-07:15:00.000|38=100|40=2|44=101.25|10=125|
checksum ok: True
tampered: False
```

A production FIX engine adds message stores, resend handling and validation against the counterparty's rules of engagement.

## Orders, execution reports and the order state machine

An order is a state machine driven by the broker's execution reports, not by your requests.

In FIX, NewOrderSingle (35=D) requires ClOrdID, Side, TransactTime, OrdType, the order quantity and the instrument. The broker answers with ExecutionReport (35=8) messages carrying OrderID, ExecID, ExecType (150, what this report is), OrdStatus (39, the order's current state), LeavesQty (151) and CumQty (14). Cancels (35=F), replaces (35=G) and status requests (35=H) follow the same pattern, and a refused cancel or replace returns OrderCancelReject (35=9).

**Core order states, OrdStatus values in FIX Latest**

| State | OrdStatus | Typical next states |
| --- | --- | --- |
| New | 0 | Partially filled, filled, canceled, rejected |
| Partially filled | 1 | Filled, canceled |
| Filled | 2 | Final |
| Canceled | 4 | Final |
| Rejected | 8 | Final |
| Expired | C | Final |

> **Hypothetical example:** a limit buy for 1,000 shares is acknowledged (ExecType 0, OrdStatus 0, LeavesQty 1,000, CumQty 0), fills 400 (ExecType F, OrdStatus 1, LeavesQty 600, CumQty 400) and is then canceled (ExecType 4, OrdStatus 4, LeavesQty 0, CumQty 400). The position is 400 shares, not 1,000.

REST brokers use the same states under their own names. Position logic must use the cumulative filled quantity, never the requested one, and tests should include partial fills: Alpaca's paper trading documentation, for example, says fills are simulated from real-time quotes without market impact and that orders receive partial fills at random 10% of the time.

## Client order IDs and idempotency

Give every order a unique client order ID before the first send, and never resend an order whose fate is unknown without first asking about that ID.

FIX Latest requires ClOrdID (11) to be unique within a single trading day and advises firms with multi-day orders to keep it unique across days, for example by embedding a date. REST APIs use the same idea under other names; Alpaca's order endpoint accepts a client_order_id of up to 128 characters.

The failure to design for is a timeout after sending, when the order may or may not exist. The safe sequence is to mark it unknown, query by client order ID and act only on the answer, as shown in a tested sketch in [trading bot development](https://fincodelabs.com/en/blog/trading-bot-development). Duplicate identical orders should also be stopped by a pre-trade check; see [trading bot risk management](https://fincodelabs.com/en/blog/trading-bot-risk-management).

## Drop copies, reconciliation, permissions and audit logs

The broker's records are the reference, so an integration needs an independent copy of the order flow and a regular comparison with it.

- **Drop copy:** a separate feed replicating order and trade messages; Borsa Istanbul's FIX Drop Copy replicates private order, quote and trade flow, with filters by user.
- **Reconciliation:** at start-up, after reconnects and at end of day, compare open orders, fills and positions with the broker, and stop new orders on any unexplained difference.
- **Entitlements:** roles such as viewer, trader and approver, account and instrument limits, and a second approval above thresholds.
- **Audit log:** append-only records of who sent what, with which approval, and what the broker answered, on synchronized clocks.

How these parts fit into one system is shown in the [broker order management integration](https://fincodelabs.com/en/projects/broker-order-management-integration) scenario. Order state inside your own system is covered in [an order management system](https://fincodelabs.com/en/blog/crypto-order-management-system).

## Certification and conformance testing

Counterparties test your software before they let it trade, and their certification programs show what they consider essential.

Borsa Istanbul requires members to obtain a FIX or OUCH certificate for their software or to use a certified application, and it lists the companies whose software holds a BISTECH FIX certificate. Its technical documents page publishes FIX order entry and FIX reference data certification programs for each market, among them base and advanced order entry levels for the equity market uploaded on 5 November 2025, together with OUCH certification programs and a FIX simulator application.

Brokers run their own conformance programs for clients, and REST brokers usually offer a sandbox or paper environment instead. Either way, script your own tests for logon and sequence recovery, disconnects, rejects and partial fills, and keep the evidence.

## Regulation and TradingView broker integration

Who may connect to what is set by regulation and contracts, not by the API.

In Turkey, receiving and transmitting orders is an investment service under Article 37 of Capital Markets Law No. 6362, which Article 39 reserves for authorized investment firms. Borsa Istanbul's algorithmic trading procedure (revision 7, 28 March 2025) states that a client cannot send orders to the exchange without the member's systems, and members must inform the exchange in writing about the algorithm software they use. Other jurisdictions have their own rules on algorithmic trading and market access, so confirm them with the broker and local counsel.

TradingView's Broker Integration API is not a broker API for your app: it lets brokers connect their backend systems to the TradingView interface. A trader who wants TradingView alerts to place orders uses webhooks instead, as described in [TradingView webhook bot](https://fincodelabs.com/en/blog/tradingview-webhook-bot). Broker and exchange connections are the scope of the [exchange API integration](https://fincodelabs.com/en/services/exchange-api-integration) service.

## Frequently asked questions

### What is a FIX API in trading?

A connection to a broker or venue using the FIX protocol: a stateful session with sequence-numbered messages such as NewOrderSingle and ExecutionReport. It is standard among institutions and exchanges and usually requires certification.

### Is FIX faster than REST?

It can be, mainly through persistent sessions and private connectivity, but its main advantages are standard messages and built-in recovery. For most apps, REST with WebSocket streams is enough and simpler to operate.

### Can I use a broker API from Python?

Yes. Most REST and WebSocket APIs work with standard Python HTTP and WebSocket libraries, and some brokers publish Python SDKs; test on the broker's sandbox or paper environment first.

### What is a drop copy?

A separate feed that replicates your order and trade messages, so a risk or back-office system can track activity independently of the trading session.

### Do I need certification to use a FIX API?

Usually. Borsa Istanbul requires members to certify their FIX and OUCH software or use certified applications, and brokers commonly run conformance tests before enabling a production session.

## Sources

- [FIX Trading Community: FIX Session Layer Technical Specification (June 2020)](https://www.fixtrading.org/wp-content/uploads/download-manager-files/FIX_Session_Layer_June_2020.pdf)
- [FIX Latest on Orchimate: message list and MsgType values](https://orchimate.org/fixtrading/fix-latest/messages)
- [FIX Latest on Orchimate: NewOrderSingle](https://orchimate.org/fixtrading/fix-latest/messages/NewOrderSingle)
- [FIX Latest on Orchimate: ExecutionReport](https://orchimate.org/fixtrading/fix-latest/messages/ExecutionReport)
- [FIX Latest on Orchimate: ClOrdID (11)](https://orchimate.org/fixtrading/fix-latest/fields/ClOrdID)
- [Borsa Istanbul: BISTECH connection protocols](https://borsaistanbul.com/en/bistech-technology/protocols)
- [Borsa Istanbul: Technical documents (FIX, OUCH, ITCH and TIP specifications, certification programmes)](https://www.borsaistanbul.com/en/technical-resources/technical-documents)
- [Borsa Istanbul: COD (Cancel on Disconnect)](https://www.borsaistanbul.com/en/technology-services/risk-management/cod-cancel-disconnect)
- [Borsa Istanbul: Procedure on algorithmic trading and BISTECH PTRM in the Equity Market, revision 7 (28 March 2025) (Turkish)](https://www.borsaistanbul.com/files/pay-piyasasinda-algoritmik-islemler-ve-bistech-ptrm-islem-oncesi-risk-yonetimi-proseduru.pdf)
- [Interactive Brokers: IBKR trading API solutions](https://www.interactivebrokers.com/en/trading/ib-api.php)
- [Alpaca: Paper trading](https://docs.alpaca.markets/us/docs/paper-trading)
- [Alpaca: Create an order (client_order_id)](https://docs.alpaca.markets/us/reference/postorder)
- [TradingView: REST API for Brokers](https://www.tradingview.com/broker-api-docs/)
- [Turkish legislation database: Capital Markets Law No. 6362, Articles 37 and 39 (Turkish)](https://www.mevzuat.gov.tr/MevzuatMetin/1.5.6362.pdf)

> This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the [editorial policy](https://fincodelabs.com/en/editorial-policy).

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/blog/broker-api-integration-fix-rest

Cite as: Fincode, "Broker API integration: REST, WebSocket and FIX", updated November 5, 2026, https://fincodelabs.com/en/blog/broker-api-integration-fix-rest