Vanta
Open Vanta
About

Versioning & changelog

This documentation describes v1.2.0 of the API contract. The version lives in the URL, where every endpoint sits under /api/v1/, so a future incompatible revision arrives as a new prefix rather than as a change under your feet.

What can change without notice

Write your client so these are non-events.

  • New fields in a response object. Ignore what you do not recognise; never assert on an exact key set.
  • New endpoints, and new optional request fields on existing ones.
  • New values in a field that behaves like an enum, such as a new execution type or a new account status. Handle the default case rather than crashing.
  • Wording of error messages. Match on HTTP status; treat the string as diagnostic text for a human.
  • Rate limits. Read the headers on a 429 rather than hard-coding the ceiling.

What counts as breaking

These would arrive under a new version prefix.

  • Removing or renaming a response field, endpoint or request field.
  • Changing the type or meaning of an existing field.
  • Changing the signing scheme. The canonical string is versioned by its own v1 prefix and the signature header carries v1=, so a new scheme can run alongside the old one.
  • Changing an HTTP status for an existing failure.
Response shapes are documented by example rather than by a strict schema, and the OpenAPI document is generated from those examples. It is accurate about structure and good for client generation. Treat it as a description, not a validation contract.

Changelog

Most recent first.

  1. v1.2.0

    Network-side account state and payouts.

    • GET /api/v1/trading/account: new fields drawdownRules (both loss limits, by rule), elimination (reason, time, drawdown percent), proTrack (pro promotion objectives), isPro and tradingDays. Existing fields are unchanged.
    • GET /api/v1/trading/payouts: new endpoint returning payout history (paginated with limit and cursor) and the live estimate for the cycle in progress.
    • Errors: a 400 for an invalid limit or cursor query parameter on GET /api/v1/trading/payouts.

  2. v1.1.0

    Fill sizes as numbers, for clients that need to confirm what executed.

    • GET /api/v1/trading/positions: new netQuantity field, the position size in the pair's lot unit, signed like netLeverage.
    • GET /api/v1/trading/trades: new quantity field, the total size opened over the life of the trade, in the same unit.
    • POST /api/v1/trading/orders: new data.order object, the validator's order record parsed into typed fields (quantity, value, price, bindingCap and more). data.order_json is unchanged.
    • GET /api/v1/trading/positions: unrealizedPnl now carries the validator's live figure. It previously read 0 for every position.
    • Documentation: the POST /api/v1/trading/orders response example now shows the real envelope.

  3. v1.0.0

    Public documentation for the v1 trading API.

    • Published this documentation portal covering authentication, endpoints, order payloads and errors.
    • Published a generated OpenAPI 3.1 document at /docs/openapi.json.
    • No change to the API itself. The endpoints described here have been available to key holders from within Settings → Key Management.

Questions

If something here is wrong or missing.

Report documentation problems and API questions through the support channel in your dashboard. Include the endpoint, the HTTP status and your key id, and never your secret. If you suspect a secret has leaked, revoke the key first; see Authentication.