Algo Desk API

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.

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.

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()

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

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.

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.

An order may optionally carry a strategyVersionHash (REST) or strategy_version_hash (Alpaca-compat) string — a caller-supplied identifier for the strategy/version that produced the order (for example a git SHA or a hash of the algo config). It is stored verbatim and never interpreted by the platform; this is a seed for future provenance reporting, not a full audit trail today.

An order placed through this API runs through the exact same submission path as an order placed from the trading terminal — the same pre-trade risk engine, inside the same transaction, checking the same position limits, drawdown state, and entitlement gates. The channel an order arrives through (browser, this API, or MCP) changes provenance labeling only; it never changes what is allowed to fill. A risk check that rejects a UI order rejects the identical bot order the same way, with the same error code.

A key may optionally be scoped to one of your own competition books at creation time (bookScope, the book’s fund id). A scoped key can submit orders only against that book’s fund-order endpoint — every personal-book order (/api/orders, /api/v2/orders) and every other fund is refused with 403 and code: "API_TOKEN_BOOK_SCOPE". An unscoped key (the default) is unaffected and behaves exactly as documented above.

Pause a key from Settings — Algo Desk to immediately block new order submissions without losing the key’s history or identity — reads, past orders, and the key’s own listing all keep working. A paused key returns 403 with code: "API_TOKEN_PAUSED"on every order-submission endpoint until resumed. This is distinct from revoking a key, which is permanent — a revoked key cannot be resumed, only replaced. An admin can also pause or resume a key on a member’s behalf.

Every order records which channel it arrived through — the browser, this REST API (api_token), the MCP server (mcp), or an internal platform process (system) — independent of any scope or entitlement it also carries. This is provenance only; it does not change what an order is allowed to do.

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

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"]}'

Each key has its own per-minute limit, set when the key is created and visible under Settings — Algo Desk. It applies identically on every order-submission endpoint the key can reach — personal orders, the Alpaca-compat path, and a fund book’s discretionary order endpoint. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset where available. A request over the limit returns 429; back off until the reset time rather than retrying immediately.

• 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)
• 403 (paused/scoped) — code: "API_TOKEN_PAUSED" (resume the key) or code: "API_TOKEN_BOOK_SCOPE" (this key is bound to a different book)
• 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

The Data page’s Connect tab walks through this in three steps and includes a live OAuth connect button; the config below is Read-only access (no unlock test) for each client, with a placeholder in place of a real token.

{
  "mcpServers": {
    "dogbone-capital": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://dogbonecap.com/api/mcp"
      ]
    }
  }
}

claude mcp add --transport http dogbone-capital https://dogbonecap.com/api/mcp

{
  "mcpServers": {
    "dogbone-capital": {
      "url": "https://dogbonecap.com/api/mcp"
    }
  }
}

1. In ChatGPT, open Settings -> Connectors -> Create.
2. Server URL: https://dogbonecap.com/api/mcp
3. Authentication: OAuth. Click Connect and approve the DogBone Capital consent screen.
4. Save, then enable the connector in a chat to use its tools.

Endpoint: https://dogbonecap.com/api/mcp
Auth: OAuth 2.1 + PKCE. Point the client at the endpoint above; it discovers the authorization server from /.well-known/oauth-protected-resource.

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.