Reservanto Make integrationAutomate Reservanto with Make.

As its name says, this module settles a booking with credit the customer already holds in Reservanto, so the visit counts as paid without asking for a card at the desk.

Judging by its name, this one pays for a booking out of a pass, the prepaid set of sessions a gym or a yoga studio sells to its regulars.

Going by its label, it covers a booking with a service substitution, a replacement session the customer is owed, instead of charging them again for the visit.

The name is plain: it cancels an existing Reservanto booking from inside your scenario, and the slot opens up again without anyone logging in to Reservanto.

Its name points to one job: accepting a booking that waits for your approval, so the client gets a firm slot without staff clicking through requests one by one.

It fetches the bookings tied to one customer, which gives the next modules a clear view of what that person has on the books with you.

This module pulls the bookings that fall inside a date range you choose, a solid base for a planning sheet or a report built in another app.

It turns down a booking request, the counterpart of Confirm a Booking, and spares your team from refusing requests by hand inside Reservanto.

Flagging a missed appointment as a no-show is its role, going by the name, so your history shows clearly which clients did not turn up.

Where the list module returns everything, this one zooms in on a single resource and hands its details to the next step of the scenario.

It asks Reservanto when a bookable resource, such as a room, a court or a therapist, is free, so your scenario can offer slots that really exist.

This returns every bookable resource on your account, the list you reach for when you do not know a resource ID by heart.

It reads the details of one service you sell, a haircut, a massage or a private lesson, straight from your Reservanto catalog.

It lists the services set up in your Reservanto account, in other words the menu your clients choose from when they book.

Filed under Classes in the doc, it creates a booking, which suggests a seat in a group session rather than a private appointment.

It returns the details of one class, the group session itself, so later modules can quote its name in a message or a sheet.

This fetches one appointment of a class, which reads like a single dated session of a class that runs more than once.

It reads a course from Reservanto (the Course group of the doc) and passes its details to the rest of the scenario.

Listed in the Course group, it returns the events linked to one customer, a quick way to see what that person has signed up for.

It adds a new customer record to Reservanto, so people who reach you through another channel exist in the system before they book.

This module returns a customer's details, which by its name sounds like a fuller view than the basic record other modules give.

It updates an existing customer, so a new phone number or email address collected elsewhere reaches Reservanto without any retyping.

Give it a customer reference and it hands back that person's record, ready for the next module to use in a message or a sheet.

It returns your customers as a list, each one as a separate bundle that the following modules process one after the other.

It writes a note on a customer's file, or rewrites the one already there, so context gathered elsewhere sits right next to their bookings.

The only search module of the app, it looks up customers and returns zero, one or several matches, each as a bundle.

It adjusts how much of a pass a customer has used, which keeps the remaining sessions accurate when a visit is logged outside Reservanto.

As the name suggests, it attempts to spend a customer's credit, which tells your scenario whether the balance is enough before anything else happens.

It tries to use a customer's pass and reports the outcome, the pass-side twin of Try Use a Customer Credit.

It creates a booking of the kind grouped under EMS Like in the doc, a booking type of its own that the doc does not explain further.

It changes a booking made through the EMS Like modules, so a new time or detail coming from another tool updates it in place.

It reads a single event from Reservanto and passes its details on, handy when another app only knows the event by its reference.

This one returns your events, one bundle per event, which makes it the starting point for publishing or syncing them somewhere else.

It narrows the event list down to one customer, giving you only the events that person has registered for.

It fetches one location of your business, useful when you run several sites and every message must show the right address.

This lists all the locations set up in Reservanto, each one as its own bundle, so you see every branch Make can work with.

It returns information about your own Reservanto account as a merchant, that is, the business behind all the bookings.

It books a private appointment, the one-to-one kind grouped apart in the doc, for a single client rather than a group class.

It checks a proposed start time for a private appointment and returns what Reservanto says about that slot.

It returns the possible start times for a private appointment, each as a bundle, so you can offer the client real choices.

Judging by its name, it creates free time in a one-to-one calendar, which reads like time off: a period clients cannot book because you already know you will be away.

It returns the passes your business sells, one bundle per pass, so later modules know which pass to work with instead of guessing a reference.

As its name says, it attaches a pass to a customer in Reservanto, so a sale made somewhere else lands on the right record without anyone retyping it.

It reads the customer segments defined in your Reservanto account, so a newsletter tool or a CRM can reuse the groups your team already works with.

Going by its name, it tells you which service substitutions one customer still holds, so your scenario knows whether a replacement session can cover the booking before charging anything.

It returns your Reservanto vouchers, one bundle per voucher, ready to be reported on or passed to another tool.

Judging by its name, it validates a voucher before anyone accepts it, and your scenario picks the next step from the answer. The name points to a check, not a payment.

As its name says, it pays for a booking with a voucher, so the visit is settled without a card or a manual entry. The booking and the voucher come from earlier modules.

Going by its name, it refunds the voucher payment on a booking, so the client keeps the voucher value when a visit does not happen. It is the counterpart of Pay with Voucher for Booking.

It reads the working hours set in Reservanto for a period, so your opening times stay defined in one place and other tools reuse them.

It calls any endpoint of the Reservanto API from your scenario, with the same connection as the other modules. It covers what the ready-made modules on this page do not.