listing_inactive
The listing this request addresses is inactive. Activate it to read or change it through the API.
When it fires
The request addresses a listing that is inactive in your workspace. It can address it directly (GET /v1/properties/4118), through a channel id (an Airbnb listing or a Booking.com property mapped to it), or through data that belongs to it: a reservation, a conversation or its messages, a review, a guest whose every reservation is on inactive listings, availability, pricing, content, photos, a publish call, or a quote.
An inactive listing is not billed and does not count toward your plan's listing limit. Its data keeps syncing, so nothing is lost, but the API will not read or change it until you activate it. Listings become inactive when you deactivate them, when you disconnect the account they came from, or when a new Airbnb listing is imported while it is unlisted on Airbnb. See Active & inactive listings.
When a request names several listings (for example PATCH /v1/availability/batch) and any of them is inactive, nothing is written and listing_ids names every inactive one.
The not-found check runs first: an id that is not in your workspace is still a 404 not_found, never a 403.
Response shape
Every Repull error follows the same envelope. The code is stable and safe to switch on.
{
"error": {
"code": "listing_inactive",
"message": "Listing 4118 is inactive. Its data is kept and still syncing, but it cannot be read, changed, or receive webhooks until it is activated.",
"fix": "Activate it with `PATCH /v1/listings/4118` and body `{\"active\": true}`, or several at once with `POST /v1/listings/status`. Active listings count toward your plan's listing limit.",
"docs_url": "https://repull.dev/docs/errors/listing_inactive",
"request_id": "req_01J5X7Y8Z9ABCDEF12345678",
"listing_ids": ["4118"]
}
}How to fix
- Read `error.listing_ids` — the inactive listings this request touched.
- Activate one with `PATCH /v1/listings/{id}` and body `{"active": true}`, or several at once with `POST /v1/listings/status` and body `{"listingIds": [...], "active": true}`.
- Retry the original request. The listing is complete: its data kept syncing while it was inactive.
- If activation returns `402 listings_limit_exceeded`, your plan cannot hold another active listing. Deactivate one you no longer need, or upgrade, then activate again.
- If you did not mean to use this listing, leave it inactive. Collection endpoints (`GET /v1/reservations`, `/v1/conversations`, `/v1/reviews`, `/v1/guests`) already leave its data out.
Common gotchas
- Do not retry without activating. This is not transient. The same request returns the same 403 until the listing is active.
- Finding inactive listings.
GET /v1/listingsandGET /v1/propertiesreturn active listings by default. Pass?status=inactive(orall) to include inactive ones. Those rows carry identity fields only (id,name,status,channels), enough to pick what to activate. - The toggles always work.
PATCH /v1/listings/{id},DELETE /v1/listings/{id}andPOST /v1/listings/statusaccept inactive listings. Otherwise nothing could be reactivated. - Webhooks. Events about an inactive listing are not delivered, and they are not queued for later: activating resumes delivery for events from that moment on. Replaying an old delivery for a listing that is inactive now also returns this error.
- Filters. Filtering a collection by an inactive listing (
?listing_id=4118) returns this error rather than an empty page, so an empty page always means there is no data.
Examples
curl
# Reading an inactive listing
curl https://api.repull.dev/v1/properties/4118 \
-H "Authorization: Bearer sk_live_YOUR_KEY"
# HTTP/1.1 403 Forbidden
# { "error": { "code": "listing_inactive", "listing_ids": ["4118"], ... } }
# See which listings are inactive
curl "https://api.repull.dev/v1/listings?status=inactive" \
-H "Authorization: Bearer sk_live_YOUR_KEY"
# Activate it, then retry
curl -X POST https://api.repull.dev/v1/listings/status \
-H "Authorization: Bearer sk_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{ "listingIds": ["4118"], "active": true }'
# HTTP/1.1 200 OK
# { "active": true, "updated": ["4118"], "unchanged": [] }TypeScript
const API = 'https://api.repull.dev'
const headers = {
Authorization: `Bearer ${process.env.REPULL_API_KEY}`,
'Content-Type': 'application/json',
}
async function getProperty(id: string) {
let res = await fetch(`${API}/v1/properties/${id}`, { headers })
if (res.status === 403) {
const { error } = await res.clone().json()
if (error.code === 'listing_inactive') {
// Activating counts toward your plan's listing limit. Only do it when
// you actually intend to manage this listing.
const activate = await fetch(`${API}/v1/listings/status`, {
method: 'POST',
headers,
body: JSON.stringify({ listingIds: error.listing_ids, active: true }),
})
if (activate.status === 402) {
throw new Error('Plan listing limit reached. Deactivate a listing or upgrade.')
}
res = await fetch(`${API}/v1/properties/${id}`, { headers })
}
}
return res.json()
}If you're an AI agent
The listing is inactive: not billed, still syncing, but closed to the API. Do not retry as-is. Activating it adds it to the plan's billable listing count, so confirm with the user before activating unless they already asked to work with this listing. Activate with POST /v1/listings/status {listingIds: error.listing_ids, active: true} (or PATCH /v1/listings/{id} {active: true}), then retry. If activation returns 402 listings_limit_exceeded, tell the user the plan is full and ask which listing to deactivate or whether to upgrade.
Related
- Error reference — the full table of error codes
- Using Repull from AI agents — patterns for handling errors in agent loops
- Active & inactive listings
- listings_limit_exceeded (402)
- Webhook retries & replay
Hit an error that isn't covered? Email hello@repull.dev with the request id from the response headers.