An API can move information. It can’t decide which ballroom name is correct, who approves a changed value or which department answers when two records disagree.
Those decisions belong before the connection. Leave them open and technical progress hides an operating problem until the hotel depends on it.
I’d want the implementation team to explain the record relationships in plain English before they show me a successful request.
Map the real things, not the names
List the property, rooms, airwall sections, room types and opportunity references involved. Don’t match records on display names alone.
One system treats “Grand Ballroom” as one room with three sections. The other has “Grand Ballroom ABC,” “Grand Ballroom AB” and three separate rooms. That isn’t a spelling problem, and treating it like one creates wrong connections everywhere downstream.
Decide what can change where
Which system owns each field? Does data flow one way or both ways? Who’s allowed to change it? What happens to records that get deleted, renamed or aren’t supported on the other side?
Connect only what the workflow actually needs. Copying every available field creates extra permission headaches, upkeep and arguments.
Plan the failure path
What happens when a request fails, a system’s down or a mapping is missing? Who notices? What does the user see? How does the record get fixed?
Test real changes and real failures before you rely on the connection. The hotel needs a recovery process, not just a happy-path demo.
A short checklist before anyone writes code
- Every room and section has one ID, mapped on both sides.
- Every field has an owner and a direction.
- Someone is named to handle exceptions.
- There’s a test plan for a rename, a deletion and an outage.
- Everyone agrees what “done” looks like, beyond “the call returned 200.”
Check the work, not just the request
A successful call isn’t the finish line. Check that the right record changed, the planner or staff saw what they were supposed to see and the source still makes sense.
“Integration-ready” is a preparation step. It isn’t a working integration, and every pilot conversation should say so plainly.
The best time to sort out who owns the hotel’s data is before an API starts faithfully moving the wrong understanding between systems.
Related: The Dangerous Phrase “Single Source of Truth”. For mapping responsibilities, see our hotel sales technology stack guide.
