Appearance
Who owns what across systems
Page summary: Know which system owns which fact when EMS works with partners.
Use this when: Use this when a hotel/partner flow is involved or when two systems disagree.
- EMS owns the experience and EMS booking; the partner owns its stay/reservation.
- Hotel booking and reseller booking are different routes with different behaviour.
- Stop at the system boundary instead of inventing partner-side behaviour.
Draft. Read in the code, from the EMS side only. Not checked in a running environment, and nobody from the partner side has reviewed it.
| Covers | What EMS sends to, receives from, stores about and owns in a partnership |
| Does not cover | What a partner system does inside itself |
| Checked against | ems-backend, ems-apis |
| Date checked | 5 August 2026 |
| Owner | product, with the partner team |
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 |
Confirmed in code. ems-backend/internal/booking/handler/v2/booking.controller.go:37-42 against ems-backend/internal/booking/usecases/booking_reseller.usecase.go:176-229
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
Confirmed in code. ems-apis/services/pms/ — the complete list of calls EMS makes is: get host by code, by identifier, by email; get account details; get reservation details; get reservation by identifier; validate a reservation booking; get validation forms; get the host's payment account; and register a new partnership.
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.
Confirmed in code. ems-apis/constants/reseller_status.go:5-11
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.
Confirmed in code. ems-backend/internal/vendors/usecase/reseller.usecase.go:425-500, 544-620
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.
Evidence and test details
- Checked Confirmed in code —
ems-backend/internal/booking/handler/v2/booking.controller.go:37-42,ems-backend/internal/booking/usecases/booking_reseller.usecase.go:229, 5 Aug 2026. - Follow-up OQ-014
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.
Evidence and test details
- Checked Confirmed in code —
ems-backend/internal/booking/usecases/booking_reseller.usecase.go:192-200, 5 Aug 2026.
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.
Evidence and test details
- Checked Confirmed in code —
ems-apis/constants/reseller_status.go:5-11, 5 Aug 2026.
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.
Evidence and test details
- Checked Confirmed in code —
ems-backend/internal/vendors/usecase/reseller.usecase.go:480-500, 5 Aug 2026.
"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.
Evidence and test details
- Checked Confirmed in code —
ems-backend/internal/vendors/usecase/reseller.usecase.go:488againstems-backend/internal/booking/usecases/booking_create.usecase.go:265, 5 Aug 2026.
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.