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 build | Foundation 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 SLA | No | ✓ | ✓ |
| 429 with Retry-After header | No | ✓ | ✓ |
| 90 days clean regression history | No | No | ✓ |
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 /bookingswith a UUID we generate. Response hasstatus: ON_HOLDand echoes the UUID. - CORE-BOOK-2:
POST /bookings/{uuid}/confirmflips the hold toCONFIRMEDand returns a voucher or ticket plus asupplierReference. - 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(notDELETE) returnsstatus: 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.
| Scenario | Request | Expected |
|---|---|---|
| Malformed product ID | GET /products/0000 | 400 |
| Date range over 365 days | Availability calendar | 400 |
| Invalid date format | from=2025-99-99 | 400 or 500 |
| Past date availability | date=2020-01-01 | 200 with [] |
| Empty booking body | POST /bookings {} | 400 |
| Invalid product ID in booking | productId=INVALID | 400 |
| Invalid unit ID | unitId=INVALID | 400 |
| Non-existent booking UUID | GET /bookings/00000000-... | 404 |
| Cancel already-cancelled booking | Second cancel call | 409 |
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.