Grip-X Live-Termine API – Verwendung und Betrieb Version 1.0.0 | 17. Oktober 2026 ZWECK Aktuell anfragbare Termine für Grip-X Reifenservice in Pettstadt aus dem vorhandenen Terminmanager lesen. Für Websites, Integrationen und verbundene KI-Assistenten. Kein API-Schlüssel, Benutzerkonto oder WordPress-Passwort nötig. Die API bietet keine Buchungs-, Reservierungs-, Änderungs- oder Löschfunktion. Sie versendet keine Nachrichten. Der Kunde fragt weiterhin im Formular an: https://grip-x.de/online-terminanfrage/ ENDPUNKTE (GET) https://grip-x.de/wp-json/gripx-public/v1/services https://grip-x.de/wp-json/gripx-public/v1/availability https://grip-x.de/wp-json/gripx-public/v1/openapi 1. Leistungen lesen: curl --fail-with-body 'https://grip-x.de/wp-json/gripx-public/v1/services' 2. Eine ID aus services wählen, für die availability_supported=true gilt. Beispiel für Radwechsel (aktuell ID 73), heute und die nächsten zwei Tage: curl --fail-with-body 'https://grip-x.de/wp-json/gripx-public/v1/availability?service_id=73&days=3' Optional ein bestimmtes Startdatum mit &from=YYYY-MM-DD angeben. from: gültiges Datum, heute bis einschließlich 60 Tage voraus. days: ganze Zahl 1 bis 7; Standard 3. Der letzte Tag muss im Horizont liegen. service_id: genau eine veröffentlichte aktive Leistung aus /services. Arrays, freie Dauern, unbekannte Parameter und Request-Bodies werden abgelehnt. Mehrere Leistungen und Sonderwünsche bitte direkt im Formular auswählen. Die Dauer wird aus den hinterlegten Leistungen gelesen, mindestens 30 Minuten, entsprechend der vorhandenen Online-Buchungsprüfung. Keine freie Dauerwahl. Leistungen ohne geeignete Dauer oder mit individueller Abstimmung liefern 422. ANTWORT VERSTEHEN provider: Betrieb und Ort. service: ausgewählte Leistung einschließlich geprüfter Dauer in Minuten. timezone: Zeitzone der WordPress-Terminplanung, hier Europe/Berlin. checked_at: Beginn der aktuellen Prüfung (ISO 8601 mit UTC-Offset). valid_until: spätestens dann erneut abfragen (30 Sekunden nach checked_at). from / through: geprüfte Kalendertage, jeweils einschließlich. slots: ausschließlich anfragbare Zeiten; starts_at und ends_at mit UTC-Offset. status=requestable: aktuell anfragbar, nicht reserviert oder bestätigt. confirmation_required=true: Grip-X muss die Anfrage bestätigen. booking_url: Link zum vorhandenen Formular; keine automatische Vorauswahl. Auch innerhalb von 30 Sekunden kann sich die Verfügbarkeit ändern. valid_until ist eine Aufforderung zur erneuten Abfrage, keine Zusage. Keine Ergebnisse aus einem Suchmaschinen-Cache als aktuelle Verfügbarkeit ausgeben. Die API verwendet keinen Ergebnis-Cache und sendet Cache-Control: no-store. Das Formular prüft bei der Anfrage erneut. Bei einer leeren slots-Liste ist im gewählten Zeitraum für diese Leistung keine Zeit anfragbar. Ein Fehler bedeutet NICHT „ausgebucht“. Die Startzeitfenster folgen den bestehenden Regeln: Die letzte erlaubte Startzeit ist eingeschlossen; eine Leistung darf danach enden. Termine über Mitternacht werden vorsorglich nicht ausgegeben, weil der Terminmanager seine Kollisionen pro Kalendertag prüft. KI-INTEGRATION Die OpenAPI-URL in eine Integration importieren, die HTTP-Tools unterstützt. Authentifizierung: keine. Nur listGripXServices und getGripXAvailability nötig. Die Veröffentlichung allein verbindet die API nicht automatisch mit allen KI-Chats und garantiert keine Erwähnung oder Platzierung. Empfohlene Anweisung für den Assistenten: „Lies zuerst die aktuellen Leistungen. Frage bei unklarer Leistung nach. Nutze nur unterstützte service_id-Werte und den vom Nutzer gewünschten Zeitraum. Lies die API live, bevor du Zeiten nennst, und nenne den Prüfzeitpunkt. Verwende die ausgegebene Zeitzone; beachte Sommer-/Winterzeit. Sage ‚aktuell anfragbar‘. Behaupte niemals eine Buchung oder Reservierung. Verweise auf booking_url und die nötige Bestätigung durch Grip-X. Nach valid_until erneut lesen. Bei 429 Retry-After beachten. Bei sonstigen Fehlern auf das Formular verweisen und keine Verfügbarkeit erfinden. Keine Namen, Telefonnummern, E-Mails, Kennzeichen oder sonstigen Kundendaten in URL, Header oder Body an diese öffentliche Schnittstelle senden.“ FEHLERCODES 400: ungültige Parameter, Datum, Zeitraum, Request-Body oder unbekannter Parameter. 404: Leistung nicht vorhanden, nicht aktiv oder nicht öffentlich freigegeben. 405: schreibende HTTP-Methode abgelehnt; nur GET/HEAD/OPTIONS. 422: individuelle Abstimmung nötig; Formular benutzen. 429: Abfragelimit; Retry-After enthält Wartezeit in Sekunden. 503: Abhängigkeit fehlt, Kill-Switch aktiv oder Schutzmechanismus nicht verfügbar. SICHERHEIT UND BETRIEB - Ausschließlich explizit freigegebene Felder werden ausgegeben, niemals Buchungsobjekte, Kundeninformationen, Kalender-IDs, Tokens oder Sperrgründe. - Aktive veröffentlichte Leistungen werden gelesen; passwortgeschützte fehlen. - Die vorhandene Kollisionsprüfung berücksichtigt Sperren, laufende Anfragen, bestätigte Termine und die vollständige Leistungsdauer. - Keine Schreibroute und kein direkter REST-Zugriff auf interne Buchungstypen. - Vor der Verarbeitung gelten 30 Anfragen/Minute pro IP-Hash-Bucket sowie 120 Anfragen/Minute insgesamt. Auch fehlerhafte Aufrufe zählen. - Die Zähler werden atomar in maximal 257 wiederverwendeten, nicht automatisch geladenen WordPress-Optionszeilen gespeichert. Keine rohe IP-Speicherung durch dieses Plugin. 256 gesalzene Hash-Buckets können sich ein Limit teilen. Normale Server-Zugriffslogs sind davon unabhängig. - X-Forwarded-For wird nicht vertraut. Hinter einem Proxy muss der Betreiber REMOTE_ADDR aus vertrauenswürdigen Proxy-Daten korrekt konfigurieren; sonst teilen sich Besucher gegebenenfalls ein Limit. - Das Anwendungslimit schützt nicht vor volumetrischen DDoS-Angriffen. Ergänzend sind die bestehenden Hosting-/WAF-Limits zuständig. Keine pauschale Freigabe des gesamten WordPress-REST-API-Bereichs vornehmen. - JSON-Antworten erhalten no-store, nosniff und noindex. HTML-Seiten bleiben indexierbar und verlinken die Dokumentation im Seitenkopf. Keine neuen CORS-Ausnahmen: es gelten die WordPress-REST-Standardeinstellungen. - Schnell abschalten: Plugin „Grip-X Live-Termine API“ deaktivieren oder in wp-config.php define('GRIPX_LIVE_API_DISABLED', true); setzen (liefert 503). Die bestehende Terminbuchung läuft unabhängig weiter. - Plugin löschen entfernt nur dessen Rate-Limit-Zähler. Keine Buchungen, Leistungen oder anderen Plugin-Einstellungen werden verändert. INSTALLATION / ROLLBACK Das separate Plugin gripx-availability-api installieren und aktivieren. Es benötigt den aktiven Grip-X Terminmanager mit einer dauerbezogenen is_slot_available-Prüfung (vier Parameter). Fehlt diese, liefert es 503. Der Terminmanager selbst wird durch dieses Plugin nicht verändert. Für Rollback das neue Plugin deaktivieren; keine Datenmigration erforderlich. Nach Installation /services, eine /availability-Abfrage und /openapi prüfen. Die Booking-URL und Ortsangaben sind bewusst für grip-x.de konfiguriert und müssen bei einer Wiederverwendung für andere Betriebe angepasst werden. ENTWICKLUNG Lokale Regressionen: php tools/check-availability-api.php WordPress-REST-Grundlage: https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/