Algo Desk API

Last updated July 6, 2026

One key for market data, news, and order placement — nothing outside the platform. All capital on DogBone Capital is simulated; this reference documents the same engine and the same risk checks that back the trading UI, not a separate or lighter-touch system.

Getting a key

The Algo Desk is gated behind an 8-question unlock test (API safety, rate limits, order idempotency, and the risk of unsupervised automated loops), or a direct grant from an administrator. Create and manage keys from Settings — Algo Desk once unlocked.

Authentication

Send the key as a bearer token on every request:

curl https://your-deployment.example/api/market-data/quote?symbol=AAPL \
  -H "Authorization: Bearer dbpat_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Each key carries explicit scopes. A request missing a required scope is rejected with 403, not silently downgraded. Order placement additionally requires the ALGO_API entitlement on the account — a valid, correctly-scoped key is not enough on its own.

  • data:read — quotes and historical bars
  • news:read — news feed and alt-data reads (metered against your monthly alt-data budget)
  • orders:write — submit and cancel orders
  • journal:write — create journal entries

trading:write is accepted everywhere orders:write is — an older capability scope kept for backward compatibility. Mint new keys with orders:write; existing keys scoped to trading:write do not need to be reissued.

Quote

curl "https://your-deployment.example/api/market-data/quote?symbol=AAPL" \
  -H "Authorization: Bearer $DBC_API_KEY"
import requests

r = requests.get(
    "https://your-deployment.example/api/market-data/quote",
    params={"symbol": "AAPL"},
    headers={"Authorization": f"Bearer {DBC_API_KEY}"},
)
r.raise_for_status()
quote = r.json()

Historical bars

curl "https://your-deployment.example/api/market-data/bars?symbol=AAPL&timeframe=1Day&limit=100" \
  -H "Authorization: Bearer $DBC_API_KEY"

News feed

curl "https://your-deployment.example/api/news/feed?portfolioOnly=false&limit=25" \
  -H "Authorization: Bearer $DBC_API_KEY"

Each read against this endpoint counts against your account’s monthly alt-data budget. Once the budget is reached the endpoint returns 429 with code: "ALT_DATA_BUDGET_EXCEEDED" until the next period.

Submit an order

Include an Idempotency-Keyheader on every order submission. A retried request with the same key returns the original order’s result instead of placing a duplicate — this matters for any bot that retries on timeout.

curl -X POST "https://your-deployment.example/api/orders" \
  -H "Authorization: Bearer $DBC_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: strategy-1-2026-07-06T12:00:00Z" \
  -d '{
    "symbol": "AAPL",
    "side": "BUY",
    "type": "MARKET",
    "quantity": 10
  }'
import requests, uuid

resp = requests.post(
    "https://your-deployment.example/api/orders",
    headers={
        "Authorization": f"Bearer {DBC_API_KEY}",
        "Idempotency-Key": str(uuid.uuid4()),
    },
    json={"symbol": "AAPL", "side": "BUY", "type": "MARKET", "quantity": 10},
)
resp.raise_for_status()
order = resp.json()

Orders submitted through the API pass the same pre-trade risk and entitlement checks as an order placed from the trading terminal — position limits, drawdown state, and gates like SHORT_SELLING or MARGIN apply identically. The Algo Desk changes how an order arrives, not what is allowed to fill.

If a request omits Idempotency-Key entirely, a short (about 3 seconds) fallback dedupe window still applies: a second submit with the same symbol, side, quantity, and order type within that window returns 409 with code: "DUPLICATE_SUBMIT"and the original order’s id, instead of placing a second order. This is a best-effort backstop for a script that never adopted the header — it resets on deploy and is not a substitute for sending a real key. A strategy that retries on timeout should always send its ownIdempotency-Key.

Cancel an order

curl -X DELETE "https://your-deployment.example/api/orders/{orderId}" \
  -H "Authorization: Bearer $DBC_API_KEY"

Journal entry

curl -X POST "https://your-deployment.example/api/journal" \
  -H "Authorization: Bearer $DBC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"orderId": "ord_123", "thesis": "Entered on the earnings beat, sizing to 2% of book.", "tags": ["earnings"]}'

Rate limits

Each key has its own per-minute limit, set when the key is created and visible under Settings — Algo Desk. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. A request over the limit returns 429; back off until the reset time rather than retrying immediately.

Error codes

  • 401 — missing or invalid key
  • 403 — key is missing a required scope, or the account lacks ALGO_API / another required entitlement
  • 404 — resource not found or not owned by this account
  • 409— conflicting state (for example, a duplicate journal entry on an order, or a keyless duplicate submit within the fallback dedupe window — see "Submit an order" above)
  • 429 — rate limit or alt-data budget reached; retry after the window indicated in the response
  • 500 — unexpected server error; safe to retry with the same Idempotency-Key

REST API vs. MCP server

The endpoints above are the REST API — plain HTTP for a bot or script. The platform separately exposes an MCP server at /api/mcp for MCP clients (for example, an AI copilot). The two surfaces are independent: an MCP client and a REST bot should use separate keys so either can be revoked without affecting the other. See Settings — Algo Desk for both.