Skip to main content
PUT
An order created at the kiosk and paid at the counter stays open until it is charged. In the meantime the cashier may need to correct it: the customer asks for an invoice with their tax ID, or the locator number printed on their ticket has to be entered. This endpoint corrects that data without touching the payment.
Open orders only. An order that was charged, cancelled or already invoiced has already produced its consequences and is not corrected retroactively.

​
Update order vs. Confirm payment

They are two separate endpoints on purpose. One corrects the order, the other charges it, and neither writes what belongs to the other. Payment methods are not corrected here. If the body carries payments.paymentMethods or a status, the response is 400: the order status is derived from the payment and only Confirm payment writes it. We reject it instead of ignoring it because a silently dropped APPROVED would be money you consider collected and we don’t.

​
The full flow

No extra step is needed for the invoice to carry the corrected data. When the payment settles, Fire builds the order.completed event by reading the order at that moment, so it travels with your latest correction.

​
Authentication

​
string
required
Your Fire API key with scope orders:write. The key must be vendor-scoped — keys without a vendorId are rejected with 403.

​
Path params

​
string
required
Any of the order’s three public references:It is the same set accepted by Get order and Confirm payment.

​
Body

Two control fields, always, plus one or more blocks. Whatever you don’t send is left untouched.
​
integer
required
The order revision you read with Get order. If the order changed since then —another register corrected it—, the response is 409 STALE_REVISION and nothing is written. That way two registers never overwrite each other unnoticed.
​
string
required
A unique identifier per correction (up to 200 characters), generated by you. If the response doesn’t reach you and you retry with the same key, you get 200 duplicate and the correction is not applied twice.Without this key, a retry would collide with expectedRevision —which already moved— and you couldn’t tell whether your correction went in or someone else wrote.

​
Locator and kiosk — additionalInfo

Applied field by field: send only what changes. If you correct the locator, the buzzer name and the invoice email stay as they were.
​
string
The locator: the number printed on the customer’s ticket and called out at pickup.
​
string
Name used to call the customer.
​
string
Email the invoice is sent to.
​
boolean
Whether the customer wants a printed invoice.

​
Final consumer — client

This block REPLACES the whole buyer. It is not a patch: whatever you don’t send ends up empty. Sending { "uid": "…", "name": "Juan" } on an order that had a tax ID erases the tax ID.This is deliberate. Name, document and address are one piece of data: mixing a new name with an old document produces a wrongly issued invoice, and that can only be fixed by voiding and reissuing. Always send the complete buyer, not the difference.
​
string
required
Customer identifier. Required precisely because the block replaces: without it the order would be left without a customer. Use the one the order already has.
​
string
Document type: CEDULA, RUC, PASAPORTE (Ecuador); CC, NIT (Colombia); CPF, CNPJ (Brazil); or FINAL_CONSUMER.
​
string
Document number. Dots, dashes and spaces are accepted; Fire strips them. A filler of repeated digits (9999999999999, 222222222222) is treated as final consumer.
​
string
Name or company name.
​
string
Last name.
​
string
Buyer’s email.
​
object
The invoice recipient, and it takes precedence. Fire builds the receipt’s buyer by reading billingInformation first (govIdType, govIdNumber, name —or businessName when name is absent—, email, address) and only then the client fields. It exists separately because the invoice can go to a company other than the person.If you correct the document, put it here. Kiosk orders carry this block as final consumer: correcting only client.govIdNumber and resending billingInformation unchanged leaves the receipt as final consumer. If you don’t send it, it ends up empty and client is used.
From this block Fire recomputes the buyer printed on the receipt. You don’t need to send it separately.

​
Products — not yet

Correcting products and totals is not enabled yet. If the body carries order or payments, the response is 400. It will be enabled once taxes and the total are also validated against the lines, as they are when the order is created.

​
Request

​
What Fire does with what you send

Keep the revision from the response: it is the one to send in your next correction.

​
When the order can’t be corrected

Each case has its own code, because each calls for a different action. All are 409 and write nothing. The check happens at the same instant as the write, so if a payment lands while you are correcting, one waits for the other: they never overwrite each other.

​
Idempotency and concurrency

Retrying is safe. If the response didn’t reach you, resend the same body with the same idempotencyKey: Use a new key for each different correction. Reusing a key for another change returns duplicate and the new change is not applied.

​
Events

This endpoint emits no events. The correction stays on the order, and when it is charged, the order.completed event carries the corrected data: locator, buyer and billing details.
There is no order.updated, on purpose. Event delivery is not ordered: a correction notice arriving after order.completed would be a stale fact your system might act on by mistake.

​
Validations

All return 400 unless stated otherwise. Branch on the code, not on the text: the message may be rewritten, the code is contract.

​
Responses

Get order

Read the revision before correcting.

Confirm payment

Charge the order once it is corrected.