Offline scanning: the exact contract

The short version

Scan with no signal and nothing about your pace changes. Scans queue on the phone and replay to the server in the order you took them when connectivity returns. The queue survives airplane mode, a dead zone, or a basement — you can verify this on the free plan in ten minutes.

What an offline scan carries

Each queued scan holds exactly what a live one does at the moment of capture:

What it does not carry: names, categories, notes or photos. Those are enrichments you add once the scan exists — offline capture is about not losing the count, not about doing data entry in a dead zone.

Capture time is the time that counts

When the queue replays, each scan is recorded with its capture time, not its sync time. If you counted the mezzanine at 9:40 and the phone reconnected at 11:15, the record says 9:40.

Replay is in order, and re-scans merge

The queue drains serially, in insertion order. A barcode that already exists in your account gets its scan count raised on the existing record — the database performs that increment under its own row lock, so a colleague scanning the same shelf live while your queue replays cannot cause a lost update or a duplicate row.

When the server says no

If the server refuses a queued scan, it is dropped from the queue — and you are told how many were refused and why. Nothing disappears silently. The honest phrasing of the guarantee is exactly that: nothing is lost without you being told, which is the guarantee that actually matters at reconciliation time.

When does the queue drain?

When you open the app, when it returns to the foreground, and when you tap the queued count. In practice that means walking out of the dead zone and glancing at your phone is enough — and if you want it to drain right now, the tap is there.