Reference · built on requestConnectorHospitality & property systems

apaleo

Reservations, units, folios, and maintenance windows from apaleo, with webhook topics for every change.

Request accessPricing ↗

About

apaleo is an API-first property management system. Its APIs sit under api.apaleo.com and are split by area, each with its own OpenAPI definition: Booking, Inventory, Rate Plan, Finance, Operations, Availability, Settings, Account, Reports, and Logs. Identity runs at identity.apaleo.com with OAuth 2.0. A separate Webhook API at webhook.apaleo.com sends topic and type events such as Reservation checked-in or Folio balance-changed, carrying the entity id only.

Through Fibric, an operator reads the reservation, unit, or folio behind each event and proposes a check-in, a unit condition, or a maintenance window for your approval, with a receipt of what changed and how to undo it.

This is a reference listing. It documents what Fibric would read from apaleo and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Reservations through GET /booking/v1/reservations, filtered by status Confirmed, InHouse, CheckedOut, Canceled, or NoShow
  • Reservation webhook types: created, amended, changed, checked-in, checked-out, set-to-no-show, unit-assigned, canceled, picked-up-from-block
  • Units and unit groups through GET /inventory/v1/units, with Unit and UnitGroup created, changed, and deleted events
  • Maintenances of type OutOfService, OutOfOrder, or OutOfInventory through GET /operations/v1/maintenances
  • Folio events: charge-posted, payment-posted, payment-failed, refund-posted, balance-changed, closed; Invoice created, paid, written-off
  • NightAudit started, succeeded, and failed; Block confirmed, released, and washed; RatePlan and Service changes

Proposed actions

  • Target capability: propose a check-in with PUT /booking/v1/reservation-actions/{id}/checkin, or a check-out with the checkout action
  • Target capability: propose a unit condition of Clean, CleanToBeInspected, or Dirty with PUT /operations/v1/units-condition
  • Target capability: propose a maintenance window with POST /operations/v1/maintenances: unitId, from, to, type, and description
  • Target capability: propose a unit assignment with reservation-actions/{id}/assign-unit, or a no-show with reservation-actions/{id}/noshow
  • Target capability: propose a stay amendment with reservation-actions/{id}/amend, subject to availability and restrictions

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Take a unit out of order with an end date

    When a Maintenance created event or a housekeeping report names a fault, propose a maintenance of type OutOfOrder with from and to dates so availability updates.

    With Out of Order, Predictive Maintenance

  • Confirm the unit is clean before assignment

    After a checked-out event, propose Dirty on the unit, then CleanToBeInspected and Clean as housekeeping reports, before the next unit-assigned.

    With Room Ready, Clean Sequence

  • Catch a failed payment before departure

    Subscribe to Folio payment-failed and balance-changed, read the folio, and propose a message to the guest or a hold on check-out for the desk.

    With Payment Retry, Service Recovery

  • Pick up group blocks on time

    Watch Block confirmed and picked-up-from-block events against the block's cutoff, and propose a reminder or a release for the group coordinator.

    With Block Pickup

Requirements

  • An apaleo account and a user with administration privileges to register the custom app and its client secret
  • Scopes for each call, such as reservations.read, reservations.manage, operations.change-room-state, maintenances.manage, and folios.read; the user's role must also hold the permission
  • A webhook subscription created with POST https://webhook.apaleo.com/v1/subscriptions naming endpointUrl, events, and propertyIds; apaleo sends a health-check event first
  • For development, a trial or development account, which carries lower request limits than a live account
Authentication
OAuth 2.0 at identity.apaleo.com: the client credentials grant for a custom app registered under Apps > Connected apps in your own apaleo account, or the authorization code grant for an app installed from the apaleo Store; access tokens carry scopes and the documented example expires in 3600 seconds.

Limits

  • Live accounts: 3500 requests per minute, 100 per second average, bursts to 200 per second; development and trial accounts 5 per second, 200 per minute
  • PATCH /booking/v*/reservations/{id} and PATCH /booking/v*/bookings/{id} are capped at 20 calls per 5 minutes
  • Webhook payloads carry only the entityId; the connector reads the object afterwards, and a topic can gain new types at any time
  • Over the limit, apaleo returns 429 with a Retry-After header in seconds

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request apaleo ↗

Questions and answers

Which OAuth flow should a hotel use for its own apaleo integration?
apaleo documents the client credentials grant for a custom app in the same account as the data. You register it under Apps > Connected apps > Add custom app, take the Client ID and Client Secret, and request tokens at https://identity.apaleo.com/connect/token with grant_type=client_credentials. Apps distributed through the apaleo Store use the authorization code grant.
What does an apaleo webhook payload contain?
A topic, a type, the accountId and propertyId, a timestamp, and a data object that for now holds only the entityId. apaleo notes the schema may carry different payloads in the future, so the connector always fetches the entity by id. A subscription is created with POST https://webhook.apaleo.com/v1/subscriptions.
What are the apaleo rate limits?
For live accounts, 3500 requests per minute with 100 per second on average and bursts up to 200 per second. Development and trial accounts get 5 per second and 200 per minute. Some endpoints have their own caps, such as 20 PATCH calls per 5 minutes on a reservation. A 429 response includes Retry-After.
Ask about apaleo

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with apaleo through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy