.png)
Cloudbeds Integration Guide
Connect Cloudbeds hospitality data with enterprise applications through REST APIs, OAuth authentication, and selected webhook notifications.
Cloudbeds integration options at a glance
Cloudbeds integrations are centered on its REST API, which provides access to supported hospitality objects such as Properties, Reservations, Guests, Rooms, Room Types, and Payments. Cloudbeds also provides webhook-style notifications for selected events, although coverage must be verified for each event and object. OAuth-based authentication controls application access, scopes, and property permissions. Martini can call Cloudbeds endpoints from scheduled or event-driven workflows, paginate collection requests, map payloads into downstream schemas, and expose a controlled REST API for internal consumers. Dedicated bulk, GraphQL, SOAP, file, attachment, and direct database interfaces were not confirmed, so larger synchronizations should use checkpointed REST workflows.
| Integration point | Supported by Cloudbeds? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Read Properties, Reservations, Guests, Rooms, Room Types, and Payments, and perform supported reservation-related updates or status synchronization. | Martini can consume REST endpoints from workflows, paginate collections, map payloads, apply business rules, and expose an internal API over selected Cloudbeds operations. |
| Webhooks / outbound callbacks | Limited | Receive notifications for selected Cloudbeds events when configured and supported; coverage is not universal across objects or fields. | Martini can expose a REST endpoint to receive notifications, validate and deduplicate them, retrieve the current object, and process it asynchronously. |
| Authentication | Yes | OAuth-based authorization uses application credentials, scopes, customer consent, and potentially property-level permissions. | Martini can store credentials and tokens securely, configure authenticated API calls, and isolate environment-specific secrets and access rules. |
| Scheduled synchronization | Yes | Poll paginated REST collections for initial loads, reconciliation, objects without notifications, and recovery from missed events. | Martini workflows can run on schedules, persist checkpoints, use replay windows, and throttle historical and near-real-time processing separately. |
| Pagination and incremental retrieval | Yes | Retrieve large collections through paged REST requests and synchronize changed data using timestamps, identifiers, or supported property-specific state. | Martini can orchestrate page traversal, checkpoint progress, resume failed runs, and route rate-limit or transient failures to retry handling. |
| Bulk / asynchronous APIs | Not confirmed | A distinct Cloudbeds bulk or asynchronous API was not confirmed; large loads should not assume a bulk endpoint. | Martini can implement restartable paginated workflows until Cloudbeds confirms a dedicated bulk mechanism. |
| File / attachment APIs | Not confirmed | A general Cloudbeds file, export, document, or attachment API was not confirmed for guest documents, images, or invoices. | Martini can process files when an independently supported endpoint is available, but the standard Cloudbeds API should not be assumed to provide one. |
| Database / analytics access | Not confirmed | Direct database, JDBC, and general-purpose Cloudbeds analytics database access were not confirmed. | Martini integrations should use Cloudbeds-supported APIs rather than direct database access. |
How Cloudbeds exposes data and business events
Cloudbeds REST APIs
Cloudbeds’ primary documented integration surface is a REST API for supported properties, reservations, guests, rooms, room types, payments, and reservation-related operations. Endpoint coverage, write permissions, pagination, scopes, and property access should be confirmed for each implementation.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with OAuth, calls the required Cloudbeds endpoint, follows pagination, validates the response, maps the vendor object into a canonical model, applies business rules, and writes to the target system or returns a controlled API response.
Implementation sequence
Cloudbeds Webhook Notifications
Cloudbeds provides webhook-style notifications for selected events. Notifications are not confirmed as universal for every object or field, so event coverage, payload identifiers, authentication, delivery behavior, ordering, and retries must be verified.
Martini implementation pattern
Martini implementation pattern: an exposed API receives and authenticates the notification, records an event or deterministic deduplication key, responds promptly, and starts asynchronous processing that retrieves the current Cloudbeds object through REST before applying the business change.
Implementation sequence
Cloudbeds OAuth Authentication
Cloudbeds applications use OAuth-based authorization with client credentials, scopes, customer approval, and potentially property-level permissions. Exact scopes and token lifecycle behavior should be confirmed in the current developer documentation.
Martini implementation pattern
Martini implementation pattern: secure environment configuration stores client credentials and token information, authenticated workflows request or refresh access as required, and authorization failures are separated from transient API failures for appropriate remediation.
Implementation sequence
Cloudbeds Scheduled Synchronization
Scheduled polling is appropriate for initial loads, reconciliation, missed notifications, and objects or changes that do not produce supported webhook events. A dedicated Cloudbeds bulk API was not confirmed.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow retrieves paginated data by property, uses a timestamp or identifier checkpoint with a replay window, throttles requests, and writes progress only after successful downstream processing.
Implementation sequence
Common Cloudbeds integration patterns
Pattern 1: Sync reservations and guests to Salesforce
When to use this pattern
Use this pattern when sales, guest-relations, or account teams need Cloudbeds booking and guest context in Salesforce. The exact Salesforce object model and Cloudbeds write coverage should be confirmed before enabling reverse updates.
Integration direction
Example Mapping
| Cloudbeds Field | Canonical Field | Target Field |
|---|---|---|
| reservationId | booking.externalId | Salesforce booking external ID |
| status | booking.status | Salesforce booking status |
| checkInDate | stay.arrivalDate | Salesforce arrival date |
| guestId | guest.externalId | Salesforce contact external ID |
Martini implementation pattern
A webhook-triggered workflow retrieves the current Reservation and related Guest, or a scheduled workflow polls modified records. Martini validates property and guest identifiers, translates reservation statuses, minimizes personal data, upserts Salesforce records, and retries transient failures without duplicating bookings.
Martini capabilities used
- workflows
- API consumption
- OAuth configuration
- data mapping
- business rules
- error handling
- idempotent upserts
Pattern 2: Send payment data to QuickBooks Online
When to use this pattern
Use this pattern for finance reconciliation where Cloudbeds exposes the required Payments and related reservation information. Payment fields and accounting treatment must be validated for the specific Cloudbeds operation.
Integration direction
Example Mapping
| Cloudbeds Field | Canonical Field | Target Field |
|---|---|---|
| paymentId | payment.externalId | QuickBooks transaction reference |
| amount | payment.amount | QuickBooks amount |
| status | payment.status | QuickBooks transaction status |
| propertyId | property.externalId | QuickBooks location or class |
Martini implementation pattern
A scheduled workflow retrieves supported Payments with related reservation and property context, validates amounts and status transitions, maps them to accounting records, and sends only permitted data to QuickBooks Online. Checkpoints, deduplication keys, bounded retries, and exception routing protect reconciliation accuracy.
Martini capabilities used
- scheduled workflows
- API consumption
- data transformation
- validation
- business rules
- retry handling
- monitoring
Pattern 3: Reconcile channel reservations
When to use this pattern
Use this pattern when a property needs to compare Cloudbeds reservations with Booking.com or Expedia channel information. Channel-specific APIs, ownership of updates, and supported write operations must be confirmed independently.
Integration direction
Example Mapping
| Cloudbeds Field | Canonical Field | Target Field |
|---|---|---|
| reservationId | reservation.sourceId | channel reservation reference |
| bookingChannel | reservation.channel | channel name |
| status | reservation.status | channel status |
| roomTypeId | inventory.roomTypeId | channel room-type reference |
Martini implementation pattern
Martini retrieves Cloudbeds reservations and approved channel data, normalizes identifiers, dates, room types, and cancellation states, compares the sources, and routes discrepancies for review or approved updates. Late, duplicated, or out-of-order changes are handled through stable keys and reconciliation windows.
Martini capabilities used
- workflow orchestration
- API consumption
- mapping
- comparison rules
- validation
- exception handling
Pattern 4: Load hospitality data into Snowflake
When to use this pattern
Use this pattern for centralized occupancy, booking, property, room, room-type, and selected payment reporting. It is especially useful when Cloudbeds data must be combined with other enterprise sources.
Integration direction
Example Mapping
| Cloudbeds Field | Canonical Field | Target Field |
|---|---|---|
| propertyId | property.id | property_id |
| reservationId | reservation.id | reservation_id |
| roomTypeId | roomType.id | room_type_id |
| checkInDate | stay.arrivalDate | arrival_date |
Martini implementation pattern
Scheduled Martini workflows paginate Cloudbeds collections by property, normalize related objects into a canonical model, apply replay windows and checkpoints, and load Snowflake through the approved ingestion interface. Schema validation, incremental processing, and failed-batch replay prevent partial or inconsistent reporting loads.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination orchestration
- data mapping
- JSON handling
- checkpointing
- error handling
Applications commonly integrated with Cloudbeds
Cloudbeds data can be coordinated with adjacent hospitality, finance, customer-service, distribution, and analytics applications. These examples represent realistic enterprise architecture patterns; they do not establish that Cloudbeds provides a native integration with each product.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Combine guest, booking, and account information with CRM and sales processes. | Cloudbeds → Martini → Salesforce | A scheduled or webhook-triggered workflow retrieves Reservations and associated Guests, normalizes identifiers and stay dates, and upserts the appropriate Salesforce data while applying privacy and duplicate-handling rules. |
| QuickBooks Online | Reconcile supported payment, refund, revenue, and property-level financial information. | Cloudbeds → Martini → QuickBooks Online | Martini retrieves supported Payments and related reservation data, applies accounting mappings and property rules, then sends validated records to QuickBooks Online with checkpointing and retry handling. |
| Booking.com | Reconcile reservations, booking-channel identifiers, statuses, dates, and cancellations. | Cloudbeds → Martini → Booking.com | Martini can coordinate REST-based reconciliation where both systems permit it, compare stable reservation and channel identifiers, and route discrepancies for review; channel-specific write support must be verified. |
| Expedia | Compare distribution information and reservation status across participating properties. | Cloudbeds → Martini → Expedia | A workflow retrieves Cloudbeds reservation data, maps channel identifiers and status values, and produces reconciliation results or approved downstream updates according to the supported channel architecture. |
| Airbnb | Coordinate reservation and listing-related information for participating properties. | Cloudbeds → Martini → Airbnb | Martini can normalize Cloudbeds property, room, and reservation data for an approved Airbnb integration process, with explicit rules for supported properties, identifiers, and channel-specific operations. |
| Zendesk | Give support teams reservation and guest context for arrivals, cancellations, special requests, and service issues. | Cloudbeds → Martini → Zendesk | A webhook or polling workflow retrieves the current Cloudbeds Reservation and Guest objects, minimizes sensitive fields, and creates or enriches Zendesk records using idempotent keys. |
| Snowflake | Centralize property-level occupancy, booking, cancellation, and selected payment reporting. | Cloudbeds → Martini → Snowflake | Scheduled Martini workflows paginate through Cloudbeds objects, apply a canonical hospitality model, retain synchronization checkpoints, and load normalized data into Snowflake for analytics. |
How to build a Cloudbeds integration in Martini
Objective
Establish secure Cloudbeds access and configure environment-specific credentials, scopes, properties, and target-system authentication.
Instructions in Martini
- Configure Cloudbeds OAuth client credentials in secure Martini configuration
- Confirm required scopes and property-level permissions with the customer
- Configure target application credentials separately by environment
- Avoid placing tokens or guest data in workflow logs
Objective
Select a webhook, schedule, or API trigger based on Cloudbeds event coverage and the required consistency model.
Instructions in Martini
- Use supported Cloudbeds notifications for selected event-driven flows
- Use scheduled polling for initial loads, reconciliation, and uncovered changes
- Define replay windows and property-level schedules
- Expose a controlled Martini API when another system must invoke the integration
Objective
Obtain the authoritative Cloudbeds object and its related data rather than relying on an incomplete notification payload.
Instructions in Martini
- Validate notification identifiers before processing
- Retrieve the current Reservation, Guest, Payment, or other required object through REST
- Follow pagination for collections
- Persist checkpoints only after successful processing
Objective
Coordinate retrieval, enrichment, validation, transformation, target writes, and exception handling in a maintainable workflow.
Instructions in Martini
- Separate vendor-specific API calls from canonical data processing
- Retrieve related Properties, Rooms, Room Types, Guests, or Payments when required
- Route invalid or incomplete objects to an exception path
- Use asynchronous processing after quickly acknowledging webhook requests
Objective
Translate Cloudbeds objects and status values into the target system’s contract while controlling privacy and field-level differences.
Instructions in Martini
- Define explicit mappings for identifiers, dates, statuses, property keys, and monetary values
- Apply field minimization for guest and payment information
- Do not assume related objects are embedded in every response
- Validate required fields and API-version-sensitive structures
Objective
Make synchronization behavior explicit for reservations, cancellations, payments, duplicate events, and property-specific processing.
Instructions in Martini
- Use stable Cloudbeds identifiers for idempotency
- Distinguish new, modified, cancelled, no-show, check-in, check-out, and payment changes where supported
- Reject or quarantine ambiguous status transitions
- Apply property and authorization rules before downstream writes
Common Cloudbeds data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Properties | Identify hotels or lodging properties and scope property-level synchronization and authorization. | Salesforce, Snowflake, QuickBooks Online, Booking.com | Martini retrieves property identifiers and configuration data, uses them as tenant or routing keys, and maps them into downstream property dimensions. |
| Reservations | Exchange booking dates, status, assigned rooms, channel details, cancellations, and stay information. | Salesforce, Zendesk, Snowflake, Booking.com, Expedia | Martini retrieves current reservations after notifications or during scheduled polling, normalizes status and identifiers, and performs idempotent downstream upserts. |
| Guests | Provide guest profile information associated with reservations and stays. | Salesforce, Zendesk, Snowflake | Martini applies field minimization and privacy rules, validates relationships to Reservations, and avoids logging sensitive personal data. |
| Rooms | Represent individual rooms or accommodation units and support assignment, occupancy, and reporting processes. | Snowflake, Booking.com, Expedia | Martini maps room identifiers and property relationships, joining them to Reservations or Room Types where the API returns separate references. |
| Room Types | Group sellable rooms and accommodation inventory into categories. | Snowflake, Booking.com, Expedia | Martini normalizes room-type identifiers and labels and applies property-specific mapping rules for reporting or reconciliation. |
| Payments | Represent payment information associated with reservations or guest stays. | QuickBooks Online, Snowflake | Martini transfers only fields permitted for the use case, applies accounting mappings, protects sensitive values, and handles refunds or status changes explicitly. |
Authentication and security considerations
OAuth and authorization
Cloudbeds API applications use OAuth-based authorization with client credentials, scopes, customer approval, and potentially property-level permissions. Exact scopes and token lifecycle rules should be confirmed in the current Cloudbeds developer documentation.
Secure implementation
- Store client secrets, access tokens, and environment-specific settings in protected Martini configuration.
- Rotate credentials and handle token expiration or reauthorization without exposing secrets.
- Minimize guest and payment fields copied to downstream systems.
- Do not log OAuth credentials, tokens, sensitive guest values, or payment details.
- Apply separate authorization and retention rules for each property and environment.
Operational considerations for Cloudbeds integrations
Reliability and scale
- Use pagination and restartable checkpoints for collection endpoints.
- Confirm Cloudbeds rate limits and implement bounded retries, backoff, and dead-letter handling.
- Use webhook identifiers or deterministic keys to deduplicate notifications.
- Retrieve the current object after a notification because event payloads may be incomplete.
- Use scheduled reconciliation because webhook coverage is selected rather than universal.
Data and schema control
- Do not assume Reservations contain complete Guests, Rooms, Room Types, Properties, or Payments data.
- Define explicit rules for cancellation, no-show, check-in, check-out, refund, and payment changes.
- Isolate Cloudbeds-specific mappings from downstream contracts to accommodate API or schema changes.
- Test repeated, late, out-of-order, and partially failed events before production rollout.
Why use Martini instead of scripts or point-to-point integrations?
More than a point-to-point script
Martini provides a maintainable integration layer for Cloudbeds REST calls, selected webhook notifications, scheduled synchronization, and downstream API orchestration. Workflows keep retrieval, mapping, validation, business rules, retries, and monitoring in one deployable integration asset.
- Reuse OAuth configuration, API workflows, mappings, and validation logic across properties and environments.
- Expose a controlled REST façade instead of distributing Cloudbeds credentials and object semantics to every consumer.
- Handle pagination, checkpoints, duplicate events, transient failures, and exception routing consistently.
- Separate vendor-specific Cloudbeds objects from canonical models used by CRM, finance, support, and analytics systems.
Frequently asked questions
Cloudbeds can be integrated primarily through its REST API and OAuth-based authorization. Selected webhook-style notifications can support event-driven processing, while scheduled, paginated REST workflows are appropriate for initial loads, reconciliation, and changes without notification coverage.
Yes. Martini can consume the Cloudbeds REST API, receive selected Cloudbeds webhook notifications through an exposed API, orchestrate workflows, map hospitality objects, and synchronize approved data with downstream systems. A native Martini Cloudbeds connector was not verified.
No. A dedicated Cloudbeds connector is not required. Martini can use Cloudbeds’ confirmed native integration mechanisms, including REST APIs, OAuth authentication, selected webhook notifications, and scheduled workflows.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Cloudbeds. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Cloudbeds, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
REST APIs are the primary and recommended method for current integrations. Use OAuth for authorization, selected webhooks for event notifications, and scheduled paginated REST synchronization for initial loads, reconciliation, or objects without supported events. GraphQL, SOAP, bulk, file, and direct database interfaces were not confirmed.
Cloudbeds provides webhook-style notifications for selected events, but coverage is event-specific rather than universal. Martini can receive and authenticate notifications, acknowledge them promptly, retrieve the current object through REST, and use scheduled reconciliation for missed or unsupported changes.
Martini workflows can paginate Cloudbeds collections, persist checkpoints, use replay windows, and apply bounded retries with backoff for transient failures. Stable property, reservation, object, and event identifiers support idempotent upserts and duplicate-event handling.
Yes. Martini can expose a controlled REST API that hides Cloudbeds-specific authentication, maps Cloudbeds objects to an internal contract, applies authorization and business rules, and orchestrates calls to Cloudbeds. This creates a reusable façade for approved internal consumers.
Related Martini documentation
Data processing
Connect Cloudbeds with your enterprise systems
Use Martini to build secure, maintainable Cloudbeds integrations around REST APIs, OAuth, selected webhook notifications, scheduled synchronization, and reusable workflows.