Direct Answer
The Trading API Playground is a synthetic sandbox for practicing order payload validation, fault injection, retry safety, and reconciliation logic against a simulated trading API. No real credentials, API keys, or brokerage connections are accepted, every request and response is fabricated for practice. It's a safe place to harden bot logic before pointing it at a real broker's API.
API Playground
Please fix the following before running:
Synthetic Response
Order State Transition
State transition table (accessible text equivalent)
| Step | State | Description |
|---|
Educational tool, for hypothetical scenarios only. Not personalized advice. No real orders are placed and no real credentials are accepted or stored.
Methodology
The playground runs entirely against local in-browser fixtures, no network request leaves your browser, and no route exists to real broker or exchange infrastructure. Every response is generated deterministically from the endpoint you selected combined with the fault scenario you injected.
How synthetic responses are generated
Each endpoint maps to a fixture template. The fault injection layer wraps that template with the selected failure mode: a timeout withholds the response for a simulated delay; a 429 returns a rate-limit body with a Retry-After header; a 5xx returns a server-error body; a partial fill modifies the fill quantity and order state; a duplicate event replays the same event envelope with a new delivery timestamp; a delayed acknowledgement returns an intermediate pending_ack state before resolving; and a disconnect simulates a mid-stream WebSocket close frame.
Idempotency and client order IDs
The playground demonstrates idempotency by mapping one logical command to a stable client order ID. Submitting the same client ID twice returns the same synthetic result as the first submission rather than creating a new order record. This mirrors how real brokers use client IDs to prevent duplicate orders on network retries, a critical property for any automated system that must recover from uncertain delivery.
Validation rules
- Authorization headers and common secret patterns (Bearer tokens,
sk-prefixes, PEM headers) are rejected before processing. - Payload symbols must start with
FAKE_to prevent accidental use of real tickers as a signal that orders are live. - Non-fake destination URLs are blocked, the playground has no external route.
- Payload size is limited to 4 KB.
- Every request is schema-validated against the documented fake schema before a response is generated.
Assumptions and limitations
- No real credentials are accepted or stored at any point.
- No real market data is used, all prices are illustrative fixtures.
- Synthetic fills are educational and make no claims about live execution quality, queue priority, or venue microstructure.
- The fake API intentionally exposes failure cases that real APIs may handle differently depending on broker, venue, and session state.
- A synthetic playground teaches API semantics and failure-handling patterns; it cannot reproduce broker risk rules, real queue position, or latency characteristics of production systems.
Frequently Asked Questions
Does this tool connect to any real brokerage or exchange?
No. The playground runs entirely in your browser against local fixtures. No request leaves your browser, no credentials are transmitted, and no route to any real brokerage, exchange, or market-data vendor exists. All responses are deterministic synthetic outputs generated from your selected scenario.
Why does the tool reject my API key if I paste it in?
The playground actively rejects payloads and header values that match common secret patterns, Bearer tokens, sk- prefixes, PEM certificate headers, and similar formats. This is an intentional safety control: real credentials should never enter a public educational tool, and the rejection helps you recognize the pattern before working with a production system. If you see a rejection, verify that your payload only uses the documented fake schema and does not contain any real account identifiers.
What is a client order ID and why does it matter?
A client order ID (sometimes called a client ID or idempotency key) is a stable identifier you assign to each logical order before submitting it. If a network failure makes you uncertain whether the first request was received, you can safely retry with the same client ID, the broker's system recognizes it and returns the original result rather than creating a second order. Without client IDs, a network retry can create duplicate orders with real financial consequences. The playground demonstrates this by returning the same synthetic result when you submit the same client ID twice.
What should I do when I see a 429 rate-limit response in the real world?
A 429 response means you have exceeded the broker or venue's request rate limit for your account or IP. The correct response is to stop sending new requests, check the Retry-After header value (if provided) to determine how long to wait, and implement exponential backoff with jitter rather than retrying immediately. Immediate retries after a 429 typically trigger additional rate limits. The playground's 429 fault scenario shows the response format and retry-safe guidance so you can verify your retry logic before connecting to a live system.
How does a partial fill affect order state and reconciliation?
A partial fill means your order was accepted but only some of the requested quantity was executed. The order transitions to a partially_filled state and typically remains active for the unfilled remainder, depending on the time-in-force setting. For reconciliation, you must track both the filled quantity and the remaining open quantity separately, a common source of bugs is treating a partial fill as either a complete fill or a rejection. The playground's partial-fill scenario shows the state transition and event log entry so you can see what your reconciliation logic needs to handle.
What is the difference between a paper trading API and this playground?
A paper trading API is typically a simulated environment provided by a real broker that connects to real (or delayed) market data and mirrors the broker's actual order routing and matching logic, but executes against a simulated account balance rather than real funds. This playground is simpler and entirely educational: it has no connection to any broker system, uses only fake price fixtures, and focuses on teaching request structure, error handling, and state machine patterns rather than simulating execution quality or market behavior. Use this playground to learn API mechanics before setting up a paper trading environment with a real broker.
Can this playground be pointed at my own client code?
No. It runs entirely inside the page and exposes no network endpoint for an external client to call, so there is nothing for a bot to connect to. Its purpose is reasoning about request shapes, error semantics, and recovery logic interactively rather than serving as a test server. Once the semantics are understood, exercising real client code belongs in a broker sandbox environment that speaks the actual protocol.
Why does the playground surface failures a real broker might handle differently?
The failure cases are injected deliberately, because the point is practicing the handling path rather than reproducing a specific vendor. Real brokers differ substantially in which conditions they reject, which they accept and correct silently, and which they report asynchronously. A tool that mirrored one broker exactly would teach that broker rather than the failure category. Treating the injected errors as a catalogue of what can go wrong, not as a prediction of what a particular venue will return, is the intended use.
What still needs verifying in a broker sandbox that this cannot cover?
Authentication and signing against real credentials, the broker specific field names and enumerations, its actual rate limit accounting, how it reports asynchronous state changes, its risk rules and margin calculations, and the timing characteristics of its endpoints. Session and calendar behavior also has to be checked against the real venue. The playground covers protocol reasoning and failure handling; everything that depends on a specific counterparty implementation remains a sandbox exercise.