Skip to main content

title: β€œUse Cases” description: β€œEnd-to-end integration flows for the Integrations API β€” built for venue owners and operators.” ---The Integrations API is scoped to your own venues. The use cases below cover the most common integration patterns, each with a complete request/response flow. ---## Use Case 1 β€” Custom Check-in System Goal: Build your own scanner or POS that checks in tickets without using the Fourvenues app.

Step 1 β€” List your events

Fetch the events to show the operator a picker:

Step 2 β€” Pre-load tickets for the selected event

Poll this endpoint every 5 minutes and cache the result locally. This avoids a round-trip on every scan:
Pass start_date equal to the created_at of the last ticket you received to only fetch new tickets on each poll, reducing response size significantly.

Step 3 β€” Fallback: look up by code at scan time

If a scanned code is not found in your local cache (ticket bought after the last poll), look it up directly:

Step 4 β€” Mark the ticket as checked in

Use the ticket _id to submit the check-in. enter: 1 marks as entered, enter: 0 reverts:
If the ticket has already been checked in (enter: 1), the API will return an error. Always check the current enter value before attempting a check-in.
Same flow works for Lists using /integrations/lists/{id}/checkin and for Passes using /integrations/passes/{id}/checkin. ---## Use Case 2 β€” Payments & Refunds Report Goal: Export all payments and refunds for your events into a finance system or spreadsheet.

Step 1 β€” List events in a date range

Save the _id of each event you want to report on.

Step 2 β€” Fetch payments for each event

amount is always expressed in cents (e.g. 2500 = €25.00).

Step 3 β€” Fetch refunds for each event

Step 4 β€” Fetch wallet movements (optional)

If your venues use the Fourvenues wallet, you can pull movement history:
---## Use Case 3 β€” Datawarehouse / Incremental Sync Goal: Keep an external database in sync with Fourvenues data, updated daily.

Initial load

On the first run, pull all events and for each event pull tickets, lists and bookings:
Convert the event’s date Unix timestamp to a YYYY-MM-DD string before using it as the date parameter for bookings:

Incremental updates (daily)

Use start_date / end_date together with date_field=updated_at to fetch only records that changed in the last 24 hours:
Upsert the returned records into your warehouse using _id as the primary key.