Repeating POST /v1/checkins can create another arrival. The API treats a deliberate second check-in as a separate row, audit entry and event. A network retry therefore needs more care than simply sending the same body until a successful response appears.
Define the user’s intended action
Distinguish one arrival attempt from a deliberate later visit by the same person. Give the local command its own application identifier and track its state. That identifier belongs to your system; the current check-in request schema does not declare an idempotencyKey field.
Disable repeated button activation while the request is pending. This helps with double clicks but does not solve response loss or a worker restart by itself.
POST /v1/checkins
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{"waiverId":"WAIVER_ID","method":"search"}
Replace the UUID placeholder and use checkins:write. Include a valid locationId only when appropriate. See create check-in.
Treat a timeout as uncertainty
A timeout does not prove the server rejected the command. It may have committed the arrival before the connection failed. Keep the local state as uncertain and reconcile using the appropriate arrival list and operating-day context.
Do not assume any matching recent arrival conclusively belongs to your request. A guest can legitimately return, and another authorized operator may have checked them in. Use the available identifiers and context, and require an operator decision when the evidence remains ambiguous.
Keep retries separate from repeat visits
An illustrative command lifecycle is:
prepared -> sending -> confirmed
-> uncertain -> reconcile -> confirmed or needs review
-> rejected -> show actionable error
A deliberate repeat visit starts a new command. Do not make a permanent “one check-in per waiver” rule if the operation needs repeat arrivals. Conversely, do not use a broad automatic retry policy that turns every uncertain response into another arrival.
Test failure timing
Simulate losing the response after the server-side action in a controlled environment. Also test a double click, a restarted client and two legitimate visits. Verify that downstream processing handles separate checkin.created events without conflating delivery retries with distinct arrivals.
The webhook deduplication guide addresses repeated delivery. It does not erase an arrival created by repeating the API mutation. Keep those two forms of duplication separate in code and diagnostics.