Manage Lodgify vacation-rental properties, availability, rates, bookings, enquiries, quotes, guest messages and webhooks.
Lodgify ships in the w6w first-party pack. It declares 30 actions, 4 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.lodgifyLodgify is vacation-rental software: a property manager keeps listings, rates, availability and guest bookings in one place and distributes them to booking channels and a direct-booking website.
This app covers the Lodgify Public API’s operational surface, preferring the v2 endpoints where v2 covers the operation and using v1 where only v1 does. Properties can be listed (paged, optionally localised to a website) and read, with their room types and the ids of deleted properties. Availability can be read for every property, one property or one room type, and the number of available units set for a date range. Nightly rates can be read with the property’s rate settings (fees, taxes, promotions) and rates saved for a property and room type. Bookings can be listed with the documented stay and trash filters, read, created, updated, moved to the trash, moved through the Booked / Tentative / Declined / Open lifecycle, checked in and out, and given room access key codes. Enquiries can be read and created. Quotes can be priced for a stay, read for a booking, created for a booking, and a payment link requested and read. Message threads can be read and messages added to a booking or an enquiry. Webhook subscriptions can be listed, created and removed.
Authentication is a Lodgify API key sent in the X-ApiKey header, so the app works in scheduled, unattended runs.
Health comes from the API itself because Lodgify’s status page is behind a bot challenge: a signed GET /v2/properties?size=1 probe, an unsigned probe of the public GET /v1/countries list that proves the API is reachable, and declared absences for the status page and for quota headroom.
Three routes to the same 30 actions. The Workflow tab is generated from Lodgify's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
change-booking-status Mark a booking booked, tentative, declined or open again, or recover it from the trash.
check-in-booking Record that a booking was checked in at a time of day in the property's timezone.
check-out-booking Record that a booking was checked out at a time of day in the property's timezone.
create-booking Create a booking for a property and room type, optionally upgrading an existing enquiry.
create-booking-quote Create a new quote for an existing booking, optionally with add-ons and a rate policy.
create-enquiry Create a guest enquiry, optionally for a property, dates and party size, with an opening message.
delete-booking Move a booking to the trash. It is not permanently deleted and can be recovered.
get-availability Read the availability calendar for every property, one property or one room type over a date range.
get-booking-quote Read the current quote of a booking: status, amounts, per-room prices, add-ons and expiry.
get-quote Price a stay at a property for given dates and party, with optional add-ons and promotion code.
get-rate-settings Read a property's rate settings: booking window, notice, currency, VAT, fees, taxes and promotions.
get-rates-calendar Read the nightly rates calendar of a property's room type, with the rate settings (fees, taxes, promotions) that apply.
list-bookings List bookings, filtered by stay (upcoming, current, historic, by arrival or departure date), update time or trash state.
list-deleted-properties List the ids of properties deleted since a date, to keep a synced copy tidy.
list-properties List the account's properties, 50 per page, optionally only those changed since a date.
list-rooms List the room types of a property, with capacity, amenities and price range. Most rentals have a single room type; its id is needed for rates and availability.
send-message Add a message to a booking's or an enquiry's thread: a reply to the guest, a guest message, or an internal comment.
subscribe-webhook Have Lodgify call a URL when an event happens. The signing secret is returned once, only here.
update-availability Set the number of available units of a room type for a date range (0 closes the dates).
update-booking Change a booking's dates, property, rooms, guest details or note. Only the fields you set are sent, and Lodgify does not allow every field to change.
update-booking-key-codes Set the access key code of each room on a booking, e.g. a smart-lock code.
update-rates Save nightly rates for a property's room type: price, minimum and maximum stay per date range.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Lodgify's real ids.
{
"manifestVersion": "2",
"name": "lodgify-example",
"steps": [
{
"id": "change-booking-status",
"uses": {
"app": "io.w6w.lodgify",
"action": "change-booking-status",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"bookingId": "<bookingId>",
"transition": "<transition>"
}
}
]
}change-booking-status check-in-booking check-out-booking create-booking create-booking-quote +25 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Lodgify, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Lodgify. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "change-booking-status",
payload: {
bookingId: "<value>",
transition: "<value>",
// requestPayment: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action change-booking-status --payload '{"bookingId":"<value>","transition":"<value>"}' Give an AI agent Lodgify — without giving it Lodgify's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.lodgify#change-booking-status",
"input": {
"bookingId": "<bookingId>",
"transition": "<transition>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Lodgify connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Lodgify's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Lodgify itself is MIT, and the runtime that executes it is source-available (FSL).
Lodgify declares its own checks, so its health is a property of the app rather than something the host guesses at.
No machine-readable status feed: status.lodgify.com is behind a Cloudflare bot challenge and lodgify.statuspage.io is an unclaimed decoy.
Signed GET /v2/properties?size=1, classified from the response body.
Unsigned GET /v1/countries; the documented {code, name} list proves the API is reachable without proving this connection's key is live.
Lodgify documents fixed per-minute ceilings but no header or endpoint that reports remaining headroom.