A check-in records an arrival against a waiver. It does not replace the signed document, confirm a person's training or make every admission decision for your team. Build the screen around those separate responsibilities.
Find the candidate
Use check-in candidate search to find the relevant record. Search with the supported parameters and let an authorized operator confirm the person before creating the arrival.
Keep the result understandable when names repeat. Show enough context to choose correctly, but do not expose sensitive answers on a queue-facing screen. Debounce search input because candidate search uses a 60-per-minute limit.
Read status before acting
The API can record a check-in for an expired waiver and return an expired status. Your application must decide how that status affects admission under the organization's procedure. Do not present a successful HTTP response as “all requirements met.”
A voided waiver produces a conflict. Explain the state and the next operational step to staff instead of retrying the same mutation unchanged.
Create one arrival intentionally
Call create check-in after confirming the intended record. Repeating this request can create another arrival. The idempotency behavior documented for waiver submission does not automatically apply here.
Disable repeat activation while a request is pending. If the response is lost, reconcile the arrival list before making another attempt. Keep a local operation identifier so your own interface can distinguish a retry from a deliberate second visit.
Use the organization's day
List check-ins for the relevant day. Its day filter uses the organization's calendar day, and the response echoes timezone information. Do not silently substitute the server's UTC date at midnight.
Test an expired record, a voided record, two arrivals by the same person and a visit near a date boundary. The resulting interface should show what happened and what staff still need to decide.