An enrollment is a workshop, series or teacher training — bought as a whole, not dropped into.
Publishing one calls Mindbody's addenrollmentschedule. To create a recurring drop-in
class instead, use Studio Schedule (Admin); to put a
student into an enrollment that already exists, that is
POST /v1/events/{event_id}/enrollments.
Publish an enrollment
This is a real write. Mindbody has no dry-run mode for enrollments, so
publishing creates one on the public schedule. Removing it afterwards is a manual job in
the Mindbody back office.
Editing an enrollment.
Only the fields you change are sent. Mindbody does not report this enrollment's booking
status, pay rate, room, days or capacity, so those five start at
leave unchanged — set one only if you mean to change it.
Suggestions are the class types already used by
enrollments at this studio, so they are known to be enrollment types. A drop-in class
type here produces a workshop Mindbody will not sell tickets for.
Optional.
Mindbody pay rate slot. The names live in the back office and no
API exposes them, so these are numbered only.
Required — an enrollment is a bounded run.
Sets Mindbody's total capacity
and its separate online cap to the same number. That differs from the
class form, where the online cap is left at 0 — an enrollment needs to be bookable
online to sell.
0 means no waitlist, and is sent as 0
rather than dropped.
Mindbody product ids allowed to pay for a place, comma-separated.
Sent as an array of strings. Leave empty to let Mindbody's own defaults apply.
Two things cannot be changed once an enrollment exists, because
Mindbody's update endpoint does not take them: the pricing options
(absent from its request body) and the class type (present but
documented as "overridden if sent", so it would be a silent no-op). Both are changed
in the Mindbody back office. See api-datastream docs/VERIFY.md §40.