# Pushing reservations and guests to Journey
> Source: /guides/pushing-reservations-and-guests
> Upcoming: a partner-authenticated path for sending reservations and guests to Journey.
> Status: PREVIEW
> Note: Upcoming — not available. No partner endpoint accepts reservations or guests today. This page describes the direction and the problems a push path has to solve, so you can plan; it does not describe anything you can call.

<Warning>
  **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.
</Warning>

## What exists today [#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](/guides/reservation-and-guest-data-flow).

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" [#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.

<Steps>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
</Steps>

## What to do in the meantime [#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](/guides/patterns/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.

<Note>
  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.
</Note>