Connecting go~mus as a platform is a common integration case: reseller marketplaces (OTAs like GetYourGuide, Tiqets, Musement, Klook, regional tourism platforms), museum-operated booking portals, museum-controlled apps, white-label solutions. This page separates the two paths and shows where each fits.
Recommended: ExperienceBank as channel manager
ExperienceBank is a channel manager specialised in museums and attractions. One integration, many resellers. ExperienceBank maintains the connections to the major OTAs centrally and routes inventory, prices and orders to the respective reseller platforms.
Who this fits.
- New museums starting or expanding reseller distribution
- Houses that want to serve multiple resellers without running a separate integration project per reseller
- Houses seeking operational relief: inventory, prices, availability handled centrally instead of in parallel per partner
Flow.
1. Discuss the setup with ExperienceBank, define inventory and prices.
2. ExperienceBank connects to your go~mus instance.
3. Reseller platforms get enabled through ExperienceBank, not via separate API integrations per reseller.
→ Partner page with the ExperienceBank listing.
Direct API (own booking paths, not for resellers)
The go~mus API is usable directly too - from your website, from an app, or from a special booking path you operate yourself (experience packages, B2B brokering, a white-label platform under museum control). For classic resellers (OTAs, external distribution platforms), always use ExperienceBank, not the direct API.
When the direct API fits.
- Direct order creation from your museum's website, bypassing the standard shop
- A museum-operated app or a special booking portal
- White-label platforms you run yourself, on your responsibility
Flow. Essentially the regular go~mus API with a reseller token instead of a user token. The token determines what is visible and which actions are allowed.
1. Read master data - Tickets, Events, Tours, Coupons, Museums, Exhibitions.
2. Check availability live - capacity endpoints and date-detail seats. A caching strategy is mandatory, see Best practices.
3. Optional: reservation - Reservations when a reseller checkout needs some lifetime on the seats.
4. Create and finalize the order - Orders, two-phase reseller pattern (POST /orders → POST /orders/:id/finalize).
5. Cancel - individual items or the whole order if needed, see Orders: cancel.
6. Fetch documents - ticket PDFs, Passbook, event PDFs, tour PDFs, invoices.
Reseller-specific patterns.
- Token context awareness - reseller tokens grant filtered access: only the tickets, events, tours cleared for this reseller. Responses differ from a user token. Details in Authentication.
- Rate limits - reseller tokens have rate limits. 429 means too many requests; exponential backoff. More in Best practices.
foreign_idfor customer and order mapping - the reseller keeps the customer id (foreign_id) and the order reference (reference) on its side, go~mus carries both. Later lookups work via your own key, not via go~mus ids. Pattern in Customers.
Pitfalls.
- Cancelling all items ≠ cancelling the order. Cancelling each item one by one does not produce a cancelled order. Cancelling the order itself is a separate call - explained in Orders.
- Reservations are not idempotent. On a timeout, do not try to recover the old reservation - it expires after 5 minutes by itself. Run a fresh capacity check and create a new reservation. More in Best practices.
- Price calculation is server-validated. If you compute the
totalyourself, use master-data prices, not your own list prices. Otherwise the server rejects the order. Background in Best practices.
Which path fits what
| Situation | Recommendation |
|---|---|
| Reseller distribution (OTAs, external platforms) | ExperienceBank |
| Direct orders from your website or app | Direct API |
| Museum-operated booking portal, experience package | Direct API |
| White-label platform under museum control | Direct API |
In doubt: ask support@giantmonkey.de.
Related pages
- Tickets, Events, Tours, Coupons - the booking primitives
- Orders - order lifecycle, two-phase finalize, cancel
- Reservations - temporary holds
- Customers - foreign_id pattern
- Authentication - reseller tokens, permissions
- Best practices - caching, rate limits, price validation, idempotency