I was just wondering if anyone here has ever tried creating integrations between NPSP Salesforce and SuperSaas before? (I am using Make to build the integration).
I am trying to create a new, more accessible scheduling system for my volunteers to sign up to sessions and activities, and I like SuperSaas's functionalities... but I need to ensure the available slots/bookings on SuperSaas is aligned with my Shift and Session Attendance objects in Salesforce.
I have been able to create a SuperSaas to Salesforce integration (allowing volunteers to book a session inside SuperSaas) but I am struggling to create a Salesforce to SuperSaas integration for handling backoffice changes in SF that SuperSaas needs to reflect. The API is struggling to find the correct SuperSaas slots to amend. Any advice or suggestions much appreciated!
Hi Sam,
This is a common pain point with SuperSaaS integrations — the trick is to stop trying to "find" the matching slot from the Salesforce side, and instead capture and store the SuperSaaS identifiers at the point of creation so Salesforce always has a direct reference for later updates.
1. Root of the issue
When SuperSaaS creates a booking, the API response includes a Location header pointing to the newly created appointment, in the format:
https://www.supersaas.com/api/bookings/{appointment_id}.jsonThis appointment_id (along with the schedule_id) is what you need to reliably update or delete that specific booking later. If you're not capturing and storing this at creation time, any later Salesforce-to-SuperSaaS update has to guess/search for the matching slot based on date/time/name, which is fragile and exactly the kind of "can't find the correct slot" issue you're running into.
2. Recommended fix
When the SuperSaaS to Salesforce sync happens (the direction that's already working), make sure your Make scenario also:
- Captures the appointment_id and schedule_id returned by SuperSaaS
- Writes them into two fields on your Salesforce Session Attendance record (e.g., SuperSaaS_Appointment_Id__c and SuperSaaS_Schedule_Id__c)
3. Fixing the Salesforce to SuperSaaS direction
Once those Ids are stored, your outbound Make scenario (Salesforce to SuperSaaS) should:
- Trigger on changes to Shift/Session Attendance
- Use the stored SuperSaaS_Appointment_Id__c and SuperSaaS_Schedule_Id__c directly in the API call
- Call the Update Appointment endpoint directly:
PUT
https://www.supersaas.com/api/bookings/{appointment_id}.json?api_key=your_api_key- No searching/matching required, since you're referencing the exact record
4. If some records don't have a stored appointment_id yet (existing/legacy data)
For a one-time backfill, you can use SuperSaaS's range/list endpoint to pull all appointments for a given schedule_id within a date range, then match them back to Salesforce records based on date/time/volunteer name as a one-off reconciliation, and store the resulting appointment_id going forward. After that, you shouldn't need to search again.
5. For ongoing sync integrity
SuperSaaS also has a changes endpoint:
https://www.supersaas.com/api/changes/{schedule_id}.json?from={last_retrieval}&api_key=your_api_keyThis returns recently changed appointments since a given timestamp, which can be useful as a safety net to catch anything that falls out of sync between the two systems, on top of your Make-triggered real-time flow.
The core takeaway: don't search for the slot to update — store the appointment_id the moment the booking is created, and always update using that direct reference.
