Sign in
Start free7-day free trial
Live API contract
Events and arrivals

Close an event while preserving its record trail

Stop future signing and invitations while keeping the documented read-only roster and existing waivers intact.

Event closure affects future use of that event’s signing routes. It does not void the waivers already signed. Make the consequences clear before offering a close action, especially when an organizer still has pending guests or has rescheduled the booking.

Confirm the intended scope

Use the event ID, name and current status to ensure the operator is closing the right event. A single cancelled participant usually calls for an invitation-level action, not closure of the entire group.

Check outstanding communication and any future use of the event’s public link. An integration should not silently close an event merely because its local end-time display passed without considering the organization’s workflow.

Apply the close action

The request requires events:manage:

POST /v1/events/{id}/close
Authorization: Bearer YOUR_API_KEY

Under the documented behavior, the shared public signing link and personal invitee links stop accepting signatures. Further invitations cannot be sent. The roster link remains available read-only, and waivers already signed remain unaffected.

Do not describe the result as deleting the event’s participant records. Also do not invent a reopen endpoint or assume the generic event PATCH can reverse closure; follow only the lifecycle operations in the current contract.

Update the interface and external workflow

Remove send controls or explain their unavailable state when the event is closed. Keep historical roster access limited to the appropriate audience. A working read-only link still needs careful handling and should not be mistaken for a public marketing page.

Notify the operational owner when distributed signing links are no longer intended for use. Physical signs, booking messages and partner instructions can outlive the event’s active state.

Test future access and history separately

Use a controlled event with a sample signed record and an uncompleted invitation. After closing, confirm the expected signing-link behavior, the retained signed record and the read-only roster. Check that your interface does not keep offering an initial send based on stale cached state.

For a lost response, retrieve the event before choosing another action. Record the request identifier and observed status. Pair this implementation with rescheduled-group handling so staff understand when a schedule change requires a broader review rather than a premature close.