Changelog¶
Every entry is keyed on the API version reported as info.version in the
reference. That number is the single source of truth, and the
SDK versions follow it.
Early access
Version 1.0.0 has not been released. This API is available to
design-partner firms only, and the surface is still being extended. Nothing
here is a commitment to a date.
Versioning promise¶
- The major is in the URL. Everything lives under
/api/v1/. A change that would break a working integration mints/api/v2/— it never lands insidev1. - Minor — additive and safe: a new endpoint, a new optional request field, a new field on a response, a new error code, a new frame type on the socket. Your integration keeps working.
- Patch — a fix with no change to the wire.
What "additive" means for your code: tolerate what you do not recognize. A response gaining a field is a minor release, and a client that rejects unknown keys will break on one. The same goes for error codes and WebSocket frame types — match on what you know, and have a sane default for the rest.
Removing a path, removing a response field, or changing what an existing field means all require a new major.
Two vocabularies are frozen inside v1 and will not change meaning:
- the fourteen scope strings, and
- the error codes.
One consequence of "tolerate what you do not recognize" is worth spelling out
for writes: the order rejection vocabulary can gain values in a minor release,
so treat a rejection_reason you do not know as a plain rejection rather than
failing on it.
What is in early access today¶
| Area | Status |
|---|---|
OAuth2 client_credentials server tokens |
Available |
| Token exchange for delegated trader tokens | Available; the subject-type URN is not final |
| Bulk reads over accounts, trading accounts, positions and transactions | Available; account fields follow your firm's offering |
| Live account status | Available |
| Account writes — create, update, bulk create | Available |
| Trading — open and close a position | Available |
| Transactions — create, approve, reject, cancel | Available, with one exception below |
| Approving a withdrawal that pays out through a payment provider | Refused with 501. Approve it in the Backoffice; do not retry |
| WebSocket streaming — prices, account figures, durable events | Available |
| Webhook subscriptions and signed delivery | Available; the two delivery header names are not final |
| Browser-direct REST calls with a delegated token | Not available. Allowed origins is inert |
Reading an order back after a 202 |
Not available. Use the order events instead |
| Amending a live order, or placing a pending order | Not available |
| Opening a trading account | Not available |
| SDKs on npm and PyPI | Not published |
Anything marked "not final" is deliberately not printed in these pages so that nobody writes an integration against a value that changes before launch. Your integration pack carries the current values, and each one becomes a changelog entry the day it is frozen.
Release history¶
| Version | Date | Change |
|---|---|---|
| 1.0.0 | — | Not yet released. |
Deprecation policy¶
When a new major ships:
- The previous major keeps working for a support window agreed with you, and the window starts from the new major's release.
- Anything scheduled for removal is announced first and served with
DeprecationandSunsetresponse headers giving the date, well before it stops working. - Log those two headers and alert on their first appearance. They are the earliest and most reliable signal that something you depend on is going away — earlier than any email.
Staying current¶
- Regenerate your SDK types after any version bump. The generated types come from the same definition the reference is built from.
- Both SDKs assert at build time that their major matches the API's.
- Watch this page and the error catalog; both are generated, so neither can quietly drift from what the API actually does.