An exchange API bulk order can succeed for some items and fail for others. Read the batch-level result and every item acknowledgement, preserve each order's identity, and confirm accepted or uncertain items against order and fill records. Retry only a specifically resolved item whose new submission remains authorized. Replaying the whole batch can duplicate orders that already exist or have filled.
This article was prepared with AI assistance. Its four-order ledger is an original hypothetical exercise, not a customer incident, trading recommendation or claim that KLINEO exposes a bulk-order control.
Read the envelope, the items and the executions
A bulk request is a container for multiple operations. Its convenient shape does not establish that the venue treats those operations as one indivisible transaction.
OKX explicitly describes its batch operations as allowing some operations to succeed while others fail. Its guide directs clients to inspect the individual sCode and sMsg values. That is a venue-specific contract, not a rule to infer from every exchange's use of the word batch. See OKX batch-operation guidance.
For Bybit's V5 batch placement endpoint, order identities appear in result.list, while item success/error codes appear in retExtInfo.list. The documentation describes consistent list structures and says placement acknowledgement is asynchronous; status must be confirmed through the WebSocket stream. Keep those paired results together rather than displaying only a top-level success banner. See Bybit V5 batch placement response fields.
For any adapter, separate three questions:
| Layer | What the evidence can establish | What remains to verify |
|---|---|---|
| Request envelope | Whether there is a usable response for this submitted request | Whether every intended item has a usable result |
| Item acknowledgement | Whether that particular operation was accepted or explicitly rejected under the endpoint's contract | Whether an accepted order is working, canceled or executed |
| Order and execution records | Current order state and recorded fills for an identified item | Freshness, completeness and any still-live remainder |
An order ID is a reference to investigate. It is not a receipt for the intended quantity. The trade IDs versus order IDs guide explains which records identify orders and which identify individual executions.
Preserve the request map before sending
Keep a local batch reference and a separate item record for each approved operation. The local reference groups the request; it cannot substitute for a venue-supported client order identifier on each item.
Each record should preserve the target account, environment, product, symbol, side, quantity units, limit or other price constraints, client identity and original request position. Add the exchange order ID, item code, item message and observation time when available. Store the response before transforming it into a simplified dashboard status, with credentials excluded from logs.
Use the endpoint's documented relationship between response items and request items. Where a contract uses parallel arrays, validate their expected cardinality and alignment; preserve request position alongside identifiers. Where response identifiers are returned, cross-check them against the intended item. A missing, duplicated or contradictory mapping needs investigation. Guessing that the third successful row belongs to the third requested symbol can attach a real fill to the wrong strategy.
This is an accounting recommendation for an integration. It does not establish a KLINEO implementation or imply that exchange client identifiers provide universal replay protection. The existing idempotency guide covers that separate limitation.
Work through four 100-USDT instructions
Assume a fictional spot account submits four independent limit buys in one batch. Each has a maximum gross purchase notional of 100 USDT. Prices, quantities and outcomes below are invented. Ignore fees, borrowing, slippage and other account activity solely to isolate batch recovery. All quantities are base-asset units, and fills occur at the stated limit prices.
The request envelope is usable, but the local recovery record has these item observations:
| Item and frozen intent | Item evidence | Subsequent evidence | Immediate handling |
|---|---|---|---|
| A: buy 10 ALP at 10 USDT | Accepted with order ID | All 10 filled: 100 USDT spent | Record execution; do not submit A again |
| B: buy 5 BTA at 20 USDT | Explicit entry rejection for an invalid price increment | No accepted order for this attempt under the documented rejection contract | Repair parameters only through a fresh authorized decision |
| C: buy 20 GAM at 5 USDT | Accepted with order ID | Eight filled; 12 remain live | Record 40 USDT spent and 60 USDT still possible |
| D: buy 25 DEL at 4 USDT | No usable item result preserved locally | Outcome unresolved | Recover original identity and query; do not resubmit |
D represents an evidence gap, not a claim that a particular exchange normally omits result rows. A malformed response, failed mapping or lost local record must not be reclassified as a clean rejection.
At this point, confirmed gross purchases are 100 + 8 × 5 = 140 USDT. C can still spend another 12 × 5 = 60 USDT. D's original instruction may account for up to 100 USDT under the example's assumptions. The batch therefore has 140 USDT of confirmed purchases plus up to 160 USDT of additional or not-yet-observed purchases. B's rejected 100-USDT plan does not cancel A, C or D.
Now suppose recovery finds D under its original client identity, with all 25 units filled at 4 USDT. Confirmed gross spending becomes 140 + 25 × 4 = 240 USDT, while C retains a 60-USDT live remainder. The original batch can reach 300 USDT of purchases without any retry. The fourth 100-USDT allocation belongs to the rejected B intent; its availability for a new order still depends on current account evidence and authorization.
Blindly sending the original four instructions again can duplicate A and C and, after D is found, D as well. A new client ID does not make those repeated economic intentions safe.
Reconcile selectively before creating more work
Group items by evidence, then act on each original identity:
- For an explicitly rejected create operation, retain the reason and check whether the original intent remains valid. A corrected price, quantity or account mode can change the economics. Revalidate rather than treating the repair as an automatic transport retry.
- For an accepted item, recover its order state and cumulative fills. A fully filled item is completed work. A live or partly filled item still has a remainder to manage.
- For an uncertain item, investigate the original request and supported order/history records in the correct scope. Keep it unresolved while evidence is missing or contradictory.
The order-timeout reconciliation guide explains ambiguous execution recovery. The partial-fill guide handles inventory and the remaining instruction after fills are known. Neither problem is solved by a batch-level failure label.
Refresh funding evidence before a permitted new submission. Existing accepted orders may reserve resources, and completed fills may have changed the account. The available versus total balance guide explains why a displayed total cannot establish the amount currently available for another order. The four-item example's arithmetic deliberately excludes these production complications.
A compensating order is a new trade
Suppose the strategy needed all four assets together. Partial success can leave an unwanted allocation even when the adapter handled every response correctly. If the venue's ordinary batch endpoint permits partial success, packaging the legs together does not create an all-or-nothing portfolio operation.
Canceling accepted orders cannot reverse fills. Selling already acquired assets introduces new orders, costs and execution uncertainty. A recovery policy must define who may authorize those actions and what exposure is acceptable while they are incomplete. This article addresses separate batch items; a paired cancel-and-replace operation has a different lifecycle and needs its own endpoint contract.
A useful completion record retains every intended item, its last known state, cumulative fills, live remainder, rejection reason and unresolved evidence. It distinguishes “all items accounted for” from “all orders finished.” A batch can be reconciled while C is deliberately still working. It cannot be considered reconciled while D has disappeared behind a general success or failure badge.