An interface built for a person assumes a person is watching. It can return a partial result, or fail quietly, or rely on the user noticing that a number looks wrong. Software deciding on its own has none of that. The gap between an API that is pleasant to click through and one an agent can be trusted with comes down to about six things, and most venues get three of them right.
The capability list, in order of how much it hurts when missing
Ranked by the cost of working around the gap, not by how often the capability is advertised on a landing page.
| Capability | Typical availability | Cost of working around it |
|---|---|---|
| Idempotency keys on order placement | Roughly a third of retail venues | High: duplicate orders on retry |
| Streaming fills and position updates | Common, often as a paid tier | Medium: polling, 1 to 3s of blindness |
| Separate read and trade credentials | Uncommon | High: no safe way to run a dry run |
| Server-side bracket or OCO orders | Common on futures, rarer on spot | Medium: the agent must hold the stop itself |
| Deterministic error codes | Mixed, often prose messages | High: string matching on error text |
| Sandbox with real rejection behaviour | Rare | Medium: first live order is the first real test |
Why the sandbox is usually the weak link
Most sandboxes fill every order at the requested price. That is the one behaviour a live venue will not reproduce. An agent tested only against a permissive sandbox has never executed its rejection path, never handled a partial fill, and never seen a margin error. The first time it meets any of those, it meets them with real money.
A sandbox earns its place when it can be told to reject. If the venue offers no way to force a rejection, the next best thing is a local proxy that returns the venue's own error shapes on demand, which takes a day to write and removes an entire category of production surprise.
Rate limits are two budgets, not one
Market data and order placement are almost always metered separately, and the order budget is the tight one. A typical split looks like this.
- Market data, 20 to 60 requests per second, often with a websocket alternative that does not count against it.
- Account and positions, 5 to 20 requests per second, which is where naive polling loops die first.
- Order placement, 2 to 10 per second, sometimes with a daily cap that is not documented until you hit it.
An agent that treats these as one number will behave correctly in testing and then throttle itself at the worst possible moment, which is when the market is moving and it wants to place several orders at once.
What to check before writing any code
- Place an order, kill the connection before the response, then retry. Count the resulting positions.
- Ask for a position update while an order is partially filled, and see whether the numbers agree.
- Trigger a rejection, and read what comes back. If it is prose rather than a code, plan for that.
- Find the order-placement rate limit, not the headline one.
- Check whether read-only credentials exist. If they do not, every test runs with trading rights.
None of this is exotic, and none of it is in the quickstart guide. It is the difference between an integration that works on a quiet Tuesday and one that holds when the venue is busy and the agent is making decisions without anybody watching.
Frequently Asked Questions
Can an agent trade through a REST-only API?
It can, but it pays for it in latency and in missed fills. Polling a positions endpoint every second is both slower and more expensive in rate-limit budget than one streaming connection. REST-only is workable for strategies that hold positions for hours, awkward for anything shorter.
Why do idempotency keys matter so much for agents?
An agent retries. If the network drops after the order reaches the venue but before the response comes back, a retry without an idempotency key sends a second order. A human notices the duplicate; an unattended agent often does not, until the position is twice the size it should be.
What rate limits are typical?
Most retail-facing venues sit between 10 and 60 requests per second, often with a separate and much tighter budget for order placement than for market data. Read the two limits separately, because the order budget is the one that bites.
