Use cases

Scan2Check turns an Android phone into a scanner for your own checks. The app scans a code, sends it to your API, and shows a full-screen green or red answer with your message. What "valid" means is up to your API, which is why the same app fits very different jobs.

Every case below follows the same pattern:

1. You set up an endpoint that knows the rules (valid tickets, expected parcels, who may borrow what).
2. You make a settings QR in the configurator and scan it on each phone.
3. Staff scan codes. Your API answers each scan with green or red and a short reason.

The cases

Use case	Green means	Red means
Event ticket check-in	Come in	Already used, wrong day, unknown ticket
Vouchers and entitlements	Redeemed now	Already redeemed, expired
Attendance	Presence recorded	Wrong session, already recorded
Equipment and tool checkout	Checked out / returned	Already out, reserved, in repair
Parcel and mailroom handover	Hand it over	Wrong recipient, already collected
Receiving against a delivery	Item expected, recorded	Not on this delivery
Lot and recall check	Not on the blocked list	Recalled or expired: do not use
Inspection and patrol rounds	Checkpoint logged	Wrong route, out of order

More ideas that follow the same pattern: an order pickup counter (red = not ready yet), coat check or rental return, lab sample hand-offs between stations, or checking that a part belongs at this workstation.

Building blocks you will use

• deviceId is sent with every scan and stays the same for one app installation. Map it to a gate, counter or station in your API.
• The status message is yours. "Already used at 18:42, gate B" is far more useful than a plain red screen.
• autoScanTimeout reopens the scanner by itself, which keeps a queue moving.
• Custom form asks the operator a pick-one question with every scan (for example Checkout / Return). Your API can also ask only when it needs to, by replying "status": "missingData" with a form; the app then shows the form and sends the scan again with the answer.
• symbols limits which barcode types the scanner accepts, so staff don't scan the wrong label by accident.
• backgroundColor in a response colours the result screen, for example a separate colour for VIP tickets.

Know the limits before you start

• You build and host the API. Scan2Check has no backend, no dashboard and no stored data of its own. Green and red are exactly what your API answered, nothing more.
• Every scan needs a connection. Nothing is queued offline. When the network fails the operator sees a red screen with the network error, so plan a manual fallback for entrances.
• A red screen is not always a "no". It can also be a timeout or a server error. Make your messages say which, so staff don't turn people away because the Wi-Fi dropped.
• A timeout doesn't mean nothing was recorded. Your API may have saved the scan just before the answer was lost. Make repeated scans safe: a second scan of the same code by the same device a few seconds later should not count twice.
• Forms offer pick-one choices only. No typed numbers, notes, photos or signatures.
• The settings QR works like a password. It holds your API URL and any headers, including an API key. Share it only with your staff, check every code on the server, and change the key if the QR leaks.
• deviceId identifies an installation, not a person. It changes if the app is reinstalled.
• A retail barcode (EAN) names a product, not one item. Two identical drills have the same EAN. To track individual items, print your own QR or Code 128 labels.