Event Mutations
The event mutations allow you to enroll, bulk-enroll, and remove attendees on events within your Teachify school. These operations enable programmatic management of attendee lists — for example, importing a course’s student roster into a webinar event, or removing no-show users from an event.
Available Mutations
Section titled “Available Mutations”Manages event attendees:
enrollAttendeeToEvent- Enroll a single attendee into an event (idempotent).bulkEnrollAttendeesToEvent- Enroll multiple attendees in one round trip; supports atomic mode.removeAttendeeFromEvent- Remove a user’s enrollment from an event.
Important Behavior
Section titled “Important Behavior”Manual enrollments do not impact revenue. Both enroll paths (enrollAttendeeToEvent, bulkEnrollAttendeesToEvent) create a Payment record in the manual_enrolled state with amount: 0 regardless of ticket price. These payments do not count toward:
- Event/school revenue reports
- Ticket
soldItemsCount - Payout calculations
The Payment row exists only because Enrollment requires a payment association in the data model. Treat it as a comp seat, not a sale. If you need to record a paid ticket programmatically, use the public checkout flow instead.
removeAttendeeFromEvent destroys the enrollment row but leaves the underlying Payment untouched (no refund, no payment-state change). Refunds are a separate Payment-domain action.
Operational Notes
Section titled “Operational Notes”Orphan Payments accumulate on remove-then-re-enroll cycles
Section titled “Orphan Payments accumulate on remove-then-re-enroll cycles”Because removeAttendeeFromEvent preserves the Payment row for audit trail, every “remove then re-enroll the same user on the same event” cycle adds one extra manual_enrolled, amount=0 Payment for that user. They have no effect on revenue or sold counts (still amount: 0), but if you build an integration that reschedules attendees by removing-and-re-adding (instead of editing the Event itself), the user’s payment history will accumulate N+1 Payment rows after N reschedules. Use updateEvent (or the event’s reschedule flow) when possible to avoid this. If you must remove-and-re-add, surface the count in your monitoring so a runaway loop is visible.
Side effects survive atomic rollback
Section titled “Side effects survive atomic rollback”bulkEnrollAttendeesToEvent with atomic: true rolls back DB writes if any row fails, but already-enqueued background jobs and deliver_later mailers are not unwound. Use atomic mode for data-integrity guarantees, not for “no notifications fire”.
OAuth Scope
Section titled “OAuth Scope”All three mutations require the students:write scope (matching enrollStudentToConsultingMeeting / enrollStudentToCourse). The scope reflects that the operation adds a person, even though the resource is an event.
Error Handling
Section titled “Error Handling”The two enroll mutations return an errors field on the payload. removeAttendeeFromEvent does not — failures surface as standard GraphQL execution errors with an extensions.error.code (e.g. EVENT-001). See each mutation page for the codes it can return.
For more information about the Teachify Admin API, please refer to the API Overview.