Skip to content
Grondia Developers

Personal data

A campground’s guests are people, and the API redacts their contact details by default. On bookings it hides the guest’s name and email address. On customers it hides the name, the email address and the phone number. Two scopes would lift the redaction, bookings:pii and customers:pii, but a campground’s administrator cannot create a key with either of them today. If your product needs personal data, write to Felix, felix@grondia.com, or to Siro, siro@grondia.com: access is decided case by case with Felix.

This page says exactly what is redacted on which call, how to ask, and how to build a product that works with the redaction in place.

What each call returns

Section titled “What each call returns”
Call Redacted Returned as it is
GET bookings/ and GET bookings/{id}/ guest_first_name and guest_last_name come back empty. guest_email comes back as "[redacted]". Everything else: dates, site_number, status, total_price, booking_reference, external_reference, channel and the number of guests
GET customers/ first_name and last_name come back empty. email comes back as "[redacted]". phone_number comes back empty. id and date_joined
GET invoices/ Nothing: an invoice carries no guest fields. invoice_number, booking_id, total_chf, status, issued_at
GET sites/, GET ari/ and the till calls Nothing: they carry no guest fields. Everything
Webhooks Nothing: the bodies carry no guest fields (see below). Everything

A booking that has no email address on record shows an empty guest_email instead of "[redacted]", so "[redacted]" also tells you that an address exists.

What a read looks like

Section titled “What a read looks like”

A booking at Camping Beispielsee, read with a key that has no personal-data scope. The guest, Anna Müller, is not in it:

{
  "id": 48213,
  "booking_reference": "B7E41A09C2",
  "guest_first_name": "",
  "guest_last_name": "",
  "guest_email": "[redacted]",
  "site_id": 9061,
  "site_number": "A12",
  "site_category": "Standard",
  "check_in_date": "2026-07-14",
  "check_out_date": "2026-07-17",
  "num_adults": 2,
  "num_youth": 0,
  "num_children": 0,
  "status": "confirmed",
  "total_price": "139.50",
  "created_at": "2026-06-30T22:30:12.481903Z",
  "updated_at": "2026-06-30T22:30:12.481903Z",
  "external_reference": "",
  "channel": ""
}

The same guest as a customer, read from GET customers/. Her name and her contact details are not in it either:

{
  "id": 1207,
  "email": "[redacted]",
  "first_name": "",
  "last_name": "",
  "phone_number": "",
  "date_joined": "2026-06-02T07:15:09.311205Z"
}

What you send

Section titled “What you send”

When you create a booking you may send the guest’s details. The create call answers 201 with the guest fields you sent. Every read after that shows them redacted, and so does a repeat of the same create (the same external_reference), which answers 200.

Field Comes back
guest_first_name, guest_last_name, guest_email In the 201 answer to the create call, as you sent them. Redacted on every later read.
guest_country, guest_zip, guest_city, guest_nationality Never. They are write-only.
guest_id_type, guest_id_number Never. They are write-only.
language, custom_fields Never. They are write-only.

Send guest_id_number only when the campground has asked you to. When it is present, Grondia files a registration form for the guest of that booking right away (a Meldeschein, see the glossary). If filing the form fails, the booking is still created.

Webhooks carry no guest data

Section titled “Webhooks carry no guest data”

A webhook body never holds a guest’s name, email address or phone number. A booking event carries the booking’s id, its references, status, dates, the pitch type code (site_type_code), total and currency; guest.checked_in and guest.checked_out carry the same booking body. guest.created carries only the guest profile’s id, the campground’s guest_number and the time the profile was created.

To see more, fetch the booking. The redaction above applies to what comes back.

Asking for personal data

Section titled “Asking for personal data”

There is no self-service route today. Neither bookings:pii nor customers:pii appears in the campground’s admin, and a key cannot be given either one there.

If your product cannot work without personal data, write to Felix, felix@grondia.com, or to Siro, siro@grondia.com. Say which campground you work with, which calls and fields you need, and what your product does with them. Access is decided case by case with Felix. Until you have an answer, build for the redaction.

Building around redaction

Section titled “Building around redaction”
  • Match on ids, not on names. Use id, booking_reference and your own external_reference to match a record in your system with one in Grondia. Names and email addresses are not there to match on.
  • An empty name is not a deleted name. If you created the booking, you already hold the guest’s details: keep yours. Do not overwrite them with the empty strings and "[redacted]" that a read returns.
  • "[redacted]" is not an address. It looks like text in an email field, so check for it before you store it as an address or send mail to it.
  • Keep guests out of your logs and your test data. Log ids rather than response bodies that carry names, and use invented people in fixtures, as these docs do. Anna Müller does not exist.

Data protection law

Section titled “Data protection law”

A guest’s name, email address and phone number are personal data under data protection law: in Switzerland the nDSG, in the EU the GDPR. This page describes what the API does. It is not legal advice and it does not decide what your product may do with the data. For the rules that apply to you, ask your own legal adviser.

Section titled “Related”