AI Trading Bot Order Edits: 8 Checks Before You Amend or Replace

DN AI Trading Beginner Series · Reviewed 9 November 2026

Your bot reports that an order was edited. One identifier stayed the same; another changed. Was that an amendment to the existing order, or a cancellation followed by a replacement? “Edited” is too broad a label to settle the question.

The answer matters when you follow the order’s history, interpret an error or investigate a later fill. Start with the operation that was actually requested. This guide examines a single spot order without borrowing rules from derivatives, linked-order groups or another exchange’s API.

DN’s order-timeout guide already explains why cancellation and replacement need separate outcomes. Here, the focus is the documented edit route: what it changes, which identifiers survive and where the evidence belongs.

1. Name the exact edit route

Record the venue, product, API version and operation name. “Kraken edit” or “Binance update” is not precise enough when the same provider documents different transaction models. A hosted bot’s button label may also conceal which exchange operation its connector uses.

Keep the route name with your evidence. For the Binance REST profiles, the documented operations are PUT /api/v3/order/amend/keepPriority and POST /api/v3/order/cancelReplace. For the Kraken profiles, the WebSocket v2 method names in the table are part of the distinction.

If your bot does not reveal the underlying route, leave the route unknown and ask its operator or support team. Do not infer it from a familiar-looking ID. The worksheet can retain the entered results while withholding route-specific interpretation.

Also keep a harmless account alias, instrument, environment and connector-instance alias. These labels help distinguish the operation you are reviewing from another request or a test account.

2. Check which fields that route can change

Name the intended change before considering whether the operation succeeded. A quantity reduction, a quantity increase and a new limit price are different requests. An endpoint whose purpose is narrower than your intended change cannot be treated as a general-purpose editor.

Kraken’s atomic-amend guide permits price and quantity changes, including trigger and iceberg display fields; other attributes require different handling. [4]

For a simple spot limit-order case, keep the record to the relevant field. If the request changes several attributes, identify each one privately and consult the exact documentation. The tool’s broad change selector does not validate a payload, exchange filters, permissions or funds.

An intended price change entered alongside the Binance Keep Priority profile is a useful discrepancy to preserve. It asks whether you selected the wrong route or described the intended change incorrectly. It does not establish that an incompatible request was submitted or that an exchange accepted it.

Keep configuration changes separate too. Editing a bot’s default entry rule is a different question from editing an already-submitted exchange order. Use the bot-settings guide when the uncertainty concerns which saved or running configuration receives a change.

3. Establish what the quantity field means after fills

Before copying a quantity into an edit, establish whether the field describes the revised total order or the quantity requested for a new replacement. Keep its asset unit attached. The number you want to trade from this point onward is not automatically the value required by every edit endpoint.

Kraken’s amend_order route documents that reducing the new order quantity below the existing filled quantity cancels the remainder. [3]

Kraken legacy edit rejects newly supplied volume below its executed volume. [5]

This is a reason to identify the route, not an instruction to reduce an order below its fills. An edit cannot make previous executions disappear from the history. The current request and its evidence must account for the documented meaning of the field you are changing.

The outcome map intentionally has no fill or remainder calculator. It does not calculate a replacement size, a balance or the amount still exposed. Preserve the quantities in the appropriate private records and use the partial-fill guide for that accounting question.

4. Compare identifiers within their own namespaces

An identifier’s namespace means the kind of thing it identifies. An exchange order ID identifies an order at the venue. A client order ID is a separate label supplied or managed through the client interface. A request ID or amendment ID can identify an operation concerning the order.

Binance Keep Priority generates a new client ID by default, but permits retaining the current one via newClientOrderId. [2]

Kraken’s amendment reply distinguishes amend_id, identifying the amendment transaction, from the order identifiers. Its optional req_id is a client-originated request reference echoed in the response. Neither should be substituted for the returned exchange order ID. [3]

In the worksheet, compare the before and returned exchange aliases with each other. Compare client aliases separately. For an amendment, the returned exchange field refers to the amended order; for a cancel-new operation, it refers to the replacement. Do not put a cancellation acknowledgement reference in that field.

Exact matching is only a comparison of the text you entered. If two records belong to different accounts or requests, matching labels do not establish a relationship. If the typed relationship is unclear, preserve the raw comparison and leave the route-rule conclusion unassessed.

5. Keep queue priority separate from order identity

A retained order ID does not mean that every property of the order stays unchanged. In particular, queue priority concerns its place among orders at a price. An identifier comparison cannot measure that place or predict when the order will fill.

Kraken’s guide distinguishes priority-preserving reductions from changes that requeue. [4]

The planner can display a documented priority rule for a selected change kind. It cannot establish that your particular request reached the engine, that the actual payload matched your description or that a position in the queue was retained in a live account.

If the change combines quantity and price or includes another attribute, keep the explanation conditional until the relevant rules are established. “Same ID” should never become shorthand for “nothing operationally significant changed.”

6. Read the response shape that belongs to the route

Match the result fields to the selected operation. A reply containing one operation result is different from a response containing two separately reported results. Avoid translating every provider into a made-up common success flag.

Binance cancelReplace supplies cancelResult and newOrderResult. Keep both values and the selected request mode. [2]

Kraken’s legacy reply returns order_id and original_order_id with composite success. [5]

A missing reply, an empty field or an unclear error remains missing evidence.

The tool preserves each entered result independently. One known leg does not fill in the other. An incompatible mode/result combination remains a conditional discrepancy in the supplied record. This says nothing by itself about whether either order is currently open, filled, canceled or otherwise changed.

7. Distinguish a preview, a submitted request and an amendment event

Label what you actually received. A preview concerns a proposed operation. A request reply describes the documented processing stage. An account event reports a different piece of evidence. These records can be related without being interchangeable.

Kraken legacy edit’s validate=true performs validation only; exclude those replies here. [5]

Coinbase Advanced Trade exposes an orders/edit_preview endpoint separately from its edit endpoint. The preview response includes error and order-cost fields. Retain it as preview evidence rather than relabeling it as the edit receipt. [6]

The actual Coinbase orders/edit reference describes success as whether the edit request was placed. That wording does not establish a fill or the present account state. Coinbase is a documentation example here, not an additional route modeled by the worksheet. [7]

Kraken’s execution stream separately identifies user-initiated amendment events, engine-initiated restatements and trades. Its amendment flag also points to modification history. An amendment event should retain that meaning when you organize the evidence. [8]

If only a later bot summary is available, label it as a later summary. A friendly “updated” message needs its own scope: which request, which route and which response did the bot use to produce it? A later explanation does not become a direct exchange reply merely because it repeats the order ID.

8. Finish with an evidence record, not a retry instruction

Retain the selected route, the request alias, the relevant context, the result fields actually supplied and the correctly typed identifiers. Keep a safe pointer to the response. Describe known discrepancies in the record separately from unanswered questions about the account.

Binance warns that timeouts and internal-server errors can leave execution status unknown; they do not necessarily mean the operation failed. Its documentation describes checking for the status when the account stream has not supplied it. The general lesson is to preserve uncertainty instead of manufacturing a failed result. [9]

A useful support note might say: “This operation is reported as the legacy edit route, and the returned exchange alias equals the original under the same request context. Please identify which response field should contain the replacement order ID.” That is a specific evidence question without declaring the actual venue state.

For the record behind a bot’s decision, use the bot-logs guide. For a working order whose management is unclear, use the orphan-orders guide. The timeout guide addresses unresolved execution and retry questions.

A completed map is not a closure certificate. It can show that the supplied declarations fit a documented route while current state remains unverified. It can also reveal a clear alias conflict while other evidence is still missing.

Keep the next evidence question narrow. If the route is unknown, ask which operation the connector used. If an alias conflicts, ask which named response field supplied it. If the response is incomplete, identify the missing part without rewriting the parts you already have. That gives another reviewer a concrete question and preserves the distinction between a documentation expectation and an account observation.

Worked example: same exchange order, different client label

This fictional case selects Binance Keep Priority and describes a quantity reduction. The request is REQ-A, its response evidence is RESPONSE-A, and the context uses VENUE-A / ACCOUNT-A / SPOT:BASE-QUOTE / TEST-A / INSTANCE-A. These are teaching aliases, not account data.

The reader reports success, attributes the reply to that request and supplies EX-A for both the before and returned exchange order. The client aliases change from CL-A to CL-B. The map can describe the exchange-ID declaration as consistent with the selected profile and the client change as permitted variation. It does not authenticate the reply or establish current order status.

The important comparison is within each namespace. Replacing the returned exchange alias with an amendment reference would answer the wrong question. Likewise, interpreting the changed client label as proof of a new exchange order would exceed this route’s contract.

The six fictional cases also include four different Binance paired-result records and a successful Kraken legacy edit whose returned exchange alias matches the original. That last case preserves a route-rule discrepancy without inventing internal cancellation or placement results.

Methodology and limits

DN’s map is a deterministic interpretation of reader-entered declarations against four documented profiles. It keeps response shape, literal identifier comparison, scoped expectations, change intent and evidence limitations separate. It does not discover the provider route or inspect the original response.

The six dataset cases are synthetic teaching records, not captured provider responses or performance measurements. Unknown values remain unknown. A mode conflict or ID-rule conflict describes the entered combination under its stated assumptions; it does not replace an exchange query.

The tool excludes fill arithmetic, remaining exposure, current working-order status, order eligibility, fees, retry decisions and actual execution. It cannot predict queue position or certify that a strategy is suitable. Product documentation can change, so retain the reviewed route and date with any application of the guide.

Frequently asked questions

Primary sources

Official documentation reviewed on 9 November 2026 (SAST). Each example is specific to the named product and request route. Documentation findings do not verify an individual account or order.

1. Binance Spot: Keep Priority
2. Binance Spot REST: Trade
3. Amend Order — Kraken Spot WebSocket v2
4. Kraken: Atomic Amends
5. Kraken WebSocket v2: Edit
6. Edit Order Preview — Coinbase Advanced Trade
7. Edit Order — Coinbase Advanced Trade
8. Executions — Kraken Spot WebSocket v2
9. General REST API Information — Binance Spot
10. Get Started With Spot Trading — Binance