Cloudbeds integration support

Airplate is an RFP and event-management platform for hotels and venues. With Cloudbeds connected, Airplate writes each event request to your Cloudbeds property as a group with a reservation inside it.

• Reads your property and its room types. A connection test reads your property's name and currency; writing a request reads the property's room types and uses the first one for the reservation.
• Writes each request as a group block. When a request is created in Airplate, or edited, Airplate creates a guest profile for the booking contact, a group for the event dates and a reservation inside that group — see event and group block sync.
• What it does not do. It does not check Cloudbeds availability while a request is answered, it receives no notifications from Cloudbeds, and it does not change or cancel what it wrote: a status change or a cancellation in Airplate is not passed on to Cloudbeds.

Airplate authenticates to Cloudbeds with a long-lived API credential issued to your property. While the integration is available on request, Airplate activates it with you; once it is listed on the Cloudbeds marketplace, the Airplate app will be installed from there.

1. 1
   Email [email protected] with the name of the property you want to connect.
2. 2
   When it activates your venue, Airplate arranges a secure way to receive the API credential issued for that property — never by e-mail — and your Property ID, which identifies the property Airplate reads and writes.
3. 3
   Airplate saves both for your venue, the credential encrypted, and sets the environment — Production for your live property, or Sandbox for Cloudbeds' test environment. The integration is active once both the credential and the Property ID are present.
4. 4
   Airplate then tests the connection: a successful test returns your property name and currency straight from Cloudbeds.

Unlike an OAuth integration, the Cloudbeds credential is long-lived. There is no refresh cycle and no expiry for Airplate to manage: the same credential is sent as a bearer token on every request until you replace or revoke it. Three practical consequences:

• Nothing expires silently. The connection will not drop on its own after a period of inactivity, and there is no periodic re-authorisation prompt.
• Revoking is immediate and total. Because there is no refresh token to fall back on, revoking or rotating the credential in Cloudbeds stops Airplate's access on the very next request. Every call then fails until Airplate has the new credential.
• The credential is stored encrypted, and Airplate's connection status never returns it: it shows only whether a credential and a Property ID are set, the Property ID and the environment.

Each time a request is created or edited in Airplate, it is written to Cloudbeds in four steps. Each step runs only if the previous one succeeded. When a step fails, Airplate starts the write again from the first step — up to three attempts in all, one and then two seconds apart — and records the result in Airplate's sync log.

1. 1
   Guest profile. The booking contact from the request — name, email, phone and company — is created as a guest in Cloudbeds.
2. 2
   Group booking. A group is created for the event, named from the event type and company, covering the event dates, carrying the contact details and a note with the event type, guest count and the enquiry detail.
3. 3
   Room type. Airplate reads the property's room types and uses the first one for the reservation that carries the block.
4. 4
   Reservation. A reservation is created inside the group for the event dates.

Dates come from the request: the event date is the start, and checkout is normally the following day. An event that runs past midnight extends the block by an extra day so the space stays held for the whole event.

Every group and reservation Airplate creates carries an external reference of the form AIRPLATE-RFP-<id>, which is how you find Airplate-created bookings in Cloudbeds. Airplate does not look that reference up before it writes: editing a request, or a new attempt after a failed step, creates a new guest, group and reservation, and the earlier ones stay in Cloudbeds as they are.

Airplate does not read guest payment details, folios, or financial reporting, and it does not change or cancel a booking it wrote.

1. 1
   Email [email protected] to switch the Cloudbeds integration off.
2. 2
   Airplate deletes the stored API credential and marks the integration inactive, so no further calls are made to Cloudbeds and no request can write to it.
3. 3
   In Cloudbeds, revoke the API credential issued to Airplate for the property. Because the credential is long-lived, this is the step that guarantees it can never be used again.