Same Integration, Different Property: Why It Works at One Hotel and Breaks at Another

There is a particular kind of bug that costs hotels more time than it should. The integration works. It has worked for months at four other properties on the same PMS, running the same code, hitting the same endpoints. Then you switch it on at the fifth, and it fails immediately.

The instinct is to look at the code. That is usually the wrong place.

The shape of the problem

A recent digital check-in rollout is a clean example. A guest completes check-in and signs; the system attaches the signed PDF to their reservation and guest card in the PMS. Standard flow, live at several properties.

At the new property, every attempt came back with the same rejection:

`"code": "50000", "Directory that configured in optima not exists on the server. HotelID = 4021"`

Every attempt. Attaching to the reservation, attaching to the guest card, both failed identically. And the same call - same code, same request shape - completed normally at the other properties running the same PMS.

That last fact is the whole diagnosis. The code is not the variable. The property is.

Why this happens more than you would expect

Most property management systems are configured per property, not per installation. The vendor ships one platform, but each hotel gets its own configuration: storage paths, document directories, permission sets, rate-code mappings, tax handling, user roles.

That is a reasonable design. Hotels genuinely differ. But it means the surface area for per-property misconfiguration is large, and it is almost entirely invisible from the outside. An API partner cannot see whether the attachment directory for hotel 4021 exists on the PMS host. They can only see the error that comes back when it does not.

The practical consequences:

• A working integration is not proof the next property will work. Each rollout is a fresh environment.
• Errors surface late. Configuration gaps do not appear until the specific feature is exercised with real data, which is often during go-live testing rather than earlier.
• The failure looks like a software bug to everyone watching. The general manager sees check-in not working. What is actually broken is a folder path.

Diagnosing it quickly

The fastest route is a controlled comparison. Take the failing call and run the identical operation against a property where it succeeds. Then put the two side by side:

• Same code path
• Same request structure
• Same credential pattern
• Different property ID
• One succeeds, one returns an error

That comparison does something important. It converts a question of blame - is this the integration or the PMS? - into a single, specific, answerable question about one property's configuration. Nobody has to be persuaded. The evidence does the work.

Writing the ticket so it gets fixed

Support queues are triaged. A ticket that reads the integration is not working joins a long line of vague reports. A ticket that reads this directory does not exist for this hotel ID, here is the error, here is the same call succeeding at another property, please create the directory is a task somebody can complete in minutes.

Include:

1. The exact error string, with its code. Not a paraphrase. 2. The property identifier the PMS uses internally. 3. The specific test record you used, so they can reproduce it. 4. Evidence it works elsewhere on the same platform. 5. The explicit ask. Create the directory, or correct the configured path. 6. What you will do next. Re-run the test on that record and confirm.

The last point matters more than it looks. It tells the vendor the loop closes, and it gives them a definition of done.

The organisational lesson

Two things follow from this pattern, and both are about expectation-setting rather than engineering.

Budget for per-property configuration in every rollout. If you are adding a fifth property to a working integration, the software work may genuinely be zero and the configuration work may still be days. Treating rollout five as a copy of rollout four is how go-live dates slip.

Decide who owns vendor escalation before you need it. In the example above the chain ran from the integration partner to the PMS implementation team to the PMS help desk, with the hotel's general manager copied throughout. That escalation is not a technical task, it is a relationship one, and it moves at the speed of whoever is willing to keep bumping the thread.

What to do before your next go-live

Run every integration point against the new property with real data before the launch date, not on it. Specifically exercise the paths that touch storage or documents - attachments, signed forms, uploaded ID scans - because those are the ones that depend on server-side setup nobody has looked at.

Finding a missing directory two weeks early is a support ticket. Finding it on launch morning is a crisis with an audience.