Closure

​

Definition

In the POS API, a closure is the end-of-day summary for a point-of-sale location. It aggregates all sales, payments, and totals for a specific day.

​

Purpose

Closures provide the daily totals used for accounting reconciliation. They mark the boundary between one business day and the next.

​

Relationships

• A closure belongs to a location.
• It summarizes the sales and payments of that day.

​

Endpoints

---

​

See also

• Locations

​

Why it matters

In physical retail and hospitality, a “closure” is the everyday act of ending a business day: staff count the cash drawer, reconcile payments, and formally close the till or POS session. Once that happens, the sales recorded for that period are considered final: no more edits, refunds, or additions are expected. This matters for anyone building on POS data because orders can still change right up until that moment. Syncing that data too early, for example into an accounting system, risks pulling in numbers that aren’t final yet. The GET /pos/closures/{date} endpoint answers a simple business question: is this day’s data safe to use yet? open means the day isn’t finalized and orders may still change; closed means the day is done and its orders can be treated as final.

​

Closure detail

In addition to the status, the response includes a closures array when the connector makes it available. This array details each closure found for the requested date: its id, total, tax_amount, and payments and taxes breakdown. This array is only populated for some connectors with native closure data. For connectors without native closures, closures is always empty, since there’s no underlying closure record to detail. See Get closure info for a specific day for more details.

---

​

Native closure connectors

Some POS systems track their own end-of-day closure (a Z-ticket, a shift document, a session, etc.). For these connectors, Chift checks whether that native closure exists for the requested date and returns its status directly. No inference is applied. The rule is the same across all native connectors:

• A date that is today or in the future always returns open.
• Any past date returns the status of the connector’s own closure record for that day.

Native closure connectors handle the closures array in one of two ways:

• "closures": [] contains the orders summary.
• "closures": [] is empty and contains no orders summary.

​

Connectors without native closures

When a POS doesn’t expose its own closure concept, Chift infers the status using a time-based rule instead:

• A date that is today or in the future returns open.
• A date more than 7 days in the past returns closed.
• For dates in between, Chift checks if there are orders on the following days as an indicator that the requested day is closed.

---

​

Implementation guide

You don’t need to build separate logic for each connector. The native-versus-inferred distinction above is what Chift abstracts for you. The following covers every connector:

​

1. Wait for closed before processing a day

• Only treat a day’s orders as final once GET /pos/closures/{date} returns closed. An open day can still receive new orders, so processing it too early risks missing data.
• If a day contains multiple closures, you can use the closure already returned even if the day is still open. Make sure to keep closure_id as a reference to avoid duplicates.

​

2. Fetch the day’s orders the right way

Check whether the closures array contains enough data (id, total, tax_amount, payments, and taxes) for your needs. If you need additional data about the day’s orders, wait until the day returns closed. Then look at the closure response to decide how to get its orders:

• If GET /pos/closures/{date} returns one or more closure_id, use each entry’s closure_id to fetch the matching orders. A single day can have more than one closure, so pull orders for every closure_id returned, not just the first one.
• If GET /pos/closures/{date} doesn’t return closure_id, fetch orders with date_from and date_to set to that day or date range.