Apaleo PMS API Integration Guide for Guest Messaging and AI

An Apaleo PMS API integration uses the same public REST APIs as every other integration on the platform. Access runs through OAuth 2.0, limits run through scopes that name what a tool can read or change, and changes reach the tool through webhooks that push reservation and folio events as they happen. A guest messaging or AI concierge tool needs a small slice of that: reservation reads, a few reservation events, and folio balance if it answers billing questions. That is the honest answer to "does it integrate with Apaleo," and the rest of this guide is about judging whether a vendor's version of that answer holds up. For the wider category, our guide to PMS and AI integrations covers the other platforms.

Everything below is drawn from Apaleo's developer documentation as of October 2026. Apaleo changes its docs, so treat endpoint and event names as things to verify against apaleo.dev before you sign anything.

How does an Apaleo PMS API integration work?

Apaleo is an API-first property management system (PMS), which in practice means there is no special partner connector. Apaleo's own interface, marketplace apps and a private integration you commission all use the same public REST APIs ^[6]. The API overview states that every API is listed at api.apaleo.com and documented with Swagger (OpenAPI), and that a free trial account provides the same credentials for app and API access as a paid one ^[2]. That trial account is your test bed. There is no separate sandbox to request.

The developer documentation is organized into a core API section (authentication, endpoints, errors, rate limiting), business integration guides by use case (channel, booking engine, point of sale, revenue, finance, guest journey, upsell), a webhooks section, an app store and certification section, and an AI integrations section covering a Claude plugin and an MCP server ^[1]. For a guest messaging tool, the guest journey guide, the scopes reference and the webhook configuration page are the three documents that matter. I have not reproduced rate limits here because they were not on the pages I read; check the core API section before you assume any number.

How does a tool get access, and how is it limited?

Two OAuth 2.0 grants, chosen by who built the integration. Apaleo's authentication guide assigns the Authorization Code grant to public marketplace integrations, where a hotel user signs in and consents to the scopes the app requests, and the Client Credentials grant to private custom integrations, where a client ID and secret are issued inside the hotel's own account ^[3]. If a vendor built an app for many Apaleo hotels, expect the first. If they are building something for you alone, expect the second.

Scopes are where a hotel IT lead should spend their attention. Apaleo names them in resource.action form, with .read for read access and .manage for write. The scopes reference lists examples including reservations.read, folios.read, folios.manage and setup.manage, and says of setup.manage: request it only if your app really needs that ^[4]. Fine-grained clients use permissions in a longer form such as core.reservations.read ^[4].

The rule for a messaging tool is simple. Read scopes only, unless the tool posts charges, in which case folios.manage needs a written justification and a conversation with your finance lead. Nothing in the messaging use case touches setup, accounting or rates. If a vendor's consent screen asks for more, that is a scoping error on their side or a feature you did not ask for. The same questions come up with Oracle, with a very different cost model, and how the same questions play out with Oracle OPERA Cloud and OHIP is the companion to this piece.

What does a guest messaging tool actually read?

Less than vendors tend to imply. The reservation record carries what a messaging tool needs to know who it is talking to and when: arrival and departure dates, the assigned unit or unit group, guest name, adults and children, and reservation status. The folio carries the balance, which is the single field behind "what do I owe so far." That is the whole data model for the use case.

Source: Apaleo developer documentation, scopes reference and webhook configuration, accessed October 2026. Event names as documented; verify before building.

What it should not read: anything under finance, rates, availability or setup. A tool that answers "is the pool heated" does not need accounting scopes, and a vendor who asks for them either copied a template from a different integration type or has not thought about least privilege.

One more thing to pin down. Ask whether reservation reads happen on demand (a guest asks, the tool looks up) or on a schedule (the tool syncs every arrival every hour). The first is cheap and precise. The second builds a copy of your arrivals list in someone else's database, which changes the data retention conversation entirely.

Which webhooks matter for guest communication?

Webhooks are how the tool learns that something happened without asking. You subscribe by topic with a POST to webhook.apaleo.com/v1/subscriptions, and Apaleo delivers events to an endpoint you name ^[5]. For the reservation topic, the documented event types include created, amended, changed, checked-in, checked-out, check-in-reverted, set-to-no-show, unit-assigned, unit-unassigned, canceled and deleted. For the folio topic they include balance-changed, charge-posted and payment-posted ^[5].

Map each to a message moment. Created or amended drives the pre-arrival sequence. Checked-in and unit-assigned fire the welcome and the room-specific tips. Checked-out closes the conversation and can open the post-stay message. Canceled and set-to-no-show are the ones people forget: they are how the tool learns to stop, so a guest who canceled on Tuesday does not get "we cannot wait to see you tomorrow" on Thursday.

Three requirements from Apaleo's configuration page belong in the vendor conversation. The endpoint must be reachable over HTTPS, usually on port 443, with HTTPS or basic authentication recommended. Apaleo sends from three outbound IP addresses, 34.240.36.71, 52.212.76.75 and 63.33.249.221, which a firewall should allow. And the documentation states plainly that the list of event types may grow and your implementation should be ready for unexpected types ^[5]. A receiver that throws an error on an unfamiliar event will eventually break on a Friday night. Ask the vendor how theirs behaves. Retry and signature behavior were not on the pages I read, so ask about those too and get the answer in writing.

What does the data flow look like end to end?

Walk one guest through it.

A reservation is created in Apaleo. The webhook fires, the messaging platform receives the event, reads the reservation with reservations.read to get the arrival date and guest details, and schedules the pre-arrival message for three days out. On arrival day the front desk checks the guest in, the checked-in event fires, and the welcome message goes out on the channel the guest already used, with the Wi-Fi code and tonight's dinner hours pulled from the property knowledge base, not from Apaleo. The guest replies "is late checkout possible?" The reply lands in the staff inbox, the AI answers from the policy in the knowledge base, and if the guest pushes back, the conversation escalates to a person with the reservation context attached. On departure day the checked-out event closes the thread.

Notice what did not happen. Nothing was written to Apaleo. No charge was posted, no reservation was changed, no note was added. The messaging use case is read and listen. That is why the scope list above has no .manage entries, and why a vendor who tells you the integration is "deep" should be asked what, exactly, it writes.

Do you need the integration on day one?

No, for most of what a guest messaging tool does. Answering property questions, taking and routing service requests, running one inbox across web chat, SMS, WhatsApp and email, and escalating to a person all run from property content and the conversation itself, with the guest identified by QR code or stay link. Yes, when you want event-triggered journeys and accurate billing answers. Whether AI messaging needs a PMS integration on day one goes through the full capability split.

The honest sequencing is standalone first, connector second. Integration is where hotel technology projects go to stall: in the NYU Tisch Center's 2026 outlook, sponsored by Stayntouch and IDeaS and drawn from more than 300 hotel professionals, 38% named integration a top pain point ^[8]. In Canary Technologies' 2026 survey of 404 hotel IT purchasing decision makers, also vendor-sponsored, integration barriers sat among the top challenges to AI adoption while 58% expected guest communications to be the highest-impact AI area ^[7]. Read together: the value is in guest communication, the delay is in integration, so do not make the first wait on the second.

For an Apaleo property, that means running the messaging layer while the connector is scoped. The ResortConcierge AI connector for Apaleo is planned, not shipped, and the Apaleo integration page, where connector status is published, is the place to check before assuming anything.

One caution on the standalone phase. Adding a tool that does not consolidate a channel is how hotel tech fragmentation gets worse, so the messaging layer should at minimum replace the inboxes you already have, not sit beside them.

What should a hotel ask a vendor before connecting to Apaleo?

Ten questions. Get the answers in writing and attach them to the order form.

1. Which scopes will you request, and why does each one exist for this use case?
2. Which webhook topics and event types will you subscribe to?
3. Will you read reservations on demand or sync them on a schedule, and if you sync, where is the copy stored and for how long?
4. What happens to our data when the token is revoked or the contract ends? Deletion timeline, in days.
5. How does your endpoint handle an event type it does not recognize?
6. Have you demonstrated this integration in an Apaleo trial account, and can we watch?
7. Is this a marketplace app under the Authorization Code grant or a private integration under Client Credentials, and who holds the credentials?
8. What is your certification status with Apaleo, with a date?
9. Who pays for the build, and what is the acceptance test?
10. What runs if the integration is down, and how will we know?

Illustrative: a 90 room Apaleo property scoping this would end up with two scopes (reservations.read, folios.read), seven reservation events plus folio balance-changed, on-demand reads, a 30 day deletion window and a trial-account demo before any production credential is issued. That is a small, defensible footprint, and it is what a well-built messaging integration looks like. Anything much larger deserves a why. If the vendor's answer to question 10 is "nothing," the tool adds a dependency without removing one, which is the test in when adding one tool reduces the mess.

Where ResortConcierge helps

The practice above is standalone first, then a narrow connector. ResortConcierge runs without a PMS today: web chat with QR or stay link entry and a unified inbox need no Apaleo connection, which is how a property should start while the integration is scoped.

The features a reservation event would drive already exist on the platform side: notifications and audience targeting send the arrival-tomorrow, checked-in and departing-today messages, so the integration's value is concrete before it ships. Today those triggers come from stay data in the platform rather than from Apaleo.

The ResortConcierge API describes how the platform exposes its own data; PMS connectors, including the Apaleo connector, are planned, and this post should not be read as describing a live Apaleo app, marketplace listing or certification.

Take the ten questions to your vendor call. If they can answer the first two from memory, you are probably talking to someone who has read the same scopes page you just did, and that is a good sign. If they cannot, you have learned something cheaper than a failed integration would have taught you.