What we're building
A trading API is the one integration where getting the details wrong is expensive for everyone. An ambiguous error code, an idempotency gap on order submission or an under-specified rate limit does not just annoy developers. It costs money on live positions. So we are publishing the intended shape of the interface before it exists, taking feedback from the people who would build against it, and shipping only once the contract is one we are prepared to keep stable. Nothing on this page is callable today: there are no endpoints, no sandbox and no keys.
- REST endpoints for account state, instruments, positions, order placement, modification and closure
- A WebSocket feed for streaming quotes and order or position events, mirroring what the web terminal consumes
- API-key authentication with scoped keys, read-only keys separate from trading keys
- Published, predictable rate limits per key, with headers telling you where you stand
- Idempotency keys on order submission so a retried request cannot open a second position
- Versioned endpoints and a documented deprecation policy, so an integration does not break without warning
What you can use today
The NOVEDOX web terminal already covers the full trading workflow: live streaming prices, candlestick charts across five timeframes, market and pending orders, stop-loss and take-profit management, partial closes, and a complete position and history ledger. It runs on desktop, tablet and mobile browsers from the same account.
Planned design
How we intend the API to work
The split is conventional, because convention is a feature when someone is integrating at three in the morning: REST for state and actions, and WebSocket for anything that streams. You would fetch your account, list instruments and submit or amend orders over HTTPS, and subscribe to quotes and execution events over a persistent socket.
REST for accounts and orders
JSON over HTTPS, with the usual verbs meaning the usual things. Reading your balance, listing open positions and pulling trade history are GETs. Placing an order is a POST; amending a stop-loss or take-profit is a PATCH on the position; closing, fully or partially is an explicit action rather than something inferred. Errors would carry a stable machine-readable code alongside a human-readable message, so your handling does not depend on string matching.
WebSocket for streaming
One connection, subscribe by instrument. Quotes push as they update, and order and position events, fills, stop-loss triggers, take-profit hits, arrive on the same channel so your state stays consistent without polling. This is the same delivery model the web terminal already uses for its live prices.
Authentication with scoped keys
API keys, generated from your account, each with an explicit scope. A read-only key can pull prices and positions for a dashboard or a research notebook and is incapable of placing an order, which is exactly what you want on a machine you do not fully control. A trading key can act. Keys would be revocable individually, so rotating one does not disturb the rest.
Rate limits you can plan around
Limits per key, published rather than discovered by accident, with response headers reporting your remaining allowance and reset window. Streaming data belongs on the WebSocket precisely so nobody has to burn REST quota polling for prices.
Idempotency on anything that moves money
Order submission would accept a client-supplied idempotency key. Retry a request after a timeout and you get the original result back rather than a second position. The single most important safety property a trading API can offer.
Illustrative only
What the interface might look like
Read your account, planned REST
Authenticated with a scoped API key. Read-only keys can call this; they cannot place orders.
# ILLUSTRATIVE. This endpoint does not exist yet
GET /v1/account HTTP/1.1
Host: api.example-placeholder.novedox
Authorization: Bearer nvx_live_<your-api-key>
200 OK
{
"account_id": "NVX-100248",
"type": "demo",
"base_currency": "USD",
"balance": "10000.00",
"equity": "10142.35",
"margin_used": "412.90",
"free_margin": "9729.45",
"leverage": "200:1"
}Place an order, planned REST
A trading-scoped key, plus an idempotency key so a retry cannot open a second position.
# ILLUSTRATIVE. This endpoint does not exist yet
POST /v1/orders HTTP/1.1
Host: api.example-placeholder.novedox
Authorization: Bearer nvx_live_<your-api-key>
Idempotency-Key: 7c1f9a2e-4b30-11f0-9c2e
Content-Type: application/json
{
"instrument": "EUR/USD",
"side": "buy",
"type": "market",
"volume": "0.10",
"stop_loss": "1.07820",
"take_profit": "1.08640"
}
201 Created
{
"order_id": "ORD-8841207",
"status": "filled",
"fill_price": "1.08145",
"position_id": "POS-3310985"
}Stream quotes, planned WebSocket
One socket, subscribe per instrument. Quotes and execution events arrive on the same channel.
// ILLUSTRATIVE. This socket does not exist yet
const ws = new WebSocket(
"wss://stream.example-placeholder.novedox/v1"
);
ws.onopen = () => {
ws.send(JSON.stringify({
op: "auth",
key: "nvx_live_<your-api-key>"
}));
ws.send(JSON.stringify({
op: "subscribe",
channel: "quotes",
instruments: ["EUR/USD", "BTC/USD", "GBP/JPY"]
}));
};
ws.onmessage = (e) => {
const msg = JSON.parse(e.data);
// { "channel": "quotes", "instrument": "EUR/USD",
// "bid": "1.08142", "ask": "1.08145", "ts": 1767225600000 }
console.log(msg.instrument, msg.bid, msg.ask);
};Partial close, planned REST
Closing part of a position is an explicit action, mirroring the control in the web terminal.
# ILLUSTRATIVE. This endpoint does not exist yet
POST /v1/positions/POS-3310985/close HTTP/1.1
Host: api.example-placeholder.novedox
Authorization: Bearer nvx_live_<your-api-key>
Idempotency-Key: 91b4c07d-4b31-11f0-8ad1
Content-Type: application/json
{
"volume": "0.05"
}
200 OK
{
"position_id": "POS-3310985",
"closed_volume": "0.05",
"remaining_volume": "0.05",
"realised_pl": "18.40",
"close_price": "1.08513"
}
# Errors carry a stable code, not just a message:
# 429 { "code": "rate_limit_exceeded", "retry_after": 2 }
# 422 { "code": "insufficient_free_margin" }Planned surface
What the API is intended to cover
Every row below is a design intention, not a shipped capability. Status for all of it is “in development”.
| Area | Planned capability | Transport |
|---|---|---|
| Account | Balance, equity, margin used, free margin, leverage, base currency | REST |
| Instruments | The tradable catalogue 7 forex majors, 12 crosses, 4 exotics, 8 crypto pairs, with contract details | REST |
| Quotes | Continuous bid and ask updates per subscribed instrument | WebSocket |
| Candles | Historical candles on 1m, 5m, 15m, 1h and 1d, paged | REST |
| Orders | Place market and pending orders, amend, cancel | REST |
| Positions | List open positions, modify stop-loss and take-profit, close fully or partially | REST |
| Events | Fills, stop-loss and take-profit triggers, position updates | WebSocket |
| History | Closed trades with realised results | REST |
| Authentication | Scoped API keys, read-only and trading, individually revocable | Both |
| Safety | Idempotency keys on order submission, published per-key rate limits | Both |
Developer questions
Before you plan an integration
Can I get an API key today?
No. Key generation is part of the API work and does not exist in the product yet. There is no application form, no partner tier and no exception process. If you are offered a NOVEDOX API key by anyone, it is not genuine.
Is there a sandbox or test environment?
Not yet. When the API launches we intend the demo account to serve that purpose: the same endpoints, the same instruments and the same 200:1 default leverage, against a simulated $10,000 balance. Until then, the closest thing to a test environment is the web terminal on a demo account.
Will the examples on this page match the released API?
Treat them as sketches. They are here to show the intended shape and to invite criticism, and we fully expect field names, paths and error codes to change before anything ships. Building against them now would be building against something that does not exist.
Will there be official client libraries?
It is under consideration, but nothing is promised. The first commitment is a clear HTTP and WebSocket contract that anyone can implement in the language of their choice, a good raw interface matters more than a thin wrapper around a bad one.
Are MT5 or cTrader a faster route to automation?
Both are also in development, so neither is available sooner today. MetaTrader 5 would bring Expert Advisors in MQL5 and cTrader would bring cBots in C#. The platforms page tracks the status of all three in one place.
What can I do with NOVEDOX in the meantime?
Trade manually on the web terminal: 31 instruments, live streaming prices, five chart timeframes, market and pending orders, stop-loss and take-profit, partial closes and a full history ledger. Register and your demo account is funded automatically.
Trade manually today, automate later
The web terminal is live and needs no download. Register for a $10,000 demo account and leave your email above to hear when the Trading API ships.
Trading involves risk. 74.3% of retail accounts lose money.