When to Use the Widget, When to Use the API, and When Not to Bother

Ready to take bookings through Camper BMS and wondering which integration suits your setup? For most parks, it's the widget. Camper BMS gives you four paths - widget, hosted booking page, REST API (a technical interface developers can use to build custom software on top of Camper BMS), and iCal feeds - and the decision is usually simpler than it looks.

This post walks through which one fits which situation, including the option of not integrating at all yet.

The Four Options at a Glance

• Widget - paste a snippet on your existing site. Live in minutes. No developer needed.
• Hosted booking page - link out to a Camper BMS-hosted page on your subdomain. Live in minutes. No code at all.
• REST API - build something custom. Days to weeks of developer effort. See the developer docs for details.
• iCal feed - availability sync with external calendars and platforms that support iCal (Airbnb, Booking.com, Google Calendar, Outlook). Import external bookings to block availability, or export Camper BMS availability so other systems can see which sites are booked.

If you want a one-line answer: the widget is the right starting point for most parks.

Use the Widget If...

• You already have a website you're happy with.
• You want bookings live this week, not this quarter.
• You don't have an in-house developer (or your "developer" is the family member who built the site).
• You're happy to update inventory and pricing in the Camper BMS dashboard and have those changes flow to your site automatically.

The widget is designed to be the default. Don't reach past it without a real reason. The Developers page has the embed snippet and a quick walk-through if you want to see what it looks like in code.

Use a Hosted Booking Page If...

• You don't have a website, or your current one isn't worth embedding into.
• You have a website you like the look of and don't want to change anything about it - just add a "Book Now" button that links out to your Camper BMS booking page.
• You want a Camper BMS-managed page you can link to from your Google Business Profile, Instagram bio, or printed signage.
• You're a small park where the dashboard is the operation, and a "website" is just somewhere to send people who want to book.

This is the simplest option of all. No code, no embed - just a URL.

Use the REST API If...

• You have a developer (in-house or on retainer) and a real reason: a kiosk app, a custom dashboard, a multi-park rollup, syncing to accounting software, or bookings flowing into a workflow that lives outside the Camper BMS dashboard.
• You're comfortable with REST, JSON, token-based auth, and the trade-offs of building on top of someone else's API.
• You've read the API documentation and know which endpoints you actually need.

Worth knowing before you start:

• Some endpoints are read-only or rate-limited, so it's worth checking the docs before you build around them. An integration that re-syncs the world on a schedule hits those limits faster than one that only writes when something has actually changed.
• The API doesn't expose every internal admin function. There's a deliberate boundary - if a workflow you need only exists in the dashboard, the API may not be the answer for it.

Use an iCal Feed If...

• You take bookings on Airbnb, Booking.com, or another platform and want those bookings to block availability in Camper BMS automatically (import).
• You want Camper BMS availability to flow out into a Google Calendar, Outlook, or a channel manager that consumes iCal feeds, so external systems stay in sync (export).
• You're managing the same sites across multiple systems and want availability kept in sync without manual entry.

Note: iCal handles availability sync only. You can't take new bookings through an iCal feed in either direction - for inbound bookings, guests use the widget or hosted booking page.

Don't Integrate At All Yet If...

• You're still working out your inventory model, your rates, or your cancellation policy.
• The integration won't fix any of those things. Spending two weeks on a custom build before the underlying setup is right is the most expensive way to learn what's wrong.

Get the dashboard set up the way you want it, take some bookings through the hosted booking page, and only then layer integration on top. The right time to integrate is when you know exactly what "good" looks like.

Reasons People Reach for the API That Don't Hold Up

A few worth pre-empting:

"I need the API to customise the look." Not necessarily - the widget supports custom branding. Colours, fonts, logos, your own web address (for example, book.yourpark.com.au). If you genuinely need CSS-level control on every pixel, the API is justified, but most setups don't need that.

"I need the API to sync with my accounting software." Almost certainly not. Because Camper BMS isn't in the payment flow, your guest revenue lands in your own account via your payment provider - and your provider might already have its own Xero or MYOB integration to handle the bookkeeping. Camper BMS doesn't need to be in that loop.

"I need the API because I have a custom flow." If your custom flow is "guests pick a site, pay, get a confirmation email", that's the widget - no API needed. Reach for the API when your flow genuinely lives outside that pattern.

If you're tempted by the API, write down what specifically the widget can't do for you. If the answer is generic ("I want more control"), the widget is fine. If the answer is specific ("we run a four-park network and need a unified inventory view"), the API is justified.

What's Not in the API (For Now)

A few things worth being upfront about that aren't in the API today:

• A direct sync from existing systems like RMS or NewBook. Migration is spreadsheet-based - see the migration playbook.
• An official SDK or wrapper library. The REST API is the contract, and you can build a thin client on top of it if that suits your setup.
• Push notifications for events are covered by Camper BMS webhooks, which send updates shortly after each event and work alongside the API rather than through it.

Those are v1 scope decisions and may expand over time. Keeping the scope tight is what keeps the API stable and the documentation accurate.

The Bottom Line

Start with the widget or hosted page unless you can name a concrete thing they can't do. The API is there when you have a specific need the widget or hosted page can't meet.

And whichever path you pick, guest payments stay yours - Camper BMS isn't in the payment flow regardless of how bookings come in.