The whole-event send and the individual reminder are different actions. The initial event send queues invitations for invitees who have never been messaged. A follow-up to someone already messaged uses the invitee resend endpoint. Make that difference visible in your application rather than hiding both behind one generic Send button.
Confirm the invitee and current task
Identify the intended event and invitee from the authorized workflow. Before reminding, check whether the person still needs to act and whether the booking or contact role changed. A family contact can relate to several participants, so do not infer the unresolved child from the email address alone.
Do not reconstruct personal invitation tokens from predictable identifiers. Use the supported API operation and keep the original contact mapping in the appropriately protected system that owns it.
Request one reminder deliberately
The route needs both events:manage and messages:send:
POST /v1/invitees/{id}/resend
Authorization: Bearer YOUR_API_KEY
The response acknowledges queued work. It does not prove delivery or signing. The documented limit is 60 calls per minute per key; apply the current rate-limit guidance rather than issuing an unbounded loop.
Guard your own repeat actions
Record the local reminder request and disable repeat activation while it is pending. An uncertain response does not establish that nothing was queued. Do not assume the submission idempotency field used for waivers applies to this endpoint.
If your application schedules or batches follow-ups, that scheduling is your application’s behavior. Give it a clear owner, suppression rules and an appropriate review of communication requirements. The endpoint alone is not a complete reminder policy.
Handle lifecycle changes
A cancelled invitation cannot be reminded through the documented cancellation behavior, and event closure stops further invitations. Refresh stale interface state when the API rejects an action rather than repeatedly submitting the same request.
Test a first invitation, an already-messaged invitee, a cancelled invitee and a closed event. Verify the application labels the outcomes accurately. Keep queue acceptance, delivery information and completed signing as separate states in both the screen and the audit notes.
Use the missing-signature message guide for the operational purpose and send-event invitations for the initial whole-event action.