How a connection goes live
Five steps, each with a named person acting and a clear definition of done. The rules are published so you can check them against your own connections.
Corvane Travel ⇄ Alpine Distribution
In progress
- Requested
- Commercial review
- Credentials
- Mapping
- Testing
- Approval
- Canary
- Live
Acting now
Operator
Analyst or operator
A small, capped share of traffic, with booking state checked closely.
Each step has a named person acting and a clear definition of done.
- 5
- steps, each with a named owner
- 8
- stages a connection passes through
- 3
- approvals before go-live
The five steps
- Requested
- Commercial review
- Credentials
- Mapping
- Testing
- Approval
- Canary
- Live
Five steps for people, eight stages on the record. These are the stages one connection passes through.
- Buyer side
- Seller side
- Analyst or operator
Step 1 of 5
Choose your partner
Request the connection and record your commercial agreement. Buyers and sellers keep contracting and settling with each other directly.
This approval records that both companies intend to connect. It isn't a contract. Your agreement stays between you, and the connection only needs a reference to it on record before anyone can approve go-live.
Who acts
- Buyer business admin requests the connection
- Seller business admin accepts or declines it
- Connection
- Corvane Travel ⇄ Alpine Distribution
- Commercial terms
- Agreement CT-2041
- Buyer
- Recorded
- Seller
- Recorded
Illustrative. Companies and data are fictional. This step stays blocked when
- Either side declines or doesn't respond. The connection stays at Requested and no technical work starts.
- No agreement reference is on record. The connection can't reach final approval until one is.
Done when: Both companies approve the intent to connect.
Step 2 of 5
Connect securely
Pick a supported adapter and add credentials through a vault-backed form. Once saved, a secret is never displayed again.
TravelRevo works with a set list of existing hotel adapters. If your counterparty's system isn't on it, we tell you at this step, before anyone has spent a week on it.
Who acts
- Buyer integration engineer sets up sandbox access
- Seller integration engineer provides the test configuration
- Adapter
- alpine-2.3.1
- Secret
- ref:alpine/sandbox
- Credential version
- 3
- Sandbox access
- Validated
Illustrative. Companies and data are fictional. This step stays blocked when
- No supported adapter exists. The connection waits, and it shows why.
- Credentials fail validation. The error names what failed and never repeats the credential.
- There's no authorised sandbox or agreed test property. Write tests run only against an approved sandbox, simulator or agreed test property, so testing can't start.
Done when: Access is validated against the agreed sandbox.
Step 3 of 5
Resolve the mapping
Import the hotel list and see what linked, what is missing and what is ambiguous. A person reviews every new match.
Mapping covers hotel identity only. Rooms and rates pass through with the seller's own codes and terms, because a matching room label doesn't prove two rooms are equal.
Who acts
- Seller supplies the hotel list with native codes
- Mapping analyst approves or rejects each new match, with a reason
Supplier record
The Saltline Hotel Dubai
10 Harbour Street, Dubai
ALPINE · HT900
Proposed property
The Saltline Hotel
10 Harbor Street, Dubai
REVO · c100-0001
Illustrative. Companies and data are fictional. This step stays blocked when
- A match is ambiguous, such as two hotels sharing one building. It waits for an analyst and can't be approved automatically.
- A hotel has no approved match. It stays flagged as unmapped, the handling is chosen per connection, and it's never swapped for a similar property at quote or booking.
- A mapping gets corrected. That creates a new snapshot version, and tests pinned to the old one stop counting.
Done when: A versioned mapping snapshot is approved.
Step 4 of 5
Run the tests
Run search, quote, book, read and cancel in sandbox, including the awkward cases: price changes, timeouts and duplicate requests.
Each result is pinned to an adapter version, a mapping snapshot and a configuration revision. The plan covers non-refundable rates, missing taxes, rate limits and failed cancellations as well as the normal path.
Who acts
- Buyer integration engineer runs the test plan
- Seller integration engineer approves the test policy and reviews results
- Credentials reach the sandboxPassed
- Search, 2 adults + child aged 7Passed
- Quote recheck, price changedFailed
- Book, seller times out mid-bookingInconclusive
- Cancel, non-refundable rateNot run
Illustrative. Companies and data are fictional. This step stays blocked when
- A required test fails. The result shows expected, actual and a redacted trace.
- A test is inconclusive. Inconclusive never counts as passed.
- A pinned version changes. The affected tests go back to not run.
Done when: Required tests pass on the current versions.
Step 5 of 5
Approve and go live
Three approvals, then a small canary with a traffic cap and a rollback ready. Traffic ramps up within the seller's limits.
A canary is a small, capped slice of real traffic, watched closely before anything larger is allowed. Each ramp stays inside the limits the seller has set.
Who acts
- Buyer business admin approves go-live
- Seller business admin approves go-live and sets traffic limits
- TravelRevo operator approves, then authorises the canary and each ramp
- Buyer approval
- Waiting
- Seller approval
- Waiting
- Operator approval
- Waiting
- Canary
- A small, capped share of traffic
Illustrative. Companies and data are fictional. This step stays blocked when
- A required check is unmet: commercial reference, approved mapping snapshot, current passing tests, traffic policy, or buyer, seller or operator approval.
- The canary hits an abort condition, such as rising errors, seller rate-limit responses, unknown booking outcomes or tax discrepancies. Traffic stops ramping and the rollback is ready.
Done when: The connection is live, and you can see its health.
Live needs every check to pass. One open check keeps it closed.
Any open gate blocks go-live, and the connection says which one and who owns it. If a passing test goes stale because a version changed, that gate reopens by itself.
Corvane Travel ⇄ Alpine DistributionCan't go live: 5 of 7 gates open
- Commercial terms referencedAgreement CT-2041, both companiesRecorded
- Buyer approvalCorvane Travel business admin, after the tests passWaiting
- Seller approvalAlpine Distribution business admin, after the tests passWaiting
- Approved mapping snapshotSnapshot v7Approved
- Current passing testsRun 14 on adapter 2.3.1: quote recheck failedFailed
- Traffic policyCap and canary plan, seller and operatorWaiting
- Operator approvalCan't be requested until the tests passWaiting
What happens when something goes wrong
Hotel connections fail in familiar ways. Here's how TravelRevo handles the common ones.
Seller times out mid-booking
The booking is marked unknown because it may exist on the seller's side. Its status is reconciled first, and no retry goes out until the answer is known.
Who actsAutomatic status checks first, then engineers on both sides if it stays unresolved
The same booking request arrives twice
The duplicate is matched to the first request, so it can't create a second reservation.
Who actsNobody, unless the seller's response conflicts
A live hotel turns out to be mapped wrongly
The analyst corrects it in a new snapshot version. The published version stays intact as a record, and affected tests go back for a retest.
Who actsMapping analyst, with sign-off recorded
Seller starts returning rate-limit errors
The ramp holds, and traffic stays under the seller's cap. Limits are never overridden to clear a backlog.
Who actsTravelRevo operator, with the seller informed
A connection has to be suspended
New search and booking stop. Read, cancel and reconciliation stay open, so existing bookings can still be managed.
Who actsTravelRevo operator, with the reason recorded
Show us the connection that took longest
Tell us where it stalled and who's on the other side. A person will reply.