If your property runs on WebHotelier, this page is the honest technical answer to "how would that actually work," not a sales page pretending the details don't matter.
What WebHotelier's API actually exposes
WebHotelier publishes its own developer documentation at docs.webhotelier.net, and the integration is straightforward on paper: it's a REST API, with requests sent to endpoints under rest.reserve-online.net. Authentication is Basic HTTP auth, tied to a Hotelier API account that's bound to one specific property. Responses come back as XML by default, with JSON available and recommended for anything you're parsing programmatically. Reading data uses GET requests; creating, changing, or cancelling something uses POST or DELETE.
The methods span five areas: property data (rooms, rates, extras), availability (single-property and multi-property searches, calendar views), offers and bookings (creation, cancellation, confirmation, search), vouchers, and statistics. For an AI concierge, the two that matter are availability and bookings; everything else is back-office.
What a booking record actually contains
Bookings are retrieved with a simple GET to /reservation/{res_id}. What comes back is more detailed than most PMS integrations bother to expose: confirmation number, status, room type, rate, occupancy, check-in and check-out dates, a full price breakdown (subtotal, extras, taxes, excluded charges), guest contact details, the booking timestamp in ISO 8601 UTC, cancellation policy, and the payment schedule. Bookings that arrived through a channel (Booking.com, Expedia, and similar) can carry extra fields too, like special requests, that the documentation is explicit should be stored and surfaced by whatever system is integrating.
That last point matters more than it looks. A guest who wrote "arriving with an infant, need a crib" in their Booking.com reservation should not have that note silently dropped because an integration only reads the fields it expected.
How the concierge agent uses this
The pattern is the same one behind the AI Guest Concierge demo on the homepage: a guest message triggers an agent, and the agent has tools it can call rather than a script it follows. Mapped onto WebHotelier specifically, that looks like this.
Check WebHotelier availability is what lets the agent answer "do you have a room for the 14th to 17th" with a real date range against the property's actual inventory, instead of a generic "let me check and get back to you." Look up or create booking is what turns a confirmed availability check into something the front desk sees the next morning, using the same reservation data structure WebHotelier itself uses. Escalate to front desk is the tool that matters most: it's what the agent reaches for the moment a request touches something it shouldn't decide alone.
Where a human still needs to be in the loop
Payment schedules and cancellation policies are two of the richer fields in a WebHotelier booking record, and deliberately so: they're also two of the places an automation should not make the final call. A guest asking to move a non-refundable booking, or disputing a deposit, is a conversation for a person with authority to make an exception, not an agent following a tool call. The same goes for anything that reads as a complaint, a VIP request, or genuinely ambiguous. The point of the escalation tool isn't to catch edge cases the agent failed on; it's a designed part of the system, present from the first version, not bolted on after something went wrong.
What this page is, and isn't. This describes WebHotelier's public API and the integration architecture Attilus AI builds against it. It is not a claim that this is running live for a paying WebHotelier client today; the concierge pattern is a tested demo, documented honestly as that on the About page. A client build swaps the demo's tools for your property's real WebHotelier account and your real front-desk inbox.
The technical details above (endpoint paths, authentication method, data formats, booking fields) are drawn directly from WebHotelier's own developer documentation, not from undisclosed internals.
What a hotel needs to get started
Three things, roughly: a Hotelier API account for the property (this comes from WebHotelier, not from Attilus AI), confirmation of which guest channels you actually want answered (WhatsApp, Instagram DM, your website, or all three), and a name for who on staff should get escalations. Everything else, including exactly which requests the agent handles versus hands off, gets shaped on the intro call around how your property actually runs, not a generic template.
Technical details in this page are drawn from WebHotelier's public developer documentation at docs.webhotelier.net. See also the Guesty and Hostaway integration breakdowns. WebHotelier is a product of its respective owner; Attilus AI is not affiliated with WebHotelier.