Reference

Supplier Foundation

The technical reference for partners building or operating an OCTO-compatible Supplier API on The Experience Standard. Covers what each Foundation test verifies, how the tier ladder works, and what your API needs to return for every endpoint we exercise.

1. Overview

The Experience Standard is ETG's production-readiness benchmark for the experience-technology supply chain. The Supplier Foundation certification verifies that a supplier's OCTO API is ready for live distribution with Prioticket and other resellers on the network.

Foundation is the entry tier and the go-live bar. It is not a starter badge; it is the threshold at which a supplier's pre-production API has demonstrated that the booking lifecycle, error handling, content, pricing, and notifications all behave as the OCTO specification requires.

This page is the canonical partner reference. The runner verifies what is described here. If your API behaves as documented, your certification run passes.

2. Tier ladder

There are three tiers. Foundation is the go-live bar. Enterprise adds operational guarantees. Elite is awarded after sustained production reliability.

What to buildFoundation
Go-Live Ready
Enterprise
Scalable
Elite
Production Proven
GET /supplier/{id}
GET /products
GET /products/{id}
GET /availability/calendar
POST /availability
POST /bookings
POST /bookings/{uuid}/confirm
GET /bookings/{uuid}
POST /bookings/{uuid}/cancel
Correct error responses (400, 401, 404, 409)
Product images, descriptions, locale
Octo-Capabilities: octo/pricing on availability and bookings
Outbound webhooks on booking created and cancelled
UUID reuse across hold, confirm, retrieve, cancel
99.5%+ uptime, ≤3s availability SLA, ≤30s booking SLANo
429 with Retry-After headerNo
90 days clean regression historyNoNo

3. Authentication

Every call from the runner carries an Authorization: Bearer <token> header. The token is the credential you entered in the certification wizard, stored encrypted and never logged in plaintext.

Three tests verify your authentication behaviour:

  • AUTH-1: a call with the configured token returns 200.
  • AUTH-2: a call with no Authorization header returns 401 and a structured error body.
  • AUTH-3: a call with a deliberately bad token returns 401 or 403.

Error responses must be JSON objects with at least an errorCode (or error) field and a human-readable errorMessage. Empty bodies or HTML pages fail the test.

4. Products, supplier, availability

These tests confirm the runner can discover your supplier, list your catalogue, fetch the test product, and check availability.

CORE-SUP-1, Supplier details

GET /supplier/{id} returns a JSON object with id, name, and a capabilities array listing the OCTO capabilities you support.

CORE-PROD-1 to CORE-PROD-3, Products

GET /products returns a non-empty array. Each entry carries id, internalName, and availabilityType. GET /products/{id} returns the configured test product with at least one option. A malformed id (/products/0000) returns 400 with a structured error.

CORE-AVAIL-1 to CORE-AVAIL-5, Availability

GET /availability/calendar returns a list of dates with status and vacancies. POST /availability returns bookable slots with stableid values that the booking step consumes. Bad ranges over 365 days return 400; malformed ISO dates return 400; past dates return an empty array, not an error.

5. Booking lifecycle

The runner places a hold, confirms it into a booking, retrieves it, and cancels it. The same UUID flows through every step. Reusing the UUID consistently across hold, confirm, retrieve, and cancel is a hard requirement.

  • CORE-BOOK-1: POST /bookings with a UUID we generate. Response has status: ON_HOLD and echoes the UUID.
  • CORE-BOOK-2: POST /bookings/{uuid}/confirm flips the hold to CONFIRMED and returns a voucher or ticket plus a supplierReference.
  • CORE-BOOK-3: GET /bookings/{uuid} returns the confirmed booking with the same UUID and the voucher data.
  • CORE-BOOK-4: POST /bookings/{uuid}/cancel (not DELETE) returns status: CANCELLED.

Reservations are real. The runner cancels every booking it creates, but costs in your pre-production environment are your responsibility. We recommend a zero-cost test product.

6. Error handling

Nine deliberate bad requests verify that your API rejects malformed input with the right HTTP status and a structured error body.

ScenarioRequestExpected
Malformed product IDGET /products/0000400
Date range over 365 daysAvailability calendar400
Invalid date formatfrom=2025-99-99400 or 500
Past date availabilitydate=2020-01-01200 with []
Empty booking bodyPOST /bookings {}400
Invalid product ID in bookingproductId=INVALID400
Invalid unit IDunitId=INVALID400
Non-existent booking UUIDGET /bookings/00000000-...404
Cancel already-cancelled bookingSecond cancel call409

Every error response must be a JSON body with errorCode and errorMessage. Empty 400s fail.

7. Pricing and content

Pricing and content support are required for Foundation, signalled via the Octo-Capabilities header.

OPT-PRICING-1 to OPT-PRICING-3

With Octo-Capabilities: octo/pricing, GET /products/{id} returns a pricingFrom object (currency and amount). POST /availability returns a pricing block with unitPrices per slot. A confirmed booking response includes pricing.total, pricing.currency, and pricing.unitPrices.

OPT-CONTENT-1 to OPT-CONTENT-3

Product detail must include coverImageUrl or at least one images[].url; a non-empty title, shortDescription, and a description of at least 20 characters; and a declared locale or availableLocales array so resellers know which languages you support.

8. Notifications and webhooks

Notifications cover outbound webhooks from your system to ETG. When the wizard reaches Step 3 it issues a per-run receiver URL of the form:

https://certify.etg-holding.com/webhooks/{test_run_id}

Configure your pre-production system to POST a notification to this URL when a booking is created and when a booking is cancelled. The payload must be a JSON body that includes a type (or event_type / eventType) field plus the booking UUID anywhere in the payload.

  • OPT-NOTIF-1: a booking-created notification arrives within 60 seconds of the confirm call.
  • OPT-NOTIF-2: a booking-cancelled notification arrives within 60 seconds of the cancel call.

Re-runs receive a new URL. The URL stays valid only for the run it was issued for.

9. Glossary

OCTO
Open Connectivity for Tours and Operations. The open API specification this certification is built around.
Foundation
The entry-tier certification. Confirms a supplier's Supplier API behaves as the OCTO spec requires across authentication, the booking lifecycle, error handling, content, pricing, and notifications. Foundation is the go-live bar for live distribution with Prioticket.
Enterprise
Foundation plus operational guarantees: SLA-backed uptime, availability and booking response times, retry safety, UUID consistency, and machine-readable cancellation handling.
Elite
The highest tier. Awarded after 90 days of clean regression history with no major incidents.
Bearer token
The credential the runner presents in the Authorization header. Stored encrypted, used only for the active run, never logged in plaintext.
Test product
A product in your pre-production catalogue that has at least one available, bookable, cancellable slot in the next 30 days, and at least one adult-equivalent unit. Recommended to be zero-cost.
Webhook receiver URL
A per-run URL of the form https://certify.etg-holding.com/webhooks/{test_run_id} that you configure in your pre-production system to receive booking-created and booking-cancelled notifications during the run.

Questions? Open a ticket from your dashboard or reach the certification team via your account contact.

ConnectionHub

The Experience Standard is issued by ETG Holding AG, Florastrasse 18a, 8610 Uster, Switzerland.


© 2026 ETG