GetYourGuide: main object, sub-objects and the mirror object

For GetYourGuide you set up your product so the integration can share availability, but i-Reserve sends no customer emails for GetYourGuide bookings. You do this with a mirror object.

Main object with sub-objects

Through GetYourGuide you sell a main object (the activity), which may consist of sub-objects (for example individual boats, guides or time slots). The capacity of those sub-objects determines what is sent to GetYourGuide as availability.

The mirror object (= resource, without workflow)

Next to your normal object you create a mirror object. This mirror object is a resource and has no workflow.

Why without workflow?

Because otherwise i-Reserve sends emails to the customer on every status change (confirmations, reminders, etc.). For a GetYourGuide booking that is not allowed: GetYourGuide handles all customer communication itself. An object without workflow sends no status emails, so the customer receives no duplicate or unwanted messages from i-Reserve.

Why a resource?

As a resource, the mirror object shares the capacity with your real object. That keeps availability in sync: a sale via GetYourGuide occupies the same resource as a normal booking, so double selling is prevented — without the GetYourGuide booking going through the normal mail flow.

In short

• Main object (+ sub-objects) — your normal sales object with workflow and emails.
• Mirror object — a resource object without workflow, linked to GetYourGuide.
• Shared resource — keeps availability equal between the two (no overbooking).
• No i-Reserve emails for GetYourGuide bookings — GetYourGuide communicates with the customer.

In the mapping you then link the mirror object to the GetYourGuide product (see “Setting up GetYourGuide”).