Pushing reservations and guests to Journey
Upcoming: a partner-authenticated path for sending reservations and guests to Journey.
There is no partner push endpoint today, and nothing on this page is callable. For reservations and guests the Partner API is read-only. If you need Journey to receive your stay data now, the supported route is a PMS integration — talk to your Journey contact.
This page exists because partners keep asking, and because the honest answer is more useful than silence. No endpoint, path, schema or field name here is a commitment.
What exists today
Journey ingests stay data from property management systems, not from partners directly:
- Scheduled pulls against PMS APIs, and
- PMS webhooks, where the vendor supports them.
Both are vendor-specific integrations configured by Journey, authenticated as Journey against the PMS. Neither is a partner-authenticated API. See how reservation and guest data flows.
A next-generation ingestion gateway covering a broader set of providers is in development. It is not in production, and it is an internal component rather than a partner-facing API.
Why this is not simply "add a POST endpoint"
If you are planning around this, these are the real constraints. They are also why a thin endpoint would be worse than none.
There is no published ingest contract
The canonical shape today is Journey's internal per-PMS staging model, unioned into a reservations mart. A partner-facing contract would have to be defined and versioned deliberately, rather than exposing an internal schema that is free to change.
Tenancy has to be mapped explicitly
Ingestion is keyed on a host identifier together with the source system, and that pair is also the deduplication key. A push path needs a reliable mapping from your credential to those values and to the right property — get it wrong and records either collide or orphan.
Ordering decides which version wins
Deduplication keeps the newest record per source id, ordered by an ingestion timestamp. For pushed data that timestamp has to be assigned by the server, because a client clock cannot be trusted to move forward consistently.
Backfill is a different problem from streaming
The freshness path only looks at a short recent window. Historical loads have to take a separate route, or they are silently dropped. Any push design needs both, and they will not be the same endpoint.
Feedback has to be designed in
Processing is batch — modelling, then a periodic import into Core. There is currently nothing that reports per-record acceptance back to a sender. Without that, a push API would accept data and give you no way to know whether it landed.
Per-record idempotency is unsolved
Idempotency-Key applies to a whole request, not to the records inside it.
A bulk push needs per-record identity so a partial retry does not duplicate
some rows and skip others.
Channel classification is required, not optional
Each booking must carry whether it was direct, OTA or other. That single field decides whether and how the stay earns, so it cannot be inferred after the fact.
What to do in the meantime
- Integrate through your PMS. If your property management system is supported, that path is live and maintained.
- Read, do not write. Use roster sync to keep your systems aligned with Journey's view.
- Tell us your shape. If you have a use case that genuinely cannot go through a PMS, that is exactly the input that shapes this work. Raise it with your Journey contact rather than building against an endpoint that does not exist.
This page will be replaced with real reference material if and when a partner ingest path ships. Until the status badge above changes, treat everything here as direction, not specification.