The feed, in draft

One endpoint

Your system sends rows to a single address with a bearer key. Keys that start with jd_test_ are validated and shown in your dashboard and never relayed; keys that start with jd_live_ are relayed to every platform you have connected.

One row

A row is one room type, one rate plan, one night: the room and plan identifiers you declared in the dashboard, the date, the price tax-included as your settings say, the units still available, and the minimum stay. A row replaces the previous one for the same room, plan and night — the same delta semantics as Google's ARI messages.

Everything once, then changes

At the start, push the whole horizon you sell — a year, or three. After that, push only the nights that changed. We relay in real time through a queue; there is no polling.

What we check before relaying

The room and the plan exist in your setup. The price is present and shaped as Google's specification requires — what counts as closed or empty follows that specification, not our taste. The same stay costs the same on your landing page: that check runs after every feed.

Channel managers

If your rates already live in myallocator, Cloudbeds or SiteMinder, we can read them from there instead of you pushing. Details when those connections exist.

A row, as it will look

POST https://admin.judvi.com/api/v1/feed
Authorization: Bearer jd_test_…
Content-Type: application/json

[
  { "room": "sup", "plan": "FC-BI", "night": "2026-11-15",
    "price": 190.00, "currency": "EUR",
    "available": 2, "min_stay": 1 }
]