Skip to main content
GET
Answers whether an order can be cancelled, without cancelling anything. The point of sale calls it to show or hide the cancel button, and to explain to the cashier why when it cannot. It runs the same policy service as the real cancellation, so the preflight and the outcome cannot disagree about the rules. The natural pair of this endpoint is Cancel order: this one asks, that one executes.
orderId accepts any of the four ways an order can be named from outside: the external order id your channel generated when injecting it, the order_id that travelled in the injection payload, Fire’s order_code, and Fire’s internal UUID. Fire tries all of them within your key’s vendor. If the id matches more than one order in that scope, Fire refuses with 409 instead of guessing: answering about the wrong order would be worse than not answering.
A 200 does not mean “yes”. The verdict travels in the body: this endpoint returns 200 even when the order cannot be cancelled, because “no” is the answer to the question, not an error. A non-200 status is a real error — authentication, unknown order — never a policy denial.

​
Authentication

​
string
required
Your Fire API key with the orders:read scope. The key must be vendor-scoped — keys without an account binding are rejected with 403. The tenant is derived from the key, never from the request.

​
Path parameters

​
string
required
Order identifier. Accepts the external id, the payload’s order_id, Fire’s order_code, or Fire’s internal UUID.

​
Query parameters

​
string
default:"es"
es, en or pt. Language of reason, reasonDetail and outcomeLabel. It only affects Fire’s own rules, which carry their label in all three languages; the text of a rule configured by the account is theirs and comes back exactly as written, untranslated.

​
Response

The verdict comes wrapped in the standard envelope: { "success": true, "data": { ... } }.
​
boolean
The answer. It is the same verdict the real cancellation will give.
​
string
Raw policy result: ALLOW or DENY. Today it is redundant with canCancel on purpose: it travels from day one so that if a third outcome ever appears, adding it does not break existing consumers.
​
string
Display name of the outcome, in the requested language. It is the safety net when reason is null: without it, a denial by an unnamed rule would reach the cashier without a single word to show.
​
string | null
The reason, stable. null when the order can be cancelled. This is the contract — decide in code with code, never by parsing reason. The possible codes are listed below.
​
string | null
The name of the rule that decided, for humans. Fits in one line on a POS screen. It is editable and translatable text — not a contract.
​
string | null
The long note of that same rule, or null. Separate from reason so the consumer decides how much space to give it: a POS paints one line, a detail screen can paint both. Also editable text, not a contract. Fire’s own rules carry no note, so a denial by a Fire rule always comes with reasonDetail: null — that is expected, not a bug. The note only appears on rules configured by the account.
​
string
Where the decision came from: baseline (a Fire rule), account (a rule configured by the account), or default (no rule matched — the order can be cancelled).
​
object | null
Present only when the winning rule compared against a numeric threshold.With this you can tell the cashier “over the limit by 17 minutes” without learning any new codes.
​
object
The evaluated context, as a map of field to value. It is the forensic receipt: it lets you reconstruct why this was decided even if the configuration changes afterwards.

​
A true here is the same true the POST /cancel gives

It was not always so. The credit note and the business day were checked separately inside the real cancellation, this endpoint skipped them, and a pending field announced those two omitted checks. That field is gone: both are policy rules now, and both endpoints run them. One difference survives, and it is a legitimate race rather than a design gap: between asking and cancelling, the business day can close or someone else can fire a cancellation. Asking reserves nothing. This endpoint answers for one order on purpose: resolving it costs two queries, and over a list that would be one per row.

​
Denial codes

The real cancellation returns the same code when it denies for the same reason.

​
What to build with each field

  • Decide in code with code. reason and reasonDetail are editable, translatable text — never parse them.
  • Show reason on one line; reasonDetail is the paragraph, for screens with more room. When reason is null on a denial, fall back to outcomeLabel.
  • Use threshold to render “over by N” messages generically, without knowing any rule in particular.
  • Keep resolvedFrom in your logs: it is the receipt that explains the verdict even after the account’s rules change.

Cancel order

The other half of the pair: this endpoint asks, that one executes.

Get order

Read the order the verdict refers to.