The invitee-addition response reports aggregate added and skipped counts. A successful HTTP response is not a row-by-row acceptance report, and it does not send invitations by itself. Design the import workflow to preserve those distinctions.
Validate the input’s purpose
Identify whether contacts belong to participants, guardians or organizers. One guardian address can serve several minors, so a contact count is not a participant count. Keep the authoritative attendee roster separate from the list of messaging destinations.
The endpoint accepts an invitees array of 1 through 1000 entries. Each entry can contain email and phone under the declared limits. Use events:manage and inspect the invitee schema before constructing the request.
POST /v1/events/{id}/invitees
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{"invitees":[{"email":"participant@example.com"}]}
The address is a placeholder for a controlled example, not a real recipient.
Record aggregate outcomes honestly
The API skips entries with neither contact field and contacts already invited to that event under its documented behavior. Preserve the input batch reference and returned counts in your own application. Do not fabricate a per-row “accepted” status when the response does not supply one.
A result such as added: 8 and skipped: 2 means the batch needs reconciliation if the operator expected ten new contacts. It does not identify which two entries were skipped. Use your retained source data and authorized workflow to investigate without assuming every skip is an error.
Keep sending as a separate decision
Adding contacts and sending the initial event invitations are separate API actions. Give the operator a review point before the send. Verify the event, template and controlled recipient experience first.
The event retrieval response does not hand back invitee email, phone or personal invite tokens. Do not design your import review around reconstructing the original uploaded contact list from that response. Maintain the necessary mapping in your own appropriately protected system.
Test repeated and partial batches
Test an initial batch, the same contacts again and a batch containing an empty entry. Confirm your interface reports the actual aggregate result and does not claim delivery. For an uncertain response, inspect the situation before blindly repeating both addition and sending.
Pair this guide with individual reminders and the operator pre-send checklist. Keep contact data out of generic application logs while retaining request identifiers for diagnosis.