Lodgify API: build a custom holiday cottage website

Lodgify’s website builder is a reasonable first season. If the template is already fighting your photos, your SEO, or the way a UK cottage actually sells a Saturday-to-Saturday week, you don’t have to leave the PMS. The Lodgify API is how you put live calendars, rates, payments and OTA sync on a holiday cottage website you actually own, without sending guests through the template checkout.

I build that setup for owners who already have Lodgify (or are about to) and need the public site to behave like a business. Guests see a week’s price and can pay a deposit. Airbnb still shares the same calendar. You’re not inventing a second calendar in WordPress and hoping it stays honest.

What the Lodgify API actually does

Lodgify is a property management system with a website bolted on. The API lets you keep the PMS and drop the bolt-on. You authenticate with an API key, then read properties, room types, availability, daily rates and quotes, create bookings, and listen to webhooks when something changes. The last Lodgify staff answer we have (November 2023) said you cannot set or unset unavailable periods through the API — don’t assume you can write blocks. Which plan includes the API is unverified; check the live compare grid.

That sounds abstract until you map it to a stay. A guest picks dates. You need to know if those nights are free, what the week costs with the minimum stay and cleaning fee, whether a deposit can be taken, and whether the same dates are already blocked on Airbnb. The API is the layer that answers those questions so your site uses Lodgify as the source of truth.

Calendars, rates, and availability

The availability endpoints return booked and open periods for a property and its room types. Rates sit beside that: nightly or weekly prices, minimum stays, closed-to-arrival rules, seasonal bands. A custom site should never hard-code “from £1,200” in a banner and hope it stays true. The number on the page should come from the same rate plan Lodgify is sending to the OTAs.

Quotes matter more than people think. A holiday cottage isn’t a hotel night. Guests book Saturday to Saturday, or a short break with a two-night minimum in winter. The API can return a priced quote for a date range so checkout shows the real total — rent, extras, and the deposit — before anyone types a card number. If you skip that and only paint a calendar green and red, you’ll still be sending quotes by hand.

Webhooks close the loop. When Airbnb takes a night, Lodgify updates. Your site should hear that without a cron job someone forgets to run. I subscribe to booking changes so the custom calendar can’t sell a week that just vanished on another channel.

Lodgify integrations with Stripe and OTAs

Lodgify integrations are the reason this setup is worth doing. Payments go through Stripe (or Lodgify Payments, which is Stripe-powered). Lodgify also takes a 1% application/transaction fee on connected gateways, on top of Stripe’s own card rate. The guest pays on your site; Lodgify records the booking; you aren’t copying a bank-transfer reference into a spreadsheet. Card data never needs to touch your server.

On the distribution side, Lodgify’s channel manager still talks to Airbnb, Booking.com, and Vrbo (Expedia in one Lodgify FAQ; the pricing compare row omits it). It does not connect to Sykes, cottages.com or Hoseasons. The custom website is another channel into the same calendar. That’s the whole point. You’re not building a rival PMS. You’re putting a conversion path in front of the PMS you already trust for sync. Google Vacation Rentals is Professional and Ultimate, not Starter, and Google takes no referral fee. Individual homeowners cannot list GVR directly; under 500 properties a connectivity partner is the path. Lodgify also says you need an active Lodgify website for the Google click — check that against a fully custom front before you rely on GVR.

SuperControl’s cottages.com API is two-way and currently needs three properties; Sykes is date-blocking, not a two-way API. Hoseasons sits behind the same three-property gate. Read the Lodgify vs SuperControl comparison before you commit. Lodgify is a genuine fit when Airbnb, Booking.com, Vrbo and a custom front are the job — it is not the only PMS that can sit behind a custom site. I’m happy to sit in front of SuperControl, Bookalet, or whatever you already run.

When the Lodgify website builder is not enough

Lodgify’s website builder is fast. You get pages, a booking widget, and a domain. For a host who would otherwise have nothing but an Airbnb listing, that’s a genuine upgrade. It stops being enough when any of these are true:

• The templates look like every other Lodgify cottage on Google.
• Page speed and Core Web Vitals are a fight you cannot win inside the theme.
• You need location content — North Wales walks, a real “how to get here”, cottage-by-cottage pages — that the builder treats as an afterthought.
• The booking widget fights your layout on mobile, or hides the price until the guest has already bounced.
• You want the site to rank for how owners and guests actually search, not for a generic vacation-rental template.

I’ve watched owners spend a year nudging a template: another app, another custom CSS hack, another “we’ll live with the header”. That year has a cost. A nicer theme will not fix a site with no live prices, a contact form full of spam, and dates that reappear as Airbnb while someone is waiting on a quote. A booking path wired into the PMS does.

How to embed Lodgify on a custom site (widget vs API)

There are two honest ways to put Lodgify on a site you control. People search “how to embed Lodgify” and get the widget. That’s the first way. The API is the second.

The widget (or booking engine embed) drops Lodgify’s calendar and checkout into a page. You keep your own header and copy; they keep their UI. Setup is hours, not weeks. You still get OTA sync, because the widget talks to your Lodgify property. The trade-off is visual and technical: an embedded engine is someone else’s front-end. It can clash with your type, load late, and give Google a weaker page than a native booking flow.

The API path is native. Your site asks Lodgify for availability, renders your own calendar, collects the guest, and creates the booking. Checkout can match the rest of the site. You can put the price on the cottage page, not behind a “check availability” iframe. You can run the marketing site on Next.js, keep Core Web Vitals in your hands, and still let Lodgify be the source of truth.

I use the widget when someone needs a stopgap on an existing WordPress page. I use the API when the site is the conversion product. WordPress plugins sit in the middle — they are still an embed, with theme conflicts on top. That comparison is its own article; the short version is: plugin if you must stay on WordPress this season, API if you’re building the site that should still be here in five years. I wrote that fork in Lodgify WordPress and Lodgify website builder vs custom.

A practical sequence if you already have Lodgify. Connect Airbnb and Booking.com first, and take a test booking that blocks the other channel. Then put the widget on one property page and see whether guests can finish on a phone. If they can, you have a stopgap. If the widget covers the photos, loads after the bounce, or still hides the weekly total, that’s the brief for a custom Lodgify website: native calendar, quote, deposit, confirmation email, same PMS.

Don’t start with the API if the Lodgify property is a mess. Wrong minimum stays, rates that don’t match Airbnb, room types named after internal jokes. The API will faithfully show that mess on a faster site. Clean the engine, then dress it.

Neither path means you abandon Lodgify. You’re choosing how much of the guest-facing layer you own. Get the calendar clean, then decide whether the template is the site, or just the engine.

What we shipped at Penmaenucha Farm

Three units on a farm in North Wales, not a 40-key city operation. The job was specific: live pricing, a real booking path, a PMS calendar as the source of truth, and cottage pages that could rank locally. I didn’t rip out a working channel manager to prove a point. I put a custom site on top of Lodgify and migrated the diary so there was no dark week where nothing could be booked.

The old site had no live prices at all. More than a third of form submissions in one eight-week window were spam. Dates people were waiting on a reply for showed up later as Airbnb on the calendar. After the rebuild they took around £2,000 more in direct bookings on the same eight weeks as the year before. Organic traffic was up 20%. OTA fees were down 15%. About 12 hours a week of quote-chasing went away. The full write-up is there if you want the before and after.

The custom work is the unglamorous part. Mapping old calendar data. Matching room types. Testing that an Airbnb booking blocks the site the same hour. Testing that a site booking blocks Airbnb. Checking Stripe deposits and the balance reminder. That’s API work, not “pick a header font”.

Guests never see the API. They see a week’s price on the cottage page, a calendar that matches reality, and a confirmation that doesn’t say “we will email you a quote”. Owners see a quieter inbox and a diary that isn’t a negotiation. If you want the engineering version of that, it is availability plus quote plus booking create plus webhook. If you want the business version: stop selling stays from Gmail.

The marketing site is the other half. Guests don’t search for your PMS. They search for a cottage in a place. Property pages, speed, and local content are what make the API integration pay for itself. I write about that more in what a direct booking website actually needs. The commercial version of the same argument sits on holiday cottage websites.

If you already have Lodgify and a site that cannot take a booking without an inbox, this is a custom software job with a website in front of it — not a theme swap.

Custom Lodgify website vs starting on the template

Use the template if you have no site, no calendar discipline, and you need Airbnb plus a basic direct path this month. Get the property set up, connect the channels, take one test booking. Don’t wait for a custom build to become “ready” while the diary is still a WordPress plugin and a hope.

Move to a custom Lodgify website when the template is the thing guests bounce from. When you cannot get the price on the page. When Google is sending people to a slow, generic layout. When you care more about owning the booking path than about staying inside a website builder.

You don’t have to choose in the abstract. Look at the live cottage: can someone land from Google, see a week’s price, and pay a deposit on their phone? If yes, the builder might be enough. If no, the Lodgify API is how you keep the PMS and still ship a site that behaves like a business.

I’ll audit the public path for free. If Lodgify is already in place, I’ll tell you whether the widget will do, or whether you need the API — and if the engine isn’t Lodgify, I’ll say that too.