SuperHote
ERPConnect AI agents to SuperHote, a French short-term and vacation rental management platform. Agents read availability across a host's properties and create reservations and bookings, with no update or cancel exposed, so each write is final.
What This Integration Enables
SuperHote is a French short term and vacation rental management platform, and this connector is deliberately small. Its public REST API covers availability and reservation creation, and that is what is here: Get Availabilities, Create Booking and Create Reservation. Three actions is not a gap to apologise for, it is a statement about where the boundary sits. The calendar, the channel connections, the cleaning schedule and the guest messaging stay in SuperHote. What crosses the boundary is the single question a host gets asked all day, can I have this place on these dates, and the act of saying yes.
The interesting design decision is that the vendor ships two ways to say yes. Create Booking creates a reservation and requires that the price you supply matches the price SuperHote computes for the stay, rejecting the request outright if it does not. Create Reservation creates a reservation using the price you supply without validating it against SuperHote's computed price. Same outcome, one guard removed on purpose. That pair is the whole design of any flow built here. Create Booking is the safe default because the platform itself checks the arithmetic, so a stale rate, a mis-parsed date range or a party size that changes the nightly price all fail loudly instead of quietly booking a stay at the wrong money. Create Reservation exists because real hosting has legitimate exceptions: a negotiated rate for a returning guest, a compensated stay after a problem, a length of stay discount agreed in a message thread. It is the right action for those cases and the wrong action to reach for by default.
Authentication reflects the same portfolio shape. The account level API key is the connection credential and is configured once. The property key belongs to an individual rental and is supplied per action, which means one connection serves every property on the account rather than one connection per apartment. Both are sent in the JSON request body, as the API requires. Dates use the YYYY-MM-DD format, and both create actions require the property key, the check in and check out dates, the guest first and last name, the phone and a two letter ISO country code.
On events, be plain about it. This connector ships no triggers, and SuperHote does not publicly document a webhook or trigger API, so there is nothing here to register and nothing here creates a FlowRunner trigger. There is also no read of existing reservations and no action that updates or cancels one: the write surface is creation only, and changes to a booking that already exists are made in SuperHote itself. A flow that needs to know the state of the calendar polls Get Availabilities for the windows it cares about, which is a genuine answer rather than a workaround, because availability is precisely what that action reports.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A direct enquiry answered while the guest is still reading
A guest fills in the direct booking form on the host's own site, which is the channel with no commission on it and the slowest reply time. The agent takes the property, the dates and the party size, calls Get Availabilities, and replies within the same minute with the availability status and the computed price for exactly that stay rather than a nightly rate the guest has to multiply. Where the property is free and the guest confirms, Create Booking commits the reservation with the guest's name, phone and country code, and the price that SuperHote itself computed, so the platform's own validation confirms the two sides agree. The confirmation goes out through Gmail and the booking is announced to the cleaning coordinator in WhatsApp with the check in date and the party size.
One enquiry checked across a portfolio instead of one apartment
A guest asks for two bedrooms in the same neighbourhood for a week in August and does not care which building. Because the property key is supplied per action rather than per connection, the agent loops Get Availabilities across every relevant property on the account in one run and comes back with the ones that are genuinely free and what each of them costs for that exact stay. The comparison is written to Google Sheets for the host's own records and the shortlist goes to the guest. Nothing is committed until the guest picks, at which point Create Booking runs against the property key they chose. The value here is not automation of a booking, it is that a portfolio of a dozen rentals answers as one property would.
A negotiated rate that does not get quietly overwritten
A returning guest is offered a rate the host agreed in a message thread, or a guest whose previous stay had a problem is being compensated with a discounted week. The agent calls Get Availabilities first so both numbers exist side by side, the price SuperHote computes and the price that was actually agreed. Create Booking would reject this reservation, correctly, because the two do not match. The agent does not fall back to Create Reservation on its own. It presents the pair to the host with the guest, the stay and the difference, and only books once a person has confirmed the number. The record of who approved the variance is written alongside the booking reference in Notion, which is the artefact that answers the question three months later about why that week was cheap.
Human-in-Loop Highlight
Create Reservation is the gate, and what makes it the gate is the action sitting next to it. Create Booking and Create Reservation do the same thing with one difference: Create Booking requires the price you supply to match the price SuperHote computes for the stay and rejects the request if it does not, and Create Reservation books the stay at the price you supply without that check. SuperHote built a guard and then built a way past it, which is a vendor telling you exactly where the risk is. Every reason an agent would find itself holding a price that disagrees with the platform is a reason to stop: a rate card that changed this morning, a date range parsed one night short, a party size that moves the nightly price, a discount someone mentioned in a message thread. All four produce the same silent outcome through Create Reservation, a confirmed stay at a number nobody agreed to, and the guest sees the confirmation immediately. There is no update or cancel in this connector to walk it back with, so the correction is a phone call and a manual fix in SuperHote. So the agent uses Create Booking as its default and treats a rejection as a question rather than an error. It posts to the host: "Direct enquiry from Claire Béranger, Appartement Canal 2B, 8 to 15 August, 4 guests. She says you agreed 1,150 euros for the week when she stayed in May. Get Availabilities says the property is free and SuperHote computes 1,436 euros for that stay. Create Booking will reject 1,150 because it does not match. I can book it at 1,436 with Create Booking, or book it at 1,150 with Create Reservation, which skips the price check and confirms to her at that figure with no way for me to change it afterwards. Which number, and do you want the 286 euro difference noted anywhere?" The host answers once, and the agent books the stay the way they chose. This is the human-in-the-loop moment on a connector whose entire surface is three actions, and it earns its place because the vendor's own design says a price that does not match is worth stopping for.
Agent Capabilities
3 actionsAvailability
1- Get Availabilities Checks a property's availability for a date range and party size, returning the availability status and the price SuperHote computes for that stay. Because it answers both the calendar question and the price question in one call, it is the read that runs before either create action, and it is also the polling read that stands in for the events this connector does not receive.
Reservations
2- Create Booking Creates a reservation, and requires that the price you supply matches the price SuperHote computes for the stay. The request is rejected if the two disagree, which makes this the safe default: a stale rate or a mis-parsed date range fails loudly instead of confirming a stay at the wrong money. Requires the property key, the check in and check out dates in `YYYY-MM-DD`, the guest first and last name, phone and a two letter ISO country code.
- Create Reservation Creates a reservation using the price you supply, without validating it against SuperHote's computed price. This is the correct action for a negotiated rate, a compensated stay or an agreed discount, and the wrong action to reach for by default, because the guest receives a confirmation at whatever figure is sent and this connector has no update or cancel to reverse it. Takes the same required fields as Create Booking.
Frequently Asked Questions
What can FlowRunner do with SuperHote?
FlowRunner agents can run Get Availabilities, Create Booking, and Create Reservation in SuperHote.
Does connecting SuperHote to FlowRunner require OAuth?
No. SuperHote connects to FlowRunner with an API key, no OAuth flow required.
Can SuperHote trigger a FlowRunner workflow automatically?
SuperHote doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with SuperHote
$100 in credits. No card required. Connect in minutes.