Pagination and filtering

Every list endpoint in the public API uses the same pagination envelope and the same query-parameter conventions. Filters are deliberately limited in v1 — only what the actual integrations need.

Response shape

All list endpoints return a wrapped object — never a bare JSON array — with four top-level keys:

{
  "count": 1234,
  "next": "https://api.campone.ch/api/v1/public/bookings/?page=2",
  "previous": null,
  "results": [
    { "...": "..." },
    { "...": "..." }
  ]
}

Field	Type	Meaning
count	integer	Total number of records that match the query, across all pages
next	string | null	Absolute URL of the next page, or null if you are on the last page
previous	string | null	Absolute URL of the previous page, or null if you are on the first page
results	array	The records on the current page, serialized per-endpoint

The most reliable way to walk a result set is to follow the next link until it is null. Don’t reconstruct the URL yourself — the API may add or rename query parameters in a future minor version, and next already carries the correct ones.

Query parameters

Two pagination parameters work on every list endpoint:

Parameter	Default	Max	Notes
page	1	—	1-indexed. Requesting a page past the end returns 404.
page_size	50	200	Server clamps to the max — sending page_size=1000 will give you 200 records, not an error.

Example:

GET /api/v1/public/sites/?page=2&page_size=100

Per-endpoint filters

Filters in v1 are listed below. Anything not listed is not a supported parameter — sending it is silently ignored, not an error, but you cannot rely on that behaviour going forward.

Bookings — GET /api/v1/public/bookings/

Parameter	Type	Behavior
status	string	Exact match on the booking status code (e.g. confirmed, pending, cancelled).
check_in_from	date (YYYY-MM-DD)	Returns bookings with check_in_date >= the value.
check_in_to	date (YYYY-MM-DD)	Returns bookings with check_in_date <= the value.

Combine check_in_from and check_in_to to get an arrival window, e.g. all bookings checking in during July 2026:

GET /api/v1/public/bookings/?check_in_from=2026-07-01&check_in_to=2026-07-31

Sites — GET /api/v1/public/sites/

No filters in v1. Pull the full list and filter client-side, or page through it.

Customers — GET /api/v1/public/customers/

No filters in v1.

Invoices — GET /api/v1/public/invoices/

No filters in v1.

Sorting

Sorting is not configurable in v1. Each endpoint has a fixed default order, chosen for the most common access pattern:

Endpoint	Default sort
GET /api/v1/public/bookings/	created_at descending — newest bookings first
GET /api/v1/public/sites/	site_number ascending — natural campsite layout order
GET /api/v1/public/customers/	date_joined descending — most recently registered first
GET /api/v1/public/invoices/	created_at descending — most recently issued first

If you need a different order, sort client-side after fetching, or filter to narrow the result set first.