What you can build

Grondia is the software campgrounds run on: the pitch plan, bookings, the reception desk, invoices and the guest’s booking page. Each campground is separate, with its own pitches, prices, guests and settings. Your product connects to the campgrounds that use it, one at a time.

There are two ways to connect, and they run in opposite directions.

You build on our API

Your software reads and writes a campground’s data through the Grondia API: bookings, pitches, availability and prices, invoices, shop sales. Grondia tells you about changes with webhooks, so you do not have to poll. Each campground that uses your product creates an API key for you in its admin, and you keep one key per campground.

You make	You use	In the API reference
A channel manager or booking portal	Availability, rates and restrictions; create and cancel bookings; booking events	Channel managers, Bookings
Accounting or ERP software	Invoices; invoice and payment events	Invoices, Webhooks
Guest messaging or a CRM	Customers and bookings; booking and guest events. Personal data is redacted by default (Credentials)	Customers, Webhooks
A shop or restaurant till	Post sales to the campground, read its product list	Point of sale
A no-code or automation platform	Events on bookings, guests and payments, and the calls above	Webhooks

Each name in the first column is a recipe: one kind of product, from the first call to the list of things to check before you go live.

This path is open today. Start with the Quickstart, then check in Credentials which scopes your product needs. The campground’s admin can create some of them; for the others, ask Felix, felix@grondia.com, or Siro, siro@grondia.com. When your product works, the Partner program is the way to a review, a pilot with one campground and a listing in the App Store.

We build on your API

Hardware and services that do something on the campground itself, such as door locks and key systems, entry barriers and EV chargers, connect the other way round. Grondia writes an adapter that calls your API at the right moments of a stay: it issues a keypad code that is valid for the length of a booking, or it fetches a guest’s charging sessions to put them on the campground’s invoice. Grondia’s door-lock integrations (Salto KS, Nuki), its barrier integration and its EV-charging integration (AMPECO) all work this way.

The public API is not built for this, and we would rather say so now than after you have built against it:

• Booking and check-in events carry no guest data and name only the pitch type (site_type_code), not the pitch. A guest.checked_in event does not tell you which door to open.
• There is no endpoint to hand an access code back to Grondia.
• Check-ins are recorded in Grondia, at reception or automatically. The API has no endpoint that records one.

So if your product is a device or a device platform, send us your API documentation and a way to test against it: test hardware, a simulator or a sandbox account. Write to Felix, felix@grondia.com, or to Siro, siro@grondia.com.

Device makers lists what an adapter needs from your API and what to do next.

Not sure?

If your product does both, for example a barrier system that also shows the day’s arrivals on its own screen, it is usually both paths: we build the adapter for the barrier, and you read the bookings through the API. Ask Felix, felix@grondia.com, or Siro, siro@grondia.com, and they will tell you which parts go where. The Partner program page follows both paths from the first email to the listing.