Reference
API Route Map
Dashboard and hosted API routes used by EMS LAN export, import, and audit history.
Use This Reference Carefully
Use this guide when event work may happen on local devices, offline files, or LAN-only tools instead of the live online dashboard. In this guide, API Route Map narrows that work to dashboard and hosted API routes used by EMS LAN export, import, and audit history. Because this is a reference page, read it as part of the EMS LAN learning path rather than as an isolated checklist.
EMS LAN keeps an event moving when internet access is unreliable, but it also creates a second place where event records can change. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.
What This Reference Collects
This page is for checking details. Use it to confirm names, routes, records, fields, or certification points before relying on memory. The intended readers are Support leads and Senior operators. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.
- Primary surface or service: /rego/events/manage/offline-snapshot?id=:eventId and /rego/events/manage/offline-snapshot-history?id=:eventId.
- Records or contracts involved: API routes and Dashboard routes.
- Main care point: Watch for losing track of which file, device, person, or import is trusted while attendee, staff, inventory, POS, or check-in records change offline.
- Proof worth keeping: event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note.
How To Find The Right Entry
- Search for the exact name or route: Begin by naming the EMS LAN situation, the owner, and the exact item involved in API Route Map.
- Read the surrounding note, not only the matching line: Use /rego/events/manage/offline-snapshot?id=:eventId and /rego/events/manage/offline-snapshot-history?id=:eventId to connect the words on the page to the screen, file, service route, or record that people actually use.
- Compare the reference with the live screen, file, or service evidence: Keep API routes and Dashboard routes in view so the work stays tied to the records or contracts it can affect.
- Save the evidence that proves the entry was checked: Before handing off, save proof such as event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note so the next lead can tell which file and device state are trusted.
Confirm The Reference Still Matches Reality
You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.
- Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
- Impact is understood: The operator can explain the effect on offline files, check-in access, staff rosters, inventory counts, POS totals, and import history.
- Proof is findable: The handoff points to evidence that the next lead can tell which file and device state are trusted.
End-to-end operator runbook
Use this numbered runbook when verifying a route or API issue.
- Step 1 - Identify the thing being verified. Identify whether the problem is dashboard route, export API, import API, or history API. This narrows troubleshooting.
- Step 2 - Translate the technical name into plain language. Confirm event ID, user role, file format, and visible error message. This gives support leads useful evidence.
- Step 3 - Match the route, file, or record to real workflow. Compare the route being used with the route map below. This catches wrong URLs.
- Step 4 - Collect enough evidence to avoid guessing. Stop if the route points at the wrong event or lacks the event ID. This prevents unsafe operations.
- Step 5 - Confirm implementation and docs agree. Capture route, status, action, and expected result in notes. This supports debugging.
- Step 6 - Send the result to the right owner. Return to the relevant runbook after route correctness is proven. This keeps operations ordered.
Dashboard routes
| Route | Purpose |
|---|---|
/rego/events/manage/offline-snapshot?id=:eventId | Export and import snapshot files. |
/rego/events/manage/offline-snapshot-history?id=:eventId | Review export and import audit history. |
/rego/events/manage/check-in?id=:eventId | Check-in operations. |
/rego/events/manage/inclusion-claim?id=:eventId | Inclusion fulfillment operations. |
/rego/events/manage/inventory-tracking?id=:eventId | Inventory operations. |
/rego/events/manage/point-of-sales?id=:eventId | POS operations. |
/rego/events/manage/staff-roster?id=:eventId | Roster operations. |
/rego/events/manage/live-shift-tracker?id=:eventId | Live shift operations. |
Hosted API routes
| API | Purpose |
|---|---|
/api/events/:eventId/check-in/offline-snapshot?format=zip | Export ZIP snapshot. |
/api/events/:eventId/check-in/offline-snapshot?format=gzip | Export GZIP JSON snapshot. |
/api/events/:eventId/check-in/offline-snapshot/import | Import returned snapshot. |
/api/events/:eventId/check-in/offline-snapshot/history | Load sync history. |