Reconcile check-ins using the organization’s calendar day

The check-in list’s day parameter refers to a calendar day in the organization’s timezone. It is not a UTC date filter. A worker running in another timezone can otherwise ask for the wrong day near midnight and produce a misleading end-of-day report.

Choose the operating date explicitly

Have the application select the intended organization date, or derive it from the configured organization timezone. Do not use the server’s local date or toISOString().slice(0, 10) as a universal substitute.

For an explicit date and optional location, the read request is:

GET /v1/checkins?day=2026-09-11&locationId=LOCATION_ID
Authorization: Bearer YOUR_API_KEY

Replace the location placeholder with a real authorized UUID, or omit that filter to use the documented organization-wide behavior. The scope is checkins:read.

Keep date calculation at the application boundary

An illustrative JavaScript helper can derive a calendar date from a known timezone:

function calendarDate(instant, timeZone) {
  const parts = new Intl.DateTimeFormat('en-US', {
    timeZone, year: 'numeric', month: '2-digit', day: '2-digit'
  }).formatToParts(instant);
  const value = type => parts.find(part => part.type === type).value;
  return `${value('year')}-${value('month')}-${value('day')}`;
}

Supply the actual organization timezone from your application configuration. The example does not infer it from the browser or claim a separate organization-settings endpoint.

Interpret the response as an arrival list

Use the response’s timezone context and the endpoint’s declared fields. Check-in rows include participant names for the operational roster, but do not contain the full waiver answers. Do not fetch every full record merely to count arrivals unless the application genuinely needs those details.

Repeat check-ins are separate arrivals. A count of rows is not automatically a count of unique participants. State the measure clearly in any internal report and keep deduplication decisions separate from the API’s event history.

Test date boundaries

Test just before and after midnight in the organization’s timezone, with a worker configured elsewhere. Include a daylight-saving transition where applicable and an explicitly selected historical day. Verify that the displayed date matches the requested operating day.

Use the check-in list reference for the exact response and end-of-day operations guide for the staff handoff. Do not present an incomplete date window as proof that nobody arrived.