> For the complete documentation index, see [llms.txt](https://docs.yoplanning.support/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.yoplanning.support/de/developpeur/api-octo-yoplanning-workflow-de-vente-standard.md). # OCTO Yoplanning API - Standard Sales Workflow ### Präsentation Yoplanning bietet eine Implementierung der OCTO-API, um den Weiterverkauf von Aktivitäten zwischen Teams zu ermöglichen. Diese Dokumentation beschreibt den Standard-Workflow für Verkäufe, Stornierungen und Webhook-Benachrichtigungen. Diese Umsetzung entspricht den OCTO-Reisestandards. [Offizielle OCTO-Zertifizierung](https://certify.octo.travel/verify/5065485c-5142-4814-91b7-1dd63777a741) Offizielle OCTO-Dokumentation: *** ### Voraussetzungen Vor der Verwendung der OCTO Yoplanning API müssen in Yoplanning die folgenden Konfigurationen vorhanden sein: * Ein Wiederverkaufsteam (`teamId`) * Ein Lieferantenteam (`providerId`) * Ein API-Token vom Typ `run user`, der im Resale-Team erstellt wurde. * Der Anbieter muss: * nachdem er den Wiederverkäufer in sein Team aufgenommen hatte * die für den Wiederverkauf verfügbaren Produkte konfiguriert haben *** ### Basis-URL ``` https://yoplanning.pro/api/octo/teams//providers// ``` #### Variablen | Variable | Beschreibung | | -------------- | ------------------ | | `` | Reseller-Team-ID | | `` | Lieferantenteam-ID | *** ### Authentifizierung Die Authentifizierung funktioniert wie bei der Yoplanning API v3.1. Sie können Folgendes verwenden: #### Header-Autorisierungstoken ```http Authorization: Token XXXX ``` #### Header Authorization Bearer ```http Authorization: Bearer XXXX ``` *** ### Genutzte Fähigkeiten Alle Anfragen nutzen die folgenden Funktionen: ```http Octo-Capabilities: pricing,content ``` Diese Funktionen ermöglichen Ihnen den Abruf von: * Preisinformationen * Produktmarketinginhalte * beschreibende Daten zur Verfügbarkeit *** ### Standard-Workflow unterstützt Der von Yoplanning unterstützte Standard-Workflow sieht wie folgt aus: ``` /products ↓ /availability/calendar (optionnel) ↓ /availability ↓ /booking ↓ /confirm ``` Ablauf der Stornierung: ``` /cancel ``` Benachrichtigungsablauf: ``` /notifications/subscriptions ``` *** ### 1. Produkte abrufen Endpunkt: ```http GET /products ``` Über diesen Endpunkt können Sie die zum Verkauf stehenden Produkte abrufen. #### Verwenden Der Wiederverkäufer nutzt diesen Weg, um: * Lieferantenkatalog anzeigen * Optionen abrufen * die Tarifeinheiten abrufen * Display-Marketinginhalte *** ### 2. Einen Verfügbarkeitskalender anzeigen (optional) Endpunkt: ```http POST /availability/calendar ``` Dieser Schritt ist optional. Es ermöglicht Ihnen Folgendes anzuzeigen: * Verfügbare Termine * Preise „ab“ * ein Buchungskalender #### Bewährte Verfahren Nutzen Sie diese Route, um: * einen Monatskalender anzeigen * Vorladeverfügbarkeit * Verbesserung der Frontleistung *** ### 3. Verfügbarkeit prüfen Endpunkt: ```http POST /availability ``` Dieser Schritt ist zwingend erforderlich. Es ermöglicht Ihnen, Folgendes abzurufen: * die verfügbaren Zeitfenster * die Zeitpläne * die Fähigkeiten * die genauen Preise * die `availabilityId` Die `availabilityId` ist erforderlich, um eine Reservierung zu erstellen. #### Wichtige Empfehlung Am besten ist es, die „Einheiten“ (Anzahl der Teilnehmer) zu übermitteln. Dies ermöglicht Folgendes: * um den besten Preis zu erhalten * um die gute Verfügbarkeit wiederherzustellen * um die Kapazitäten korrekt zu berechnen *** ### 4. Sitzplätze reservieren Endpunkt: ```http POST /booking ``` Diese Route erstellt eine temporäre Reservierung. Der Auftrag wurde mit folgendem Status erstellt: ``` ON_HOLD ``` Der Status „ON\_HOLD“ bedeutet: * Die Sitzplätze sind gesperrt. * Die Reservierung ist noch nicht bestätigt. * Die Bestellung verfällt automatisch nach 30 Minuten, wenn sie nicht bestätigt wird. #### Wichtig In dieser Phase: * Die Reservierung existiert bereits. * Die Räumlichkeiten sind sicher. * Die Zahlung kann auf Seiten des Wiederverkäufers abgeschlossen werden. *** ### 5. Bestellung bestätigen Endpunkt: ```http POST /confirm ``` Mit diesem Schritt wird die Buchung abgeschlossen. Nach Bestätigung: * Der Auftrag wird endgültig. * Tickets können generiert werden * Die Reservierung ist abgeschlossen. #### Wichtig Die Bestätigung ist einfach: * Es bestätigt lediglich die bestehende Bestellung. * Der Bestellinhalt kann in diesem Stadium nicht mehr geändert werden. *** ### 6. Eine Bestellung stornieren Endpunkt: ```http POST /cancel ``` Über diese Route können Sie eine Reservierung stornieren. #### Wichtig Beachten Sie unbedingt die Stornierungsbedingungen des Anbieters, falls die Buchung bereits bestätigt wurde. Gemäß den Regeln des Lieferanten: * Es können Gebühren anfallen. * Eine Stornierung kann untersagt sein. * Es können bestimmte Bedingungen vorliegen Der Wiederverkäufer muss die Stornierungsbedingungen prüfen, bevor er die Aktion dem Endkunden anbietet. *** ### Reservierung verlängern (optional) Endpunkt: ```http POST /extend ``` Diese Route ermöglicht die Verlängerung der Dauer des `ON_HOLD`-Status. Beispiel : * Zahlung ausstehend * Kundenvalidierung läuft * Zusätzlicher Zeitaufwand erforderlich Die Buchung muss zum Zeitpunkt des Anrufs noch gültig sein. *** ### Webhook-Benachrichtigungen Endpunkt: ```http POST /notifications/subscriptions ``` Über diesen Weg können Sie sich für OCTO-Webhooks registrieren. Webhooks ermöglichen es Ihnen, Benachrichtigungen über Folgendes zu erhalten: * die Produkte * Verfügbarkeit * Buchungen #### Funktion Die vollständigen Objektdaten werden nicht direkt an den Webhook gesendet. Der Webhook enthält die Informationen, die benötigt werden, um die relevanten Endpunkte aufzurufen und Aktualisierungen abzurufen. #### Bewährte Verfahren Nach dem Empfang eines Webhooks: * Erinnern Sie sich an den betreffenden Endpunkt. * Laden Sie die neuesten Daten neu. * Verwenden Sie den Webhook nicht als alleinige Datenquelle. *** ### Verwaltung von Reservierungsabläufen Eine nicht bestätigte Reservierung wird nach Ablauf automatisch gelöscht. Standardmäßig: ``` 30 minutes ``` Der Wiederverkäufer muss daher: * Bestellungen schnell bestätigen * Zahlungsfristen ordnungsgemäß verwalten * Verwenden Sie `/extend`, falls erforderlich *** ### Bewährte Verfahren #### Verwenden Sie immer `/availability` Selbst wenn Sie `/availability/calendar` verwenden, müssen Sie trotzdem Folgendes aufrufen: ```http /availability ``` vor `/booking`. Diese Route liefert die für die Buchung notwendige `availabilityId`. #### Senden Sie die Tarifeinheiten Die Einheiten (`units` / participants) werden immer übermittelt. Dies verbessert Folgendes: * Tarifberechnung * Verfügbarkeit * die Kapazitätsregeln #### Kontrolle der Ausatmung auf der Vorderseite Zeigen Sie einen Timer an, der sichtbar ist, wenn sich der Befehl im Zustand `ON_HOLD` befindet. #### Daten nach Webhook neu laden Webhooks werden ausschließlich für Benachrichtigungen verwendet. Laden Sie die Daten stets über die entsprechenden API-Endpunkte neu. *** ### Offizielle OCTO-Dokumentation Vollständige Details zu den Endpunkten und der OCTO-Architektur finden Sie hier: --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.yoplanning.support/de/developpeur/api-octo-yoplanning-workflow-de-vente-standard.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.