RentRemote Public API: Partner Documentation - Laravel

RentRemote Public API

12 REST endpoints for keeping your own website and RentRemote in step on four things: your properties, your photos, your availability and your prices. JSON in and out, one header for authentication, no SDK required.

First call

Request
curl "https://rentremote.com/api/public/v1/ping" \
  -H "X-API-Key: $RENTREMOTE_API_KEY"
Response · 200
{
  "data": {
    "provider": "Your Company",
    "currency": "EUR",
    "scopes": [
      "properties:read",
      "properties:write",
      "availability:read",
      "availability:write",
      "reservations:read"
    ],
    "properties": 128
  }
}

Endpoints

All 12 routes. Open one for its parameters, its response body and working code in cURL, PHP, Node and Python.

Authentication

One header. A key authenticates a provider account rather than a person, so there is no login step, no token exchange and no session. Every route resolves inside the account the key is bound to.

Send your key in the X-API-Key header on every request. A key is 64 characters, has no prefix, and is shown once when it is issued.

Nothing else authenticates here. Session cookies and RentOS dashboard tokens are rejected, and a Public API key is rejected everywhere else.

Keep the key server-side: in your sync job’s environment, not in a browser bundle and not in a repository.

Start a run with GET /ping, which returns the account, the currency your prices are read in, and the scopes the key holds.

Every request
X-API-Key: <your 64-character key>
Accept: application/json

Scopes

A key carries the scopes it was issued with and cannot widen them. Calling an endpoint outside them returns 403 naming the missing scope.

  • properties:readRead the property catalogue. List your listings and read a single one back.
  • properties:writeCreate and update properties. Publish new inventory and update existing listings.
  • images:readRead property images. List the photos currently held for a listing.
  • images:writeAdd and remove property images. Push photos by URL and delete photos you have retired.
  • availability:readRead the availability calendar. Read the resolved calendar, including nights sold on RentRemote.
  • availability:writePush availability and per-night prices. Open, block and price individual nights.
  • reservations:readRead bookings made on RentRemote. See which of your nights RentRemote has sold.

Errors

Every failure is JSON: a message field, plus an errors object on a 422. Writes are all-or-nothing, so a request that fails validation writes nothing.

  • 401No key, or an unrecognised key
    • API key missing. Send your key in the X-API-Key header.
    • Invalid or expired API key.

    Check the header name and that the key has not passed its expiry date.

  • 403The key may not do this
    • This API key is not enabled for the Public API.
    • This API key is not bound to a provider account.
    • This API key is missing the required scope: properties:write.
    • This provider account is not active.

    Scopes are fixed when the key is issued. Ask your account manager to reissue the key with the scopes you need.

  • 404No such reference
    • Property not found.
    • Reservation not found.
    • Image not found.

    References resolve inside your own account. A reference on another account returns 404, never 403.

  • 422The body did not validate
    • The per page field must not be greater than 100.

    message carries the first problem, errors names every field and what is wrong with it. Nothing was written.

  • 429Too many requests
    • Too Many Attempts.

    120 requests per minute per key. Every response carries X-RateLimit-Limit and X-RateLimit-Remaining, so pace on those rather than waiting for the 429. Retry-After gives the seconds to wait.

422 · a validation failure
{
  "message": "The bedrooms field must not be greater than 20.",
  "errors": {
    "bedrooms": [
      "The bedrooms field must not be greater than 20."
    ],
    "surface_sqm": [
      "The surface sqm field must be an integer."
    ]
  }
}

Rate limits and paging

120 requests per minute, counted per key.

Every response carries X-RateLimit-Limit and X-RateLimit-Remaining. Over the limit you get a 429 and a Retry-After header in seconds.

Both list endpoints page the same way: per_page defaults to 25 and caps at 100, page starts at 1. Both return a meta block with the current page and the last one.

Use updated_since instead of walking the whole catalogue on every run.

Paging metadata
{
  "meta": {
    "page": 1,
    "per_page": 25,
    "total": 128,
    "last_page": 6
  }
}

Reference integration

A nightly sync, in five calls

Run these in order, once a night or after a change in your own system.

  1. 1

    Check the key

    Once, at the start of the run. Stop here if the scopes are not what you expect.

  2. 2

    Push each listing

    One PUT per unit, keyed on your own reference. Safe to repeat with an unchanged body.

  3. 3

    Push the gallery

    One POST per photo. The URL is the identity, so re-posting the same gallery updates rather than duplicates.

  4. 4

    Push the calendar

    One PUT per unit, split into windows. Read skipped in the response: those nights are sold and your side needs to close them.

  5. 5

    Read back what was sold

    Filter on updated_since and stop offering those nights on your own site.

Behaviour to know

Six behaviours that are deliberate and are not visible from the parameter tables alone.

A sold night is never released

Pushing available: true for a night held by a live reservation does not reopen it. The night comes back in the skipped array instead. Read that array: those nights are sold and your own site must stop offering them.

What makes a listing publicly visible

status.publicly_visible is recomputed from six conditions, all of which must hold: listed is true, the listing is not on a quality hold, it has at least two photos, it has a price, that price falls between roughly 500 and 50,000 USD a month, and your account is active and listed on the marketplace. status.review is not one of them, so a listing can be publicly visible while review still reads pending.

Prices are in your account currency

You never send a currency. It is taken from your payout settings. The visibility band above is applied to the USD equivalent, not to the figure you sent.

Listings are addressed by your own reference

No property response carries a RentRemote numeric ID. A reference on another account returns 404, never 403, so the API never confirms that a reference exists elsewhere on the platform. The only internal ID returned is the image ID, which DELETE needs.

A photo is identified by its URL

Posting a URL already on the listing updates it in place and returns 200 instead of 201, so re-posting the same gallery nightly does not duplicate it. That update replaces rather than merges: send title, type and order every time.

Bookings carry no guest data

Reservation responses carry dates, nights and status. No name, no contact details, no amounts. Staff who need that use the reservation page in RentOS.

Getting a key

Keys are issued by RentRemote, scoped to your account, and shown once at creation. There is no self-service key page.

Ask your account manager, or contact us, and state which of the 7 scopes your integration needs. A two-way sync uses all of them. Publishing inventory only needs properties:write, images:write and availability:write.

Rotation works the same way. The old key stops working the moment the new one is issued, so plan the swap into a deploy.

Storing the key
# Keep it out of your repository.
export RENTREMOTE_API_KEY="…"

curl "https://rentremote.com/api/public/v1/ping" \
  -H "X-API-Key: $RENTREMOTE_API_KEY"