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

Camper BMS gives you four ways to take bookings: a widget you embed, a hosted booking page you link to, a REST API for custom builds, and iCal feeds for calendar sync. Most parks only need one of them - and it usually isn't the API.

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. Read operations are free; writes are billed per call.
• 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:

• Reads are free. Writes are billed per call - so an integration that re-syncs the world on a schedule costs more than one that only writes when something has actually changed.
• Some endpoints are read-only or rate-limited. Check the docs before you architect around them.
• 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 customer portal, 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 subdomain. 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 merchant account via your payment gateway - and your gateway 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; build your own thin client if you want one.
• Webhooks for arbitrary events. There's a deliberate scope. If your integration needs real-time push, the absence of webhooks may rule out the API for that use case - check the docs before architecting around it.

Those are v1 scope decisions rather than permanent positions, and being upfront about them keeps the API stable and well-documented in the meantime.

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 can.

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