Broker API integration services for your own account
Fincode connects your internal tools or rule-based software to a broker's API, on your own account: order state, rejects, positions and reconciliation against the broker's records. This page names no broker, because your country and your broker's terms decide what is possible. We read those first.
Who this suits
Companies trading for their own account
A treasury or desk that enters orders by hand on the broker's screen and tracks positions and limits in spreadsheets.
Traders with written rules
Rules you have written, an account in your own name and a broker that allows API access on that account. Building the rules into software is covered under trading bot development; this page covers the broker side.
Not a fit
A product that places orders for other people. That can bring licensing duties, and we decline projects that run on other people's accounts. A licensed firm with a different need, such as tools for its own desk, can send the scope and we will say in writing whether it fits.
Working with a crypto exchange instead? See exchange API integration. Building for a client of your agency? See work for agencies.
Why a broker API is not just another exchange API
The signing and the JSON are the easy part. These differences decide the design.
Access is part of the contract
API access can depend on your account type, your country, a separate agreement or a paid data subscription. Some routes are open to licensed firms or advisers and closed to individual accounts.
The instrument changes under you
Splits, dividends, symbol changes and contract expiries alter positions overnight, with no order from your software.
Markets close
Sessions, auctions, halts, price limits, tick sizes, holidays and half days. An order can be valid and still not be tradable now.
Prices have their own license
Order access does not include data rights. An algorithm reads prices with no person looking at a screen, which exchanges license as non-display use. Without the right subscription, an API may return delayed prices or none. See stock market data APIs.
A regulated firm stands in between
Your orders pass through your broker's systems and its checks. Borsa Istanbul's algorithmic trading procedure (opens in a new tab) (revision 7, 28 March 2025), for example, says a client cannot send orders to the exchange without the member's systems, and that members inform the exchange in writing about the algorithm software they use.
REST, FIX or a local gateway: what each one asks of you
Your broker may offer one route or several. Our guide to broker API integration explains the protocols. This is the operating side, and the scope document records the choice and why.
REST and WebSocket
Needs an API key or an OAuth login, and a server. Tokens can be short-lived, streams drop and need a fresh snapshot, and an HTTP 200 does not always mean the order was accepted. The scope covers token refresh, stream recovery and a status check on every order.
FIX API session
Needs a session agreement with the broker, often a private connection, its rules of engagement and conformance testing. Trouble usually sits in sequence numbers after a restart, end-of-day session resets and resends that must not become duplicate orders. The scope covers the sequence store, resend rules and test evidence for the broker. Fincode has no production FIX project to cite.
Local gateway or vendor library
Needs a logged-in application on a server you run. Trouble usually sits in scheduled restarts, expired logins, two-factor prompts and pacing limits that drop the connection. The scope covers a restart plan and a person on your side who logs in when the broker requires it.
Terminal plugin or vendor bridge
Some platforms are reached only through a plugin inside a desktop terminal or a third party's bridge. That needs the terminal running, the vendor's license and one more company in your order path. Trouble usually sits in silent plugin failures and version updates. The scope says who answers for each part, and we do not recommend a product.
What the test report covers
Which cases apply depends on the broker and the instruments. They are simulated on purpose, on the broker's paper or test environment where it offers one.
A timeout after sending an order
The order may or may not exist, and some broker APIs do not deduplicate a retried order, so a blind retry can create a second one. The software marks it unknown, asks about the client order ID and acts only on the answer.
A rejected order
A reject is a normal result. Each documented reason maps to a behavior in a written table, and anything not in the table stops that action and alerts a person.
A sequence gap after a restart
On a FIX session, messages were missed while the connection was down. The session asks for a resend, and resent messages carry a possible-duplicate flag, so none of them becomes a new order.
A cancel that crosses a fill
The order fills in part while the cancel is on its way, and the broker refuses the cancel or cancels only the rest. Execution reports are the record, so the position counts what actually filled, whatever the cancel returned.
A trade placed outside the software
You or a colleague trade from the broker's screen. Reconciliation labels it as external and reports it. It does not try to correct it.
A corporate action overnight
A position changes with no fill behind it. New orders on that instrument stop until the difference is explained.
A contract expires
The software refuses to send orders to an expired contract. Roll dates are stored as data, and your written rules decide what happens next.
A market that is closed or halted
The order is held or canceled as your rules say, and the event is logged. It is never dropped silently.
Delayed prices arrive as if live
The software checks the data's delay or entitlement where the API exposes it, and does not treat delayed data as live.
A login expires
New orders stop and a person is alerted. After the login, open orders and positions are reconciled before anything new is sent.
Paper trading APIs can use delayed data and simplified fills. Passing there shows the logic, not how live orders will fill. Tests show how the software behaves, not future results, and trades can lose money.
What a reject map looks like
The behavior in the right column is agreed with you, line by line. It is the difference between a stopped bot and one that keeps retrying a bad order.
| Broker response | Meaning | What the software does |
|---|---|---|
| [insufficient buying power] | The order exceeds available funds | No retry. Stop new orders on this account and alert [person] |
| [invalid price or tick] | The price is not valid for this instrument today | No retry. Refresh reference data, log and alert |
| [market closed] | The session is closed | [hold or cancel, as your written rule says], and log |
| [duplicate client order ID] | The broker already has this ID | No new order. Ask for the status of that ID |
| [pacing or rate limit] | Too many requests | Wait as the broker documents. No extra connection to get around it |
| Anything not listed here | Unknown | Stop that action, log the full message and alert [person] |
What you receive
- A written route decision: which interface, and why
- An adapter that is the only part of the software talking to the broker, so changing broker means rewriting that layer
- Unique client order IDs, and an order state machine driven by the broker's reports
- A reject map: each documented reason and what the software does
- Reconciliation of open orders, fills and positions at start-up, after reconnects and at end of day
- An audit log of what was sent, by which part of the system, and what the broker answered
- A test report, plus evidence for any conformance tests your broker requires
- An operations guide and technical documentation: logins, session resets, holiday calendars
What Fincode does not do
- Recommend a broker or take referral fees
- Open accounts, or help with identity checks
- Collect or transmit orders for other people
- Strategies, signals, copy trading, account management or profit share
- Work around a broker's login, two-factor, pacing limits or country restrictions, or a prop firm's rules
- Withdrawals or cash transfers
What is checked first
Your country
For customers outside Türkiye, which brokers and products can be used depends on the law of your country and the broker's terms. For customers resident in Türkiye, receiving and transmitting orders in capital market instruments is an investment service under Article 37 of Capital Markets Law No. 6362, reserved for authorized investment firms by Article 39, and the Capital Markets Board's notice of 23 February 2023 (opens in a new tab) says residents may carry out leveraged transactions only through firms it has authorized. This is general information, not legal advice.
Your broker's terms
Whether your account type may use the API, whether access or data carries a fee, whether automated orders are allowed, whether a third party may write or run the software, and what the broker requires before go-live. If the terms say no, the work stops there.
The test route
Whether the broker offers a paper or test environment, and what it does not simulate. If there is none, we agree how read-only checks and small live orders, approved by you, take its place.
Instruments and order types
Whether your written rules need something the broker supports natively, or something the software would have to simulate. A stop kept on your server does not behave like one held by the broker.
Data rights
What your subscription allows software to do with prices. If your use needs a direct agreement with an exchange or vendor, you sign it. See Borsa Istanbul market data for one example.
Who holds the account and key
You do. Orders are sent by the software, on your own account, with your own API key, under the rules you defined, and by default the software runs on your own server or cloud account. Read and trade permissions only; we do not ask for withdrawal rights. See how API keys are handled.
When you do not need us
If your broker's own platform has what you need, such as bracket orders, trailing stops or its own automation tools, start there. If you run one account and can watch it, the broker's official SDK and a short script may be enough; try it on paper first. If you only need prices, a data API is simpler: see market data pipelines.
Custom work makes sense when several internal systems must share one order flow, when you need an audit trail and reconciliation, or when software has to run unattended within limits you set.
See how it could fit together
The broker order management integration is an example scenario, not a client project. It shows permissions, risk checks, a state machine and an audit trail in one design.
Questions about broker API integration
Which brokers do you integrate with?
We publish no list, and Fincode has no finished broker integration to show. Any broker that offers API access can be considered, if your country's law and the broker's terms allow it for your account. That is checked before we quote.
Is Fincode certified by a broker or for FIX?
No. Fincode claims no certification and no partnership with any broker. If your broker requires a conformance test, the evidence for it is part of the work, and passing applies to that session with that broker.
Should I use a FIX API or a REST API for trading?
Often the broker decides, by what it offers your account type. REST is easier to start with; FIX suits continuous, recoverable order flow and takes more onboarding. Our guide compares them.
Can you connect a stock, options, futures or forex trading API?
Where your broker's API offers them and your country allows them. Leveraged products are restricted in many places, so that question comes first.
Do you build on a trading API in Python?
It is a common choice, but the language follows the broker's official library and your own systems. The scope document states which one and why.
Can it connect TradingView alerts to my broker?
Not under this service. TradingView's Terms of Use (opens in a new tab), read on 5 November 2026, license alerts and webhooks for display use and prohibit using them for automated trading, including through third-party products or services. Read those terms and take legal advice. Software built from your written rules can work from your broker's own data instead.
Can the software trade for my clients?
No. We decline projects that run on other people's accounts, copy trades or sell signals.
Does paper trading prove the integration works?
It shows the logic under simulated fills. The live start therefore comes after your approval and runs with small limits. Passing a paper test says nothing about future results, and trades can lose money.
Do you need my broker login?
No. Work starts in the broker's test environment where one exists. On the live account you create the key or log in yourself, and credentials stay on your server. Do not send passwords or keys in your brief.
How is the price set?
You get a written proposal with work items, dates and cost before work starts. Fees depend on scope and effort, not on trading volume or results.
Read before you scope an integration
Have a broker account and a clear need?
Tell us your country, your broker, what the software should do and your timeline. Do not include passwords or API keys. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services. Trades can lose money.