Buchungen synchronisieren

Datenhoheit

1. Buchungsquelle anlegen

Lege eine stabile Quelle pro externem Konto an. Alle Mappings, Buchungen und Teilnehmer bleiben an diese Installation und Quelle gebunden.

POST /v1/club/booking-sources
Authorization: Bearer <token>
Idempotency-Key: 018f-create-source
Content-Type: application/json

{"source_key":"club-booking-system","name":"Club booking system"}

2. Courts explizit zuordnen

Lies Padel-Lab-Courts und speichere für jede externe Court-ID ein Mapping. Die API rät nicht: Ein fehlendes Mapping ergibt 409 UNMAPPED_COURT.

PUT /v1/club/booking-sources/<sourceId>/court-mappings/court-1
Authorization: Bearer <token>
Content-Type: application/json

{"court_id":"crt_01JABC","external_court_name":"Court 1"}

3. Erstimport

Ein Importjob enthält 1 bis 500 vollständige Buchungssnapshots. Verfolge den Job über GET /booking-imports/{id}; einzelne Datensätze können eigene Ergebnisse liefern.

4. Laufende Snapshots

• scheduled_end liegt nach scheduled_start.
• Ein Snapshot umfasst höchstens 24 Stunden und höchstens vier Teilnehmer.
• Eine Stornierung verwendet status: CANCELLED; es gibt kein Buchungs-DELETE.
• Teilnehmer dürfen nur vor der operativen Matchvorbereitung übernommen werden.

{
  "source_version": 42,
  "status": "CONFIRMED",
  "external_court_id": "court-1",
  "scheduled_start": "2030-01-15T18:00:00.000Z",
  "scheduled_end": "2030-01-15T19:30:00.000Z",
  "participants": [
    {
      "external_id": "player-17",
      "display_name": "Alex",
      "consent_to_share": true,
      "consent_reference": "consent-2030-001"
    }
  ]
}

Versionierungsregeln

Abgleich statt Überschreiben

Ein später externer Snapshot bleibt als Buchungswahrheit sichtbar. Sobald eine MatchSession operativ geschützt ist, überschreibt er jedoch weder bestätigte Teilnehmer noch Matchzustand oder Score. Padel Lab erzeugt einen sichtbaren Abgleichkonflikt im Club-Portal.