The engine, from your own stack.

Four calls, end to end

Every example below is a real route on the live API. The full reference — request and response schemas for all 155 customer endpoints — is generated from the server itself at the interactive reference, so it cannot drift from what the API actually accepts.

curl https://api.quantparadox.com/v1/me \
  -H "Authorization: Bearer qp_live_..."

curl -X POST https://api.quantparadox.com/v1/wizard/author \
  -H "Authorization: Bearer qp_live_..." \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"source": "buy the second touch of a fresh support level", "kind": "english"}'

curl -X POST https://api.quantparadox.com/v1/wizard/backtest \
  -H "Authorization: Bearer qp_live_..." \
  -d '{"spec": {...}, "market": "EUR/USD", "tf": "H1"}'

curl -X POST https://api.quantparadox.com/v1/institutional/validate \
  -H "Authorization: Bearer qp_live_..." \
  -d '{"strategy_id": "..."}'

What it costs, and what a retry costs

The endpoint most APIs don't have

Running a backtest is the easy half, and every platform in this category will run one for you. The question that decides whether you should trade the thing is whether the result survives the number of variants you tried to get it — and that is the call we expose.

/v1/institutional/validate can return a refusal. A strategy with a flattering equity curve and 200 attempts behind it comes back as not distinguishable from luck, with the correction shown. An API that only ever agrees with you is not a research tool.

Running a strategy forward

A deployment is a strategy running from a moment you choose. In paper we simulate it on our archive and the record counts only trades taken since you started. In live your executor polls for the decision at each closed bar and reports back what it filled.

We do not hold broker credentials and we do not place orders. The executor is yours — we ship a readable reference one at /v1/deployments/{id}/client, and it contains no strategy logic and no credentials of any kind.

# start it
curl -X POST https://api.quantparadox.com/v1/deployments \
  -H "Authorization: Bearer qp_live_..." \
  -d '{"strategy_id": "...", "mode": "live", "risk_pct": 1}'

# your executor, once per closed bar
curl https://api.quantparadox.com/v1/deployments/$ID/poll \
  -H "Authorization: Bearer qp_live_..."
# -> {"halted": false, "signal": {"side":"long","sl":...,"tp":...}, "manage": {...}}

# tell us what you filled (idempotent per bar+kind+side, so retries are safe)
curl -X POST https://api.quantparadox.com/v1/deployments/$ID/fill \
  -H "Authorization: Bearer qp_live_..." \
  -d '{"t": 1785999600, "side": "long", "price": 1.0812, "kind": "entry"}'

Practical notes

• Auth. Authorization: Bearer qp_... on every request. Keys are stored hashed and compared in constant time; a revoked key stops working immediately.
• Versioning. Everything lives under /v1. Additive changes — new fields, new routes — ship without notice; anything that could break a caller gets a new version.
• Errors. Non-2xx responses carry a detail explaining what to change. A 402 means the workspace is out of credits, not that the request was wrong.
• Rate limits. Compute-heavy routes are throttled per workspace. The exact ceiling is published in the response headers rather than here, because a number on a marketing page is the one that goes stale.
• No SDK yet. There is no pip install — the REST API is the API. If you want a client in your language, the schema at /openapi.json generates one.

Already have a key? Manage keys · Full API reference