IDs & External IDs

TL;DR

There is one Repull id per property. The same value is the id on a property, the listingId on a reservation, and the propertyId for availability. A channel's own id (Airbnb listing id, Booking hotel id) is a separate externalId.

Repull normalizes every property, room, and unit behind a single canonical id. Learn this once and you never have to guess which id a given endpoint expects.

The Repull id

Every property has one stable Repull id (an integer, e.g. 4118). That same value appears under different field names depending on the resource you're reading — but it always points at the same property:

Endpoint	Field	Example
`GET /v1/properties`	`id`	`4118`
`GET /v1/listings/{id}`	`id`	`4118`
`GET /v1/reservations`	`listingId`	`4118`
`GET /v1/availability/{propertyId}`	`propertyId` (path)	`4118`
`GET /v1/channels/airbnb/listings`	`listingId`	`4118`
`GET /v1/channels/booking/properties`	`listingId`	`4118`

One id to store

Persist the Repull id against your own records. Any endpoint that takes a property, listing, or availability id takes this value — you never need to translate between them.

External IDs

An externalId is the id a specific channel uses for the same property — the Airbnb listing id, the Booking.com hotel id, and so on. One Repull property can carry several external ids (one per channel it's published to). Read them from the listing's channels array:

curl https://api.repull.dev/v1/listings/4118 \
  -H "Authorization: Bearer sk_live_YOUR_KEY"

{
  "id": 4118,
  "name": "Lakeview Loft",
  "status": "active",
  "channels": [
    { "platform": "airbnb",  "externalId": "12345678", "active": true, "syncEnabled": true },
    { "platform": "booking", "externalId": "998877",   "active": true, "syncEnabled": true }
  ]
}

GET /v1/properties returns a lighter shape — channels is just the list of connected platforms:

{ "id": 4118, "name": "Lakeview Loft", "channels": ["airbnb", "booking"] }

Channel-specific ids

When you need the raw ids a channel exposes (host id, connection id, hotel id), use the per-channel routes. Each groups connections under the Repull listingId.

Airbnb

curl https://api.repull.dev/v1/channels/airbnb/listings \
  -H "Authorization: Bearer sk_live_YOUR_KEY"

{
  "data": [
    {
      "listingId": 4118,
      "name": "Lakeview Loft",
      "connections": [
        {
          "id": 55,                        // Airbnb connection id (the "airbnbConnectionId")
          "airbnbId": "12345678",          // Airbnb listing id
          "accountId": "112233",           // Airbnb host id — which connected account this row is from
          "accountName": "Seaside Stays",        // that account's display name
          "hostId": "112233",              // alias of accountId, kept for compatibility
          "hostName": "Seaside Stays",           // alias of accountName
          "active": true,
          "syncEnabled": true,
          "primary": true
        }
      ]
    }
  ],
  "pagination": { "nextCursor": null, "hasMore": false, "total": 1 }
}

A workspace can connect several Airbnb host accounts, so accountId tells you which one a row came from — it is the same id GET /v1/connect/airbnb publishes as accounts[].externalAccountId, and the value the Airbnb collection routes take as ?account_id=. See Account scope → Several Airbnb accounts.

Airbnb ids are strings

Airbnb host and listing ids exceed 2⁵³, so they are strings everywhere in the API. Parsing one as a number silently rounds it — 1000000000000000002 becomes 1772489413932732200, which is a different account and returns 404.

Booking.com

Note this route returns a bare array (no data wrapper).

curl https://api.repull.dev/v1/channels/booking/properties \
  -H "Authorization: Bearer sk_live_YOUR_KEY"

[
  {
    "listingId": 4118,
    "name": "Lakeview Loft",
    "connections": [
      {
        "id": 12,                 // Booking connection id
        "hotelId": "998877",      // Booking.com property (hotel) id
        "active": true,
        "syncEnabled": true,
        "syncCategory": "full"
      }
    ]
  }
]

Rooms are separate from properties

Booking.com models room types under a property. Property-level reads return the hotelId; individual room ids are handled during pairing — see Pair PMS Listings.

Previous← API Keys & Account Scope NextConnect (multi-channel) →