Updating Ex-post Orders

This page explains exactly what happens when you update an existing Ex-post electricity order, and how to update orders safely when they may already be partially filled.

PUT /public-api/2.0/electricity/orders/{id}

Key rule

The quantity you send in a PUT becomes the order's new open quantity. It is not a delta, and it is not reconciled against volume that has already been executed. If you resend the original order size after a partial fill, the filled volume is placed back in the book.

How an update works

quantity is the size going forward

The quantity field in the request body is required and is applied verbatim as the order's live open quantity. ETPA does not subtract already-executed volume when processing an update.

To change only the price of an order, send the order's current remaining quantity together with the new price.

An update replaces the order

A PUT is processed as a delete of the existing order followed by the creation of a new one. On the SSE orderbook feed you will see:

1. A delete message for the old order ID.
2. A create message with a new order ID and a new priority timestamp.

Use the new order ID for any further actions on that order.

Price-time priority is always reset

Because the updated order enters the book as a new order, it loses its original queue position, even if only the price changed. It is not possible to preserve priority through a PUT.

quantity vs originalQuantity

Partial fills do not change an order's ID. After a fill, the SSE feed reports the same order ID with a reduced quantity, while originalQuantity stays unchanged.

Field	Meaning	Use as PUT input?
quantity	Current remaining (open) size	Yes
originalQuantity	Size at order entry	No

Example: accidental quantity restoration

Step	Event	Order ID	quantity	originalQuantity
1	Order placed	A	8.2 MW	8.2 MW
2	Partial fill of 1.9 MW	A	6.3 MW	8.2 MW
3	PUT with new price and quantity: 8.2	B (new)	8.2 MW	8.2 MW

After step 3, 8.2 MW is open again. Combined with the 1.9 MW already filled, total executions can reach 10.1 MW, more than the intended 8.2 MW.

Correct request at step 3: send quantity: 6.3 with the new price.

Updating while fills are arriving

ETPA does not validate the submitted quantity against the order's current state. Specifically, the Ex-post order API does not currently offer:

• a price-only update
• an order revision or version number
• ETag / If-Match conditional requests
• an expected-current-quantity precondition
• rejection or clamping of a quantity larger than the remaining quantity

This means a PUT built from a slightly outdated view of the order is still accepted:

1. You see order A with 6.3 MW remaining.
2. You prepare a PUT for A with quantity: 6.3.
3. Before your request arrives, a further fill reduces A to 4.3 MW. The ID stays the same.
4. Your PUT is accepted and sets the open quantity to 6.3 MW, which is 2.0 MW more than was actually open.

note

This trade-off is intentional: the Ex-post order API is optimised for trading speed, and server-side reconciliation of executed volume is not performed.

Recommended update pattern

1. Read the current state immediately before the PUT. Use the order's latest quantity from the API or from your live SSE view.
2. Submit the current remaining quantity, never originalQuantity, unless you deliberately want to increase the open size.
3. Keep the read-to-PUT interval as short as possible. Treat the quantity you read as a best-effort snapshot, not a guarantee.
4. Track the new order ID from the create message on the SSE feed and use it from then on.
5. Reconcile executions against your intended total size, especially when updating orders during active trading.

tip

Fetching the current state just before updating prevents the most common mistake (resending the original size). It narrows, but cannot fully close, the window in which a fill can land between your read and your write.

FAQ

Can I change only the price? Not as a separate operation. Send the new price together with the current remaining quantity.

Why did my order get a new ID after I changed the price? Every update replaces the order with a new one. The new ID and new priority timestamp are expected.

Why did I lose my queue position? Any update resets price-time priority because the order re-enters the book as a new order.

My executions exceeded my intended order size. Why? Most likely a PUT was sent with originalQuantity, or with a remaining quantity that was outdated by a fill that happened just before the update. Compare the quantity in your PUT with the order's remaining quantity at that moment.