RTX5API and SDK Documentation
Preview the proposed RTX5 REST, WebSocket and FIX contracts. Endpoint versions, schemas, supported authentication and runnable sandbox examples are not yet published.
API examples will only be published after passing sandbox testing.
Planned API Scope
Authentication
Confirm the supported credential/authentication method, tenant/account scopes, rotation and revocation in the versioned contract. API keys or OAuth support are not assumed.
REST API
HTTPS endpoints for account management, order placement, position queries and administrative operations.
WebSocket API
Real-time market data streaming, order updates and account notifications over persistent connections.
FIX Protocol
FIX 4.4 and 5.0 session management for institutional connectivity. See FIX documentation for session scope.
Idempotency & Retries
Publish the operation identity, duplicate handling, retry windows and reconciliation endpoints before offering runnable request examples.
Rate Limits & Versioning
Per-endpoint rate limits, API versioning strategy and deprecation policy.
Choose a Version and Permission Scope
Agree the protocol, environment and permitted actions before integrating. The scope below is a documentation proposal, not a published endpoint contract.
Swipe horizontally to view all columns.
| Interface | Intended scope | Contract and access status |
|---|---|---|
| REST | Account queries, order commands and separately authorized administrative actions. | Base URL, API version, OpenAPI schema and endpoint scopes: not yet published. |
| WebSocket | Eligible market-data subscriptions, order events and account notifications. | Connection URL, message schema, sequencing and resubscription rules: not yet published. |
| FIX | Adapter-specific institutional sessions, quotes, orders and execution reports. | Use the FIX documentation for the protocol scope; counterparty certification must be agreed separately. |
| SDK | Versioned client bindings for a published API contract. | Available languages, package identifiers and tested SDK releases: to be confirmed. |
Swipe horizontally to view all columns.
| Boundary | Integration must establish |
|---|---|
| Identity | Which application or operator holds the credential; supported authentication method, credential issue/rotation and revocation procedure. |
| Tenant and account | Which broker tenant and accounts the credential can access. Access to another tenant must not follow from knowing an account ID. |
| Action | Separate read access, order submission and administrative privileges. Confirm who may grant or revoke each permission. |
| Environment | Sandbox and production access, endpoints and credentials must be identifiable separately. Production access requires its own approval. |
Submit a Command and Reconcile Its Outcome
A request timeout does not establish whether the server accepted an order. This illustrative lifecycle explains the questions an integration must resolve before retrying.
- 01
Create a client operation reference
Retain the intended account, instrument, action and request payload. Use the server's documented idempotency mechanism when a tested contract is available.
- 02
Submit and retain the acknowledgment
Record the request reference, response and any server command or order identifier. An acknowledgment must be distinguished from execution or final settlement.
- 03
Reconcile an uncertain response
If the connection fails, look up the recorded operation or order and consume relevant events before deciding to submit again. The actual lookup endpoint is not yet published.
- 04
Track the final state
Match fills, cancellations and rejections to the originating operation. Compare streamed updates with an authoritative account/order snapshot after reconnecting.
Swipe horizontally to view all columns.
| Event | Client record | Decision |
|---|---|---|
| An order request is sent | Operation reference example-001; response not received. | Outcome unknown; do not infer rejection from a timeout. |
| The connection recovers | Query/event reconciliation identifies the original accepted order. | Continue monitoring that order rather than creating a second trading intent. |
| No outcome can be established | Retain the original request and reconciliation attempts. | Apply the documented retry contract or escalate; the accepted retry window must be confirmed. |
Retries, Limits and Sandbox Validation
These behaviors need a versioned contract so an integration can handle failure predictably.
Swipe horizontally to view all columns.
| Topic | Required detail | Current status |
|---|---|---|
| Idempotency | Key scope, retention window, concurrent-request behavior and response to the same key with a changed payload. | Not yet published. |
| Retry and errors | Retryable errors, timeout semantics, backoff guidance, error identifiers and escalation path. | Not yet published. |
| Rate and subscription limits | Per-account/application quotas, burst windows, limit responses and recovery instructions. | Not yet published; no numeric rate allowance is promised here. |
| Stream recovery | Event ordering, duplicate handling, replay availability and snapshot reconciliation after a gap. | Not yet published. |
| Version changes | Contract version, compatibility policy, deprecation notice period and migration guidance. | Not yet published. |
Developer Access
Runnable contracts and sandbox access depend on an available tested build. Request the current scope and access requirements; submitting an enquiry does not create sandbox credentials.