Paginierung und Filterung

Jeder Listen-Endpunkt der öffentlichen API verwendet dieselbe Paginierungs-Hülle und dieselben Konventionen für Query-Parameter. Filter sind in v1 bewusst eng gehalten — nur was die tatsächlichen Integrationen brauchen.

Antwortform

Alle Listen-Endpunkte liefern ein Hüllobjekt — niemals ein nacktes JSON-Array — mit vier Feldern auf oberster Ebene:

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

Feld	Typ	Bedeutung
count	integer	Gesamtzahl der Datensätze, die der Abfrage entsprechen, über alle Seiten hinweg
next	string | null	Absolute URL der nächsten Seite, oder null, wenn die letzte Seite erreicht ist
previous	string | null	Absolute URL der vorherigen Seite, oder null, wenn die erste Seite angezeigt wird
results	array	Datensätze der aktuellen Seite, je Endpunkt serialisiert

Am zuverlässigsten lässt sich eine Ergebnismenge durchwandern, indem dem next-Link gefolgt wird, bis er null ist. Bauen Sie die URL nicht selbst zusammen — die API kann in einer zukünftigen Minor-Version Query-Parameter ergänzen oder umbenennen, und next enthält bereits die richtigen.

Query-Parameter

Zwei Paginierungsparameter funktionieren auf jedem Listen-Endpunkt:

Parameter	Standard	Maximum	Hinweise
page	1	—	1-indiziert. Eine Seite jenseits des Endes anzufordern liefert 404.
page_size	50	200	Der Server begrenzt auf das Maximum — page_size=1000 liefert 200 Datensätze, keinen Fehler.

Beispiel:

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

Filter pro Endpunkt

Die in v1 verfügbaren Filter sind unten aufgeführt. Alles nicht Genannte ist kein unterstützter Parameter — solche Werte werden stillschweigend ignoriert, kein Fehler, doch auf dieses Verhalten kann zukünftig nicht gezählt werden.

Buchungen — GET /api/v1/public/bookings/

Parameter	Typ	Verhalten
status	string	Exakter Vergleich mit dem Buchungsstatuscode (z. B. confirmed, pending, cancelled).
check_in_from	date (YYYY-MM-DD)	Liefert Buchungen mit check_in_date >= dem Wert.
check_in_to	date (YYYY-MM-DD)	Liefert Buchungen mit check_in_date <= dem Wert.

check_in_from und check_in_to lassen sich kombinieren, um ein Anreisefenster abzubilden, z. B. alle Buchungen mit Anreise im Juli 2026:

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

Stellplätze — GET /api/v1/public/sites/

In v1 keine Filter. Holen Sie die vollständige Liste und filtern Sie clientseitig, oder blättern Sie durch die Seiten.

Kunden — GET /api/v1/public/customers/

In v1 keine Filter.

Rechnungen — GET /api/v1/public/invoices/

In v1 keine Filter.

Sortierung

Sortierung ist in v1 nicht konfigurierbar. Jeder Endpunkt hat eine feste Standardreihenfolge, gewählt nach dem häufigsten Zugriffsmuster:

Endpunkt	Standardsortierung
GET /api/v1/public/bookings/	created_at absteigend — neueste Buchungen zuerst
GET /api/v1/public/sites/	site_number aufsteigend — natürliche Reihenfolge des Platzlayouts
GET /api/v1/public/customers/	date_joined absteigend — zuletzt registrierte zuerst
GET /api/v1/public/invoices/	created_at absteigend — zuletzt ausgestellte zuerst

Wird eine andere Reihenfolge benötigt, sortieren Sie clientseitig nach dem Abruf oder grenzen Sie das Ergebnis vorher per Filter ein.