Closure

​

Closure

​

Why does it matter?

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. An order created earlier in the day could still be voided, discounted, or corrected. 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. Not every POS software formalizes this the same way. Some have a real closing action performed by staff, a Z-report, an end-of-shift close, a session close, that Chift can check directly. Others never require this step at all: transactions simply accumulate, with no explicit moment when a day is marked “done.” For those, Chift estimates whether a day is likely finished based on how much time has passed, since there’s no native signal to rely on. The GET /pos/closures/{date} endpoint tells you whether the end-of-day closure for a given date has already happened. This is mainly used before syncing orders for accounting purposes: once a day is closed, its orders are considered final and safe to process. How this status is determined depends on whether the POS itself exposes a native concept of closure.

​

Closure detail

In addition to the status, the response includes a closures array (when made available by the connector) with the detail of each closure found for the requested date, its id, total, tax_amount, and payments and taxes breakdown. This array is only populated for connectors with native closure data and native data from the closure. 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.

​

Connectors without native closures

When a POS does not 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 orders on the following days as an indicator that the requested day is settled.

Refer to each connector’s own page for the exact implementation of this rule.

---

​

What this means for your implementation

You don’t need to build separate logic for each connector — the native-versus-inferred distinction above is exactly what Chift abstracts for you. Connector differs to another in how you retrieve a day’s data once it’s closed — that’s what your implementation needs to handle. Two patterns cover 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.

​

2. Fetch the day’s orders the right way

Once a day is closed, look at the closure response itself to decide how to retrieve its orders:

• If the response contains one or more entries in closures, 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 closures is empty, fetch orders directly with date_from and date_to set to that day instead.