Appearance
Who owns what across systems
Start here: "partner" means two different things
Two separate arrangements are both called partnerships in conversation, and they behave differently in the product. Getting them confused is the main source of trouble on this page.
| Hotel booking | Reseller booking | |
|---|---|---|
| Who books | Hotel staff or a hotel guest, through the hotel's own system | A partner, through their own arrangement with the vendor |
| Availability checked | yes | yes |
| Slot approval respected | yes | no, confirmed straight away |
| Price | EMS works it out | EMS works it out, using the partnership deal |
| How it reaches EMS | Through the booking route, with hotel details attached | Through a separate route of its own |
Anyone saying "partner bookings skip approval" is right about one of these and wrong about the other.
Where the line sits
EMS owns:
- The experience, its price, its availability and its capacity
- The booking record, its identifier and all five of its statuses
- What the money works out to, including the partner's share
- The invoice
- Whether an experience may be offered to a given partner at all
EMS asks the partner system for:
- Who the hotel is, looked up by its code or its identifier
- The hotel's reservation details, so a booking can be tied to a stay
- Whether a reservation may be booked against
- Any extra guest forms the hotel requires
- The hotel's payment account details
That list is the boundary. Nine calls out. Anything a partner system does that is not one of those nine is outside this handbook.
A partnership has its own lifecycle
A partnership between a vendor and a partner is a record with a status of its own:
Invited → Active → Inactive, or Rejected, or Cancelled.
Only an active partnership can produce bookings. What happens to bookings already made when a partnership goes inactive is not established.
Which experiences a partner can sell
Not all of them. Each experience carries a visibility setting for each partnership, and the vendor chooses.
The commercial terms come from a sales model attached to the partnership: either the vendor's default, or one set specifically for that partner. A sales model can also be set per experience, so one partner can have different terms on different experiences.
A word of warning. In this area, "requires approval" means the vendor must approve the experience being offered to that partner. Everywhere else in EMS it means the vendor must approve the booking. Same words, unrelated things.
Rules
Two partner routes, two behaviours OWN-001
What happens today: Hotel bookings go through the ordinary booking route and respect the slot's approval setting. Reseller bookings go through a separate route and are confirmed as soon as availability passes.
When it applies: Always.
Applies to: One sales channel each.
Expected behaviour: Product states that instant confirmation is safe because only instant-confirm experiences are offered to partners. That holds for the reseller route by design; it has not been traced to the code.
EMS owns the booking, the partner owns the stay OWN-002
What happens today: The booking record, its identifier and all its statuses live in EMS. The partner's reservation is looked up from the partner system and referenced; EMS does not own it and does not change it.
When it applies: Every partner booking.
Applies to: One partnership.
Expected behaviour: Exactly this.
Only an active partnership can sell OWN-003
What happens today: A partnership is invited, active, inactive, rejected or cancelled. Only active partnerships produce bookings.
When it applies: Always.
Applies to: One partnership.
Expected behaviour: Not established, specifically: what happens to existing bookings when a partnership stops being active.
The vendor chooses what a partner may sell, experience by experience OWN-004
What happens today: Visibility to a partner is set per experience. Commercial terms come from a sales model on the partnership, which can be overridden per experience.
When it applies: Whenever a partner asks EMS what they may sell.
Applies to: One partnership.
Expected behaviour: Exactly this.
"Requires approval" means something different here OWN-005
What happens today: On a partnership, the phrase refers to the vendor approving an experience for distribution. On a booking, it refers to the vendor approving the booking. The same field name is used for both, in different places.
When it applies: Reading anything about partnerships.
Applies to: Everyone reading the code or the screens.
Expected behaviour: Two different words.
Why it matters: Someone tracing why a booking auto-confirmed will find this field and reach the wrong conclusion.
What is not established yet
| Gap | Why it matters | Who can settle it |
|---|---|---|
| What happens when a partner system is unreachable | EMS makes nine calls out; none of the failure behaviour is documented | engineering |
| Whether changes flow back to the partner, and in which direction | Decides who to believe when the two disagree | partner team |
| Who may cancel a partner booking, and from which side | Support cannot answer this today | product + partner team |
| What happens to live bookings when a partnership is switched off | Real money and real guests | product |
| Who collects the money on a partner booking, and who refunds it | EMS fetches the hotel's payment account, which suggests the hotel may collect. Not traced. | engineering + finance |
| Whether a marketplace such as Get Your Guide uses either of these routes or a third | Left out of scope for now by product | product |
This page describes only the EMS side. Partner behaviour belongs in that partner's own documentation, and nothing here should be read as a statement about it.