Make.com test project · built on sample data

CourseSync

Your six step scenario, built and running end to end on a synthetic student. When a course is purchased in MindBody, the automation fills the missing sessions, updates HubSpot, logs the sale, alerts the VA when needed, and sends the confirmation.

Built for the specification you posted publicly on Make's Hire a Pro board. I have not shipped a StartIntegrate MindBody build for a prior client, so rather than describe work you cannot verify, I built your test project and put it here.

Why a working build instead of a portfolio link

You asked whether respondents have built with the StartIntegrate / MAXMEL MindBody connector, and how they would check existing class enrollments before adding new ones. The most honest answer I can give is the build itself. Everything below runs on invented sample data. There are no live keys and no calls to your MindBody or HubSpot account. The two places this design earns its keep are the purchase trigger and the enrollment check, and both are called out inline.

The sample scenario

A student who already attended the first two sessions of a five session course buys the full course. The automation must add her to sessions three, four, and five only, and must not re-add the two she already has.

Student
Maya Chen
MindBody client
100024816
Course
Study Skills Intensive (5 sessions)
Already enrolled
Sessions 1 and 2
Purchased
All 5 sessions
Should be added to
Sessions 3, 4, 5
Trigger

A purchase in MindBody starts the scenario

gateway:CustomWebHook · receives clientSale.created

Connector boundary The StartIntegrate / MAXMEL connector cannot trigger on a purchase. Its only triggers are Watch New Clients and Watch Updated Clients, and it has no sale event. So a purchase is caught by subscribing to the MindBody Webhooks API event clientSale.created and pointing it at a Make custom webhook. Knowing this boundary is the difference between dragging modules and understanding the MindBody API.

The webhook delivers the documented envelope. Before the bundle is trusted, the scenario verifies the X-Mindbody-Signature header (HMAC-SHA256 of the raw body with the subscription's messageSignatureKey).

// clientSale.created (sample payload, verified against the documented schema) { "messageId": "ASReXAmM8JmZfLBb2M2zBcp7Sm5aQ", "eventId": "clientSale.created", "eventSchemaVersion": 1, "eventInstanceOriginationDateTime": "2026-07-03T14:12:05Z", "eventData": { "siteId": 123456, "clientId": "100024816", "clientUniqueId": 100024816, "saleId": 987654, "items": [{ "name": "Study Skills Intensive (5 sessions)", "amountPaid": 495.00 }] } } // header X-Mindbody-Signature: sha256=6f1e... verified before use
1

Check existing enrollments, add the missing sessions only

http GET /client/clientvisits then Router filter then http POST /class/addclienttoclass

Connector boundary The connector can add a client to a class, but it has no module that returns a client's existing visits. So the scenario bridges the gap with a raw Make an API Call to GET /public/v6/client/clientvisits, then a Router compares the required session ClassIds against the ones the student already has. Only the sessions she is not already in are sent to POST /class/addclienttoclass.
GET https://api.mindbodyonline.com/public/v6/client/clientvisits?clientId=100024816

Returns the ClassIds the student already holds: [30401, 30402]. The Router then evaluates each of the course's five sessions:

ClassId 30403
Session 3 of 5
missing, added
ClassId 30404
Session 4 of 5
missing, added
ClassId 30405
Session 5 of 5
missing, added

Grey sessions are skipped because the student already has them. Green sessions are the three that were missing and get added. The filter that makes this safe is a single condition: the existing set does not contain this session's ClassId.

// Router filter on the Add-to-Class module (only the missing pass) { "a": "{{join(2.data.Visits[].ClassId; \",\")}}", // existing: 30401,30402 "b": "{{4.value}}", // the session under test "o": "text:notcontain" }
Result: 2 sessions skipped, 3 sessions added. Sessions 1 and 2 are never re-added.
2

Update a HubSpot contact property

hubspotcrm:createOrUpdateAContact

The contact gets automation owned properties describing the enrollment. These are matched to the contact by email and written as a set.

{ "coursesync_enrollment_status": "enrolled_all_sessions", "coursesync_course_name": "Study Skills Intensive (5 sessions)", "coursesync_sessions_added": "3", "coursesync_last_sync": "2026-07-03T14:12:07Z" }
Coexists with Appiant Every property this scenario writes is prefixed coursesync_. It never writes email, first name, last name, or the MindBody identity fields your Appiant sync owns. Email is used only to find the contact, not to overwrite it. That keeps this automation and the existing MindBody to HubSpot sync out of each other's way.
3

Add the contact to the correct HubSpot segment

hubspotcrm:makeApiCall · Lists v3 memberships/add

The contact record id from the previous step is added to the correct manual list.

PUT /crm/v3/lists/{listId}/memberships/add   body: ["102938"]

This uses the current Lists v3 endpoint rather than the native Add to List module, which HubSpot deprecated in September 2025. Using the supported endpoint is the reliable choice going forward.

4

Append a row to a Google Sheet

google-sheets:addRow

One audit row per purchase, so there is a plain record outside the two systems.

// row appended to the Enrollments tab Timestamp 2026-07-03 14:12:07 Student Maya Chen Course Study Skills Intensive (5 sessions) Sessions added 3 of 5 (sessions 3, 4, 5) Sale id 987654
5

Alert the VA, only when a follow up is needed

google-email:ActionSendEmail · with a filter

This step is conditional. The VA is alerted only when the student already had visits before this purchase, which means she joined mid course and needs the catch up packet and a short call. A clean from scratch enrollment does not page the VA.

// filter on the VA alert (fires only for a mid-course join) { "a": "{{length(2.data.Visits)}}", "b": "0", "o": "number:greater" } // existing visits = 2 -> 2 > 0 -> VA alerted

In this sample the student had two prior sessions, so the alert fires. The recipient and channel are easy to point at whatever the VA actually uses, including a Slack message or a Trainual task.

6

Send the confirmation from a HubSpot template

hubspotcrm:makeApiCall · Single-Send API

The confirmation goes out from your HubSpot marketing email template so the wording stays in your control. This route always runs.

POST /marketing/v4/email/single-send   { emailId, message.to, customProperties }

Course name and the count of sessions added merge into the template tokens, so the same template serves every enrollment.

Take the build with you

The importable Make blueprint and a full module by module runbook. The blueprint's MindBody steps use generic HTTP and a custom webhook so it imports into any Make account without the StartIntegrate connector installed. Each module is labelled where the native connector action swaps in once it is present.

Make blueprint
The six step scenario, importable into any Make account.
coursesync.blueprint.json
Build documentation
Module by module runbook, field mappings, and error handling. This is what full documentation with every build looks like.
build-documentation.html
Sample data
The invented student, course, and payloads this page renders.
synthetic-scenario.json