Trades API
How trade payloads should flow into Quantarya and how the lifecycle evolves after the first signal.
Endpoint
Quantarya currently exposes one main trade ingestion endpoint: POST /strategies/{strategy_id}/trades.
Authenticate with either a Quantarya API key or a valid user JWT in the Authorization header.
At minimum, send symbol and side. Entry, stop loss, take profit, timeframe, source, external reference, and structured metadata are strongly recommended.
Example request
curl -X POST "https://api.quantarya.io//strategies/STRATEGY_ID/trades" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d "{
\"symbol\": \"EURUSD\",
\"side\": \"BUY\",
\"entry\": 1.0825,
\"stop_loss\": 1.0785,
\"take_profit\": 1.0905,
\"timeframe\": \"4h\",
\"source\": \"tradingview\",
\"external_reference\": \"tv-eurusd-001\",
\"signal_time\": \"2026-05-21T12:00:00Z\"
}"Sending new trades
Trades can be sent programmatically into a strategy using the Quantarya API.
Typical payloads include symbol, side, entry, stop loss, take profit, signal time, timeframe, and optional metadata.
The cleaner the payload context is, the easier later review and automation become.
Updating the trade lifecycle
Opening a trade is only the start of the lifecycle.
As the position evolves, trades can later be updated or closed with more context, status changes, and closing values.
This is what makes Quantarya useful as a journal rather than just a signal inbox.
Integration guidance
A practical flow is: your external signal source chooses the strategy, authenticates with an API key, and posts the trade payload into Quantarya.
Keep routing logic outside of the UI and treat Quantarya as the destination and review surface.
When in doubt, start with minimal fields and grow the payload once the base flow is stable.