Why a bot loses orders in Coinbase Advanced Trade API
Integration of a trading bot with Coinbase Advanced Trade API breaks not in the strategy, but at the interface with the exchange.
An order goes out, a response comes back, but the position state on the bot and on the exchange diverges — and every subsequent trade is calculated from an incorrect base.
The first failure point is status desynchronization. The response to a request and the event stream do not arrive simultaneously: the bot keeps an order open when it has already been filled, or waits for confirmation on a canceled trade.
Partial execution makes it worse: the bot sees the first fragment, considers the volume complete, and builds the position on paper while the remainder continues to fill in the order book.
The second is duplicates after a connection drop. The connection breaks between sending an order and receiving a response, the bot repeats the request and opens a second position instead of one.
The problem is solved by a client identifier for idempotency and an intent log that is written before sending, not after.
The third is rejected orders whose reason the bot does not parse. A restriction on order type, size, or price comes in the response body, but the automation sees only an error code and retries blindly.
In reporting, this causes trade discrepancies: the number of fills and the volume do not match the log, and the position turns out larger than the real one. Below we examine how this is closed at the exchange communication layer.
Measurable effect: what changes after integration setup
The bot works with Coinbase Advanced Trade through the exchange's standard interface, so the order state does not have to be guessed: status, volume, and remainder come in the response to a request rather than being reconstructed from indirect signs. Below is what exactly changes in operation and how it is measured.
Execution completeness and automatic trade reconciliation
The order is brought to a final state: partial fills are collected based on actual trades and are not lost on reconnection.
Reconciliation is based on the event log — the bot's position and the exchange-side balance match on every iteration, and any discrepancy surfaces immediately, not at the end of the shift.
| Metric | Before setup | After |
|---|---|---|
| Orders with confirmed final status | 85–90% | ~100% |
| Manual reconciliations per shift | 5–10 | 0 |
| Position discrepancy investigation | hours | minutes |
Resilience during connection drops and peak loads
Connection drop, request failure, exceeding the rate limit — each class is handled separately: the bot queues the action, retries it without duplicating trades, and continues from the same state.
Retries are idempotent, so a network failure does not turn into a double order, and a burst of activity does not lead to missed signals.
Event logging is end-to-end: every action has a timestamp and reason, and every exchange response is linked to an order. With such a log, an incident is investigated in minutes rather than retold from memory.
Trading API, file exchange, or manual trades: comparison
The method of connecting trading logic to the exchange determines how quickly the system reacts to the market and how many risks move to the infrastructure.
In practice, there is a choice between three modes: direct connection via trading keys through Coinbase Advanced Trade API, exchange via file exports, and a semi-automatic mode where the final decision remains with a human.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection via trading keys | Need to react to an event within seconds, constant order flow | Trading keys reside on the server: isolation, rotation, a separate account, and withdrawal limits are required |
| Exchange via exports (file exchange) | Low trade frequency, strategy recalculated once an hour or less often | Delay between signal and execution, manual reconciliation of discrepancies, risk of duplicate order on repeated import |
| Semi-automatic mode | Decision depends on context that is poorly formalized by rules | Throughput is limited by the human, execution depends on operator availability |
Direct connection via trading keys
We create keys for a separate account with reduced permissions: trading is allowed, withdrawal of funds is not.
We tag orders with our own identifier so that resending after a network drop does not open a second position, and we reconcile order state with the exchange on a schedule.
Connection errors and rejected orders are written to the log with the reason — incident investigation takes minutes, not hours.
Semi-automatic mode with human confirmation
The system calculates the signal, the operator confirms sending — this removes the class of errors "incorrect position size" and "triggered on stale data." The price of control is confirmation delay: in a volatile section, part of the price is lost to movement.
The mode is justified while trade flow is small and decisions require context that cannot be described by rules.
Implementation stages: from key review to handover of procedures
Integration of a bot with Coinbase Advanced Trade API rarely comes down to a single call: key permissions, pair limits, and behavior during partial execution determine whether it will survive the real market.
Therefore, the work proceeds in stages, and each ends with a verifiable result rather than a status of "in progress."
Audit of the current scheme and access rights
- Audit of trading keys: which operations are allowed, whether the key has withdrawal of funds, where secrets are stored, and how they are rotated. The output is an access map and a list of excessive permissions that we remove before work begins.
- Flow design: the order path from signal to confirmation, behavior during partial fill, cancellation, and connection drop. We fix the order states and which of them we consider final.
- Processing exchange responses: we map rejection codes to bot actions — retry with the same identifier, wait, stop. Separately, we close the divergence between local state and exchange state.
Verification on historical data and in a test environment
- Run on historical data: feed a recorded quote stream and compare calculated trades with actual ones — logic errors are visible before going live on a real account.
- Test environment: reproduce rate limits, delays, and partial fills to catch scenarios that are not in history.
- Load run: behavior during activity bursts and connection degradation, recovery time after a drop.
- Handover of procedures: documentation on keys and rotation, flow diagram, rules for responding to rejections, and the manual stop procedure.
Handover package: configurations, flow diagrams, procedures
The handover documentation package is not a folder of files but a working tool for the on-call shift. We keep it versioned: each section has an owner, a date of reconciliation with the actual configuration, and a note on what exactly was checked.
Access policies and separation of permissions
We separate Coinbase Advanced Trade API keys by purpose: reading accounts, placing and canceling orders, withdrawing funds.
We do not grant withdrawal permissions to the trading system, so compromise of a working key does not open access to the balance, and rotation is described as a procedure with revocation of the old key.
- Working environment configurations: connection addresses, limits on order size and frequency, retry parameters.
- Data flow diagram: the path from market stream to trade record in accounting, with points of possible loss or duplication.
- Permission matrix: who is issued which key, for what term, who confirms revocation.
- Event logs: what is mandatory to record — order, response, rejection, balance change — and how long it is stored.
- Incident handling procedure: a list of situations and the signs by which the on-call operator identifies each one.
- Shift instructions: step-by-step actions, escalation points, prohibition on manual state edits without a log entry.
Procedure for actions during failure and connection drop
A connection drop with the exchange and a failure of our own service require different actions, so they are separated in the procedure.
Position reconciliation after recovery is a separate item: without it, the bot will place a duplicate order, assuming the previous one did not go through.
We supplement the package during the first operating cycle — where the wording proved incomplete during investigation of real failures.
Case study: trade reconciliation and bot resilience under load
The client is a market-making team trading several pairs through Coinbase Advanced Trade. The bot placed orders, but position state matched exchange reports only manually: reconciliation was run once a day, so a discrepancy on one of the pairs persisted until the next morning.
Before: manual reconciliations and discrepancies in reports
The share of unexecuted orders held at about 4% — some orders were rejected on the exchange side, and the bot did not distinguish a limit rejection from a network error, repeating the send.
This led to duplicates: during peak hours, up to 12 orders per signal, and the discrepancy between the local log and trade history was found on average within 40 minutes.
An analyst spent up to six hours per week on reconciliation, and each failure meant 20–30 minutes of trading downtime.
After: automatic reconciliation and clear error handling
We separated response codes into temporary and permanent: a retry is sent only where it makes sense, and an order rejected by limit is returned to the queue with volume recalculation.
Automatic reconciliation runs continuously and compares local state with exchange state after every order close, not once a day.
The share of unexecuted orders decreased to 0.3%, duplicates disappeared, and discrepancy detection time is seconds instead of 40 minutes.
Manual reconciliations were reduced to 20 minutes per week, and trading downtime on incidents — from half an hour to restarting a single stream.
What to do if the bot is already trading but trades do not reconcile?
The discrepancy is almost always not in the strategy but in how the bot learns the fate of its order. If confirmation did not arrive in time, resending causes duplicate orders: there are two on the exchange and one in accounting.
The second source is partial execution: volume is closed in several portions, but the bot treats the trade as a single one and does not recalculate the average price and actual position size.
First, reconcile not the bot's internal state but the trade log on the Coinbase Advanced Trade API side. The source of truth is filled portions and the final balance, not what the bot wrote to its memory.
After trading failures — connection drops, process restarts — the cause is usually lost events and the absence of a unique client order identifier by which a repeated order can be discarded.
The working scheme is built on idempotent sending: an order is tagged with its own identifier, and a retry with it does not create a new order.
Current state is maintained on the event stream, and every few minutes there is a full reconciliation of positions, orders, and commissions with exchange history — this way, unreconciled trades are visible immediately, not a day later.
Migration to the corrected loop happens without stopping trading.
The new logic runs in parallel on the same market data in calculation mode, without placing orders, and is compared with current results; then instruments are migrated one by one, with the ability to revert to the previous scheme.
Common technical doubts before starting work
Before starting, the same five questions usually come up — from key permissions to bot behavior when the exchange returns an error or drops the connection.
Below are short answers on Coinbase Advanced Trade API; if your scenario is broader, we will go through it on a call for the task.
What permissions should be granted to the key, and can withdrawal of funds be prohibited?
The key is created for trading only; the withdrawal option is disabled in its settings. If permissions are reduced more than needed, the integration fails at startup with an explicit error — before the first real order, not at the moment of a trade.
What happens during a connection drop with the exchange?
The bot reconnects with an increasing pause, and after recovery it reconciles balances and open orders with the actual account state. The order is sent with an idempotency key, so resending does not create a duplicate position.
How can the logic be tested before real trades?
Work is done in a test environment: we run partial execution, cancellation of the remainder, rejection by request limits, and session drop. Only after that is the bot moved to a minimum volume, where we compare the position calculation with the exchange report.
How is partial execution handled?
State is maintained for each order separately: the bot records the filled volume, calculates the remainder, and does not consider the position closed until the final status. Cancellation of the remainder and re-entry do not break accounting.
How are keys rotated, and what is included in support?
Accesses are stored in a secret vault; key replacement happens without stopping the bot — the old one lives until zero traffic. Integration support: monitoring exchange errors, alerts on balance discrepancies, and scheduled checks after changes on the trading venue side.
Let's discuss the task: what to send for an estimate and plan
So that the integration timeline estimate is based on facts rather than "about the same as everyone else," we need source data for an estimate based on your scheme.
We collect it before the start: this way we do not spend iterations on guesses when the bot is already running on real orders.
- Description of the current scheme: where the bot runs, how it places orders, how it stores position state.
- Export of logs for a period — 2–4 weeks of trading including rejections and errors, not only successful trades.
- List of key permissions: what is allowed, what is disabled, whether there are separate read-only keys.
- Access for audit — read-only keys or an export of trade history if full access cannot be granted.
- Example of the bot's report: how average entry price, commissions, and closed positions are calculated.
- Known failures: duplicate orders, position desynchronization, connection drops, exchange rejections.
- Restrictions on trading pairs and request rate, if you have already hit them.
- Test environment: access to a sandbox or test keys, if one is already set up.
Next is a review of the scheme, identification of areas where integration with Coinbase Advanced Trade API behaves differently than expected, and a stage-by-stage work plan: audit, key permissions, exchange response handling, reporting, acceptance in the test environment.
Let's discuss the task — describe it in free form. If some data is not available yet, we will start with what is available and come back with an estimate and plan.