CourseSync build documentation

Scope and honesty

This documents the blueprint built for the specification posted publicly on Make's Hire a Pro board, then updated to match the revised spec. It runs on invented sample data. No prior MindBody or StartIntegrate client build is claimed. The MindBody steps are written with generic HTTP so the blueprint imports into any Make account without the connector installed; each connector boundary notes where the native StartIntegrate action swaps in. In the revised design, MindBody is read only: the scenario checks whether a session was booked but never books, adds, or changes anything in MindBody.

Contents

1. Connections and prerequisites

Values to supply before the scenario runs: the MindBody SiteId, the Google spreadsheet id, the HubSpot confirmation template id, the admin recipient, the VA recipient (a placeholder pending the hire), and the override property name (manual_enrollment_skip_automation).

2. Trigger setup and signature verification

The StartIntegrate connector has no purchase trigger, so the scenario is fired by a MindBody webhook, not a connector poll.

1. In the MindBody Webhooks API, create a subscription for the event clientSale.created. Point its delivery URL at this scenario's custom webhook address.
2. MindBody returns a messageSignatureKey for the subscription. Store it in the scenario.
3. On every delivery, compute HMAC-SHA256 over the raw request body using that key and compare, as sha256=<hash>, against the X-Mindbody-Signature header. Reject the bundle if it does not match. A plain custom webhook does not verify the signature by itself, so a small verification shim gates on it in production.

The delivered envelope is { messageId, eventId, eventSchemaVersion, eventInstanceOriginationDateTime, eventData }. eventSchemaVersion is 1. eventData carries siteId, clientId, saleId, and the purchased items. Verified against the real MindBody sandbox: the live event may not carry the client email, so a GET /client/clients on the clientId resolves it before the HubSpot steps when it is absent.

3. Module by module reference (20 modules)

Nine modules run before a three-route router; the router then fans to the zero-booking, flag, and proceed paths. Routes are evaluated by filters, so exactly one path runs per bundle.

Module numbers match the reference table below. The gates named on each route are the filters that select it.

4. The parts that carry the build

The wait, then a read-only booking check

Parents book their sessions a few minutes after buying, so the scenario waits about ten minutes before it looks (modules 4 and 5, two chained Sleeps, because a single Sleep maxes at 300 seconds). Module 6 then reads the client's forward visit window and asks a tolerant question: is any session booked for this course and week, not is session one booked, because parents book out of order. It keeps only future bookings whose AppointmentStatus is Booked, and carries that session's date forward. Two real-sandbox traps are folded into the filter: the status field is AppointmentStatus, not Status, and Missed is TRUE on future bookings, so booked is never inferred from Missed. When nothing is booked, that is a normal outcome, not an error, and the scenario takes the parent-email path.

Deduplication before any write

A parent can book several sessions of one course in one sitting, and each booking can fire the flow. Module 15 reads the target segment's current members, and module 16 only proceeds when the contact is not already in it. Static (manual or snapshot) list membership through the v3 Lists API is used precisely because it is immediate rather than lag prone. This is what makes a repeat delivery of the same purchase a safe no-op.

The date-range segment match

The segment names are inconsistent today, so the match is the real problem. Module 7 pulls the lists index; module 8 keeps the list whose parsed date range contains the booked session's date and whose tokens match the course level and delivery. For a session on 2026-07-13 at HS level, that is the list named "7/6-7/17/2026 HS Class" (its range contains 7/13 and it carries the HS token); a list ending 6/13 is out, and a list that contains 7/13 but reads MS is out on the level token. Zero or more than one match takes the flag path.

5. Flag, do not fail

The scenario never guesses a segment. When the resolver returns zero or more than one candidate list, module 13 emails the admin with the student, course, session date, and the match count, and module 14 stops the scenario. No records are changed until a human resolves it. The same posture governs the zero-booking path: the scenario asks the parent for dates and stops rather than inventing an enrollment. A person deciding beats a wrong write, and every stop is explicit rather than a silent failure.

6. Appiant coexistence

Your existing Appiant integration keeps MindBody and HubSpot contact records in sync. This scenario must not fight it. Two rules enforce that:

• Every property written to HubSpot is prefixed coursesync_. The scenario never writes email, first name, last name, phone, lifecycle stage, or the MindBody identity fields Appiant owns.
• Email is used only as the lookup key to find the existing contact, never as a value to overwrite.

The result is a clean separation. Appiant owns identity. This scenario owns the enrollment state, and the two never write the same field.

7. What the demo simplifies (production notes)

This build is deliberately a single importable scenario. Two choices are worth calling out, with the higher-volume alternative for each, plus what the real MindBody sandbox says about production routing.

The delay: Sleep now, data store plus scheduler later

The ten-minute wait uses two chained Sleep modules, which keeps everything in one scenario and easy to import. For higher volume the recommended pattern is a Make data store plus a scheduled second scenario: the webhook writes a pending row carrying a process-after time, and a scheduler picks it up once the wait has passed. That frees the operation slot during the wait and scales more cleanly.

The segment resolver: hosted, or fully in-Make

Module 8 points at a small resolver in code because parsing inconsistent list names (different word order, optional course tokens, mixed date formats) is fragile inside Make formulas. In production you point it at your hosted resolver. If you want no external code at all, a fully self-contained in-Make alternative works: pull the lists index, run an Iterator over the lists, apply a per-list containment filter (parse each list's date range and keep it only if it contains the session date and the level and delivery tokens match), and collect the survivors with an Array aggregator. Exactly one survivor proceeds; zero or more than one takes the flag path.

Real MindBody findings that shape production

• Multi-item sales arrive as one trigger with several items. A parent buying several courses at once produces a single clientSale.created carrying several items. This build processes the first item; production should wrap the flow in an Iterator over items and fan out per course.
• Route on the pricing-option id, not the name. Each purchased item carries a stable pricing-option Id, so the routing table should key on that Id rather than parse the course name. This build keys on the name as a self-contained fallback. Open question to confirm with you: does each of the twelve course-and-delivery combinations have its own distinct pricing-option Id?
• Booking status is AppointmentStatus, not Status, and Missed is TRUE on future bookings, so a booked session is counted as AppointmentStatus = Booked, never via Missed.

8. Error handling and edge cases

9. Importing and what to supply

1. In Make, create a new scenario and import coursesync.blueprint.json.
2. Attach connections: MindBody credentials on the HTTP modules, HubSpot (with the crm.lists scopes), Google Sheets, and the send connection.
3. Supply the values: SiteId, the HubSpot confirmation template id, the spreadsheet id, the admin recipient, the VA recipient, and point module 8 at your resolver (or replace it with the in-Make alternative in section 7).
4. Configure the custom webhook and the MindBody clientSale.created subscription, then store the signature key.
5. Optional: once the StartIntegrate connector is installed in the account, swap the MindBody HTTP calls for the native actions where one exists. The visits read stays a Make an API Call because the connector has no get-visits action.
6. Run once with a test sale and confirm the path end to end: the override read, the wait, the booking check, the dedup read, exactly one segment matched, the course appended to courses-taken, the list membership added, the audit row appended with MB Enrollment, the VA alerted for the summer in-person Study Skills case, and the draft confirmation queued for review.