Developers

REST API

Drive TradeLayer from your own systems. Create a scoped API key in the app and use it to read your account, positions, trades and strategies — and, with the trade scope, submit signals. A submitted signal runs through the exact same pipeline and safety gate as a TradingView webhook.

The key never decides execution. A signal only says what the setup is. Whether an order actually goes out stays with the app — your auto-execute switch and kill switch. A read-only key can never place anything at all.

1 · Get a key 2 · Authenticate 3 · Scopes Endpoints Submit a signal

1Get an API key

Open the app, swipe in the side menu, and under trade settings → API-toegang create a key. Give it a name, and turn on trade if it should be allowed to submit signals (leave it off for read-only). The full key is shown once — copy it straight away. The server only ever stores a hash, so a lost key can't be recovered, only revoked.

Base URL. Every endpoint below lives under /api/v1/public on your server, e.g. https://mytradelayer.com/api/v1/public. Self-hosting on your own domain? Swap the host; the path stays the same.

2Authenticate

Send your key with every request, either as a bearer token (preferred) or in the X-API-Key header — whichever your tool makes easier:

# Preferred
Authorization: Bearer tlk_your_key_here

# Or, for no-code tools that only set custom headers
X-API-Key: tlk_your_key_here

A quick check that your key works — returns its name and scopes:

curl -s https://mytradelayer.com/api/v1/public/ping \
  -H "Authorization: Bearer tlk_your_key_here"

Keep keys secret and use HTTPS. A key is a password to your server. Rotate it (revoke + create a new one) if it ever leaks, and give each integration its own key so you can revoke just that one.

3Scopes

Each key carries a set of scopes. A request without the right scope is rejected with 403.

read	Read your account, positions, trades and strategies. Always present on every key.
trade	Submit signals through `POST /signals`. Only present if you turned trade on when creating the key.

Reference

Endpoints

GET/public/pingread	Sanity check — returns the key's name and scopes.
GET/public/accountread	Active mode (demo/live), plan, and whether auto-execute is on — so a client knows if a submitted signal will be placed or just held as pending.
GET/public/positionsread	Your open positions (OPEN trades) in the active mode. Optional `?mode=demo\|live`.
GET/public/tradesread	Recent trades. Filters: `?status=PENDING\|OPEN\|CLOSED\|INVALIDATED`, `?mode=`, `?limit=` (1–500), `?offset=`.
GET/public/strategiesread	Your strategies: id, name, type, status and fixed broker.
POST/public/signalstrade	Submit a signal. Same body as a TradingView alert; same dedup, gates, whitelist and execution gate.

4Submit a signal

POST the same JSON a TradingView alert would send — minus the webhook secret (your API key authenticates instead). The strategy must already exist in the app.

curl -s -X POST https://mytradelayer.com/api/v1/public/signals \
  -H "Authorization: Bearer tlk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "event": "ALERT",
    "strategy": "My Strategy",
    "market": "CRYPTO",
    "asset": "BTCUSDT",
    "direction": "LONG",
    "order_type": "MARKET",
    "price": 64000,
    "sl": 63000,
    "tp": 66000
  }'

The response tells you how the signal was handled:

{
  "ok": true,
  "status": "PROCESSED",   // or DUPLICATE / FAILED
  "trade_id": "…",
  "trade_ids": ["…"],       // one per linked broker
  "detail": null
}

Pending vs placed. A PROCESSED signal is accepted and stored. It's only sent to your broker when auto-execute is on and the kill switch is off — otherwise it waits as a pending trade you can place from the app. Check GET /public/account to see the current state.

eventreq	`ALERT` (new setup), `CLOSE` or `INVALIDATE` (follow-ups on the same `trade_ref`).
strategyreq	Strategy name — must already exist in the app. Routes the trade and applies its config.
marketreq	`CRYPTO`, `FOREX`, `INDICES` or `COMMODITIES`.
assetreq	The instrument, e.g. `BTCUSDT`, `EURUSD`. Resolved tolerantly.
directionreq	`LONG`/`SHORT` — also accepts `buy`/`sell`.
order_type	`MARKET`, `LIMIT` or `STOP`. Defaults to `LIMIT`.
price	Entry/reference price.
sl / tp	Stop-loss / take-profit. Needed for risk-based sizing; a strategy may require both.
quantity_type / quantity	Sizing mode (e.g. `risk_percent`, `fixed_quantity`, `percent_of_equity`) and its value. Optional — falls back to your default risk.
trade_ref	Your own id shared by all events of one trade (so a CLOSE finds the right ENTRY).
signal_id	Optional unique id for deduplication — a re-sent signal with the same id is ignored.

Control fields are ignored. Anything that tries to force execution (auto_execute, kill_switch, override, …) is stripped from an incoming signal — exactly as with the webhook. The app stays in control of placing.