Partner APIs
Cash reconciliations
Record a cash count from your operator/cashier and let Fire compute the discrepancy against the system-tracked cash. Also returns past reconciliations via GET.
POST
Record an end-of-shift or end-of-day cash count for a store and have Fire compare it against what the system says should be on hand. Fire computes the discrepancy (
SHORTAGE, OVERAGE, or MATCH), categorises the cause, and stores the result in cash_reconciliations for audit and downstream reporting.
This page covers two operations on the same path: POST to record a new reconciliation, GET to list reconciliations for a store/day/operator.
Authentication
Your Fire API key.
- POST — requires the
cash-management:writescope. - GET — requires the
cash-management:readscope.
403.POST — Record a reconciliation
Request body
UUID of the store the reconciliation belongs to. Must belong to the API key’s account/vendor — Fire returns
400 (with hide-existence behavior — 404-equivalent) otherwise.Business day in
YYYY-MM-DD. Defaults to the store’s current operational day. Use this to record a reconciliation for a past day (e.g. retroactive corrections) — Fire flags the result with details.post_close: true if the day is already closed.Operator/cashier ID. Optional. Use it when the reconciliation is for a specific cashier shift; omit when reconciling the whole store-day.
ISO 4217 code (e.g.
BRL, USD, ARS, CLP, COP, VES). Length 3.Operator-declared amount of cash on hand. Non-negative decimal. Fire compares this against
systemCash (the amount the system thinks should be on hand based on sales and payments) to compute the discrepancy.Categorical cause of any discrepancy. One of:
WRONG_CHANGE_GIVENCOUNTING_ERRORINCOMPLETE_CUSTOMER_PAYMENTMINOR_UNIDENTIFIED_DIFFERENCETHEFT_SUSPECTEDUNRECORDED_PAYMENTOTHER
MINOR_UNIDENTIFIED_DIFFERENCE or OTHER per your operations policy.Free-text. Up to 2000 characters. Use it to capture extra context (operator name, shift notes, etc.).
UUID of an authorization token. When present, marks the reconciliation as “requiring/having approval” — typically used for
THEFT_SUSPECTED or large SHORTAGE cases that need supervisor sign-off.POST response
UUID of the reconciliation row.
Account that owns the store.
Vendor scope, when applicable.
Echo of the request.
YYYY-MM-DD.Echo of the request.
ISO 4217.
Computed amount of cash the system says should be on hand for this scope (store + day + optional operator). Derived from approved cash payments minus change given, plus opening float.
Echo of the request.
declaredCash - systemCash. Negative for shortage, positive for overage, zero for match.MATCH (zero), SHORTAGE (declared less than system), or OVERAGE (declared more than system).Echo or
null.Identity of the principal that recorded this reconciliation. For API-key callers:
"apikey:<keyId>".ISO 8601 UTC.
ISO 8601 UTC.
ISO 8601 UTC.
GET — List reconciliations
Returns reconciliations matching the filters.Query parameters
UUID of the store. Must belong to your API key’s account/vendor.
YYYY-MM-DD. Returns reconciliations recorded for this specific business day. Mutually exclusive with from/to.Filter to a single operator/cashier.
YYYY-MM-DD. Inclusive lower bound for the range filter. Use with to.YYYY-MM-DD. Inclusive upper bound. Use with from.GET response
Array of reconciliation records — same shape as the POST response data.
Common patterns
- End-of-shift flow. Call POST with the operator’s declared count when their shift closes. Display
discrepancyanddiscrepancyTypeto the supervisor for sign-off. - End-of-day reconcile. Call POST without
operatorUidfor a store-wide cash count after all shifts have closed. - Audit trail. Use GET with a date range to pull all reconciliations for a store across a period — useful for monthly or quarterly cash audits.
Related
Expected cash
Compute the system-tracked expected cash for a store/day before recording the count.
Authentication
How vendor-scoped API keys and
cash-management:* scopes work.
