Skip to content

Listing Customizations

Endpoint Method Scope Description
/api/v1/listings/<id>/customizations/ GET listings:read Get all customizations for a listing in one response
/api/v1/listings/<id>/customizations/base-price/ GET listings:read Get base price customization for a listing
/api/v1/listings/<id>/customizations/base-price/ PATCH listings:write Update base price customization for a listing
/api/v1/listings/<id>/customizations/min-stays/ GET listings:read Get min-stays customization for a listing
/api/v1/listings/<id>/customizations/min-stays/ PATCH listings:write Update min-stays customization for a listing
/api/v1/listings/<id>/customizations/extra-guest-fees/ GET listings:read Get extra guest fee customization for a listing
/api/v1/listings/<id>/customizations/extra-guest-fees/ PATCH listings:write Update extra guest fee customization for a listing
/api/v1/listings/<id>/customizations/min-max-prices/ GET listings:read Get min/max prices customization for a listing
/api/v1/listings/<id>/customizations/min-max-prices/ PATCH listings:write Update min/max prices customization for a listing
/api/v1/listings/<id>/customizations/time-based-adjustments/ GET listings:read Get time-based adjustments customization for a listing
/api/v1/listings/<id>/customizations/time-based-adjustments/ PATCH listings:write Update time-based adjustments customization for a listing
/api/v1/listings/<id>/customizations/manual-overrides/ GET listings:read Get manual price overrides for a listing
/api/v1/listings/<id>/customizations/manual-overrides/ PATCH listings:write Update manual price overrides for a listing
/api/v1/listings/<id>/customizations/occupancy-based-pricing/ GET listings:read Get occupancy-based pricing customization for a listing
/api/v1/listings/<id>/customizations/occupancy-based-pricing/ PATCH listings:write Update occupancy-based pricing customization for a listing
/api/v1/listings/<id>/customizations/checkin-checkout-days/ GET listings:read Get check-in/check-out days customization for a listing
/api/v1/listings/<id>/customizations/checkin-checkout-days/ PATCH listings:write Update check-in/check-out days customization for a listing
/api/v1/listings/<id>/customizations/gap-price-adjustments/ GET listings:read Get gap price adjustments customization for a listing
/api/v1/listings/<id>/customizations/gap-price-adjustments/ PATCH listings:write Update gap price adjustments customization for a listing

Try it out

Explore schemas and live requests in the Swagger UI.

Overview

Listing customization endpoints expose the mutable pricing and stay-rule settings that apply to a specific listing. These routes use a stable customizations/ namespace so new customization types can be added later without changing the API version.

These endpoints are listing-scoped. A future release may add a separate namespace for global default customizations.


Supported Customization Types

  • base-price: the listing's nightly base price.
  • min-stays: minimum-night rules for annual, seasonal, day-of-week, lead-time, and gap-fill behavior.
  • extra-guest-fees: per-guest fees that apply when a reservation exceeds the included guest count.
  • min-max-prices: nightly and monthly floor and ceiling pricing, including weekday and seasonal overrides.
  • time-based-adjustments: lead-time discounts and premiums, either dynamic or manually configured.
  • manual-overrides: per-date price overrides that pin or adjust the price for specific dates.
  • occupancy-based-pricing: fine-tuning from the listing's occupancy compared with its market, with optional caps and excluded date ranges.
  • checkin-checkout-days: the weekdays guests may check in and check out, year-round and per season.
  • gap-price-adjustments: discounts and premiums for the nights of short open gaps between bookings, either dynamic or manually configured.

Conventions

  • Use GET to retrieve the current customization state for a listing.
  • Use PATCH to update only the fields you want to change.
  • Request and response bodies follow JSON:API.
  • Field names are dasherized in the HTTP payloads.
  • Every item of a seasonal list (seasonal-*) has a start-date, an end-date, and a rollover flag. Set rollover to true to repeat the season every year on the same dates; a repeating range must be shorter than one year, and its dates are reported in the current year. A seasonal list, when sent, replaces the listing's whole list, repeating seasons included, so the body of a GET can be sent back unchanged.

All Customizations

GET /api/v1/listings/<id>/customizations/ returns every supported customization for a listing in a single listing-customizations resource, so partners can retrieve the full picture without one request per type.

The response is keyed by customization name, and each value is identical to the attributes returned by that customization's own GET endpoint:

  • base-price
  • extra-guest-fees
  • min-max-prices
  • min-stays
  • time-based-adjustments
  • occupancy-based-pricing
  • checkin-checkout-days
  • gap-price-adjustments

To retrieve only a subset, use the JSON:API sparse fieldset query parameter fields[listing-customizations] with a comma-separated list of customization names. For example:

GET /api/v1/listings/123/customizations/?fields[listing-customizations]=base-price,min-stays

returns only the base-price and min-stays customizations. This endpoint is read-only; continue to use the individual customizations/<type>/ endpoints with PATCH to make changes.

manual-overrides is deliberately not part of this aggregate: it is keyed by date rather than by rule, so a single listing can carry hundreds of rows. Read it from its own endpoint, where you can also narrow the date range.


Base Price

Use base-price to set the listing's nightly base price. The base price is the anchor used by Beyond Pricing's algorithm; minimum and maximum prices, seasonal rules, and time-based adjustments are all applied relative to it.

The payload includes:

  • base-price: the nightly base price for the listing, in the listing's currency. Must be at least 10.
{
  "data": {
    "type": "base-price-customizations",
    "id": "123",
    "attributes": {
      "base-price": 189
    }
  }
}

Extra Guest Fees

Use extra-guest-fees to charge an additional fee when a reservation exceeds the number of guests included in the standard rate.

If no extra guest fee is configured, the standard price applies.

The payload includes:

  • extra-guest-fee: the fee charged for each guest above the threshold, in the listing's currency.
  • extra-guest-threshold: the number of guests included before the fee applies.
{
  "data": {
    "type": "extra-guest-fee-customizations",
    "id": "123",
    "attributes": {
      "extra-guest-fee": 25,
      "extra-guest-threshold": 4
    }
  }
}

Minimum Stays

Use min-stays to manage minimum-night requirements for a listing. This customization supports a combination of year-round defaults, weekday overrides, seasonal rules, lead-time rules, and gap-fill behavior.

Minimum stays are applied in the following order:

  1. Seasonal Time-Based Minimum Stays
  2. Time-Based Minimum Stays
  3. Seasonal Minimum Stays
  4. Day of Week Minimum Stays
  5. Annual Minimum Stays

Gap fills apply across minimum stay rules to help protect short orphan gaps in availability.

A GET returns every rule family. Unconfigured families come back as empty lists. This example shows each family configured:

{
  "data": {
    "type": "min-stay-customizations",
    "id": "123",
    "attributes": {
      "min-stay": 2,
      "gap-fill-min-stay": {"enabled": true, "gaps": 3, "buffer": 1},
      "seasonal-min-stays": [
        {"start-date": "2026-12-20", "end-date": "2027-01-05",
         "rollover": true, "min-stay": 5, "min-stay-locked": false}
      ],
      "last-minute-min-stays": [
        {"days-away": 7, "direction": "within", "min-stay": 1}
      ],
      "day-of-week-min-stays": [
        {"weekday": "monday", "min-stay": null},
        {"weekday": "tuesday", "min-stay": null},
        {"weekday": "wednesday", "min-stay": null},
        {"weekday": "thursday", "min-stay": null},
        {"weekday": "friday", "min-stay": 2},
        {"weekday": "saturday", "min-stay": 2},
        {"weekday": "sunday", "min-stay": null}
      ],
      "seasonal-day-of-week-min-stays": [
        {"start-date": "2026-08-28", "end-date": "2026-08-30",
         "rollover": false,
         "min-stays": [
           {"weekday": "monday", "min-stay": null},
           {"weekday": "tuesday", "min-stay": null},
           {"weekday": "wednesday", "min-stay": null},
           {"weekday": "thursday", "min-stay": null},
           {"weekday": "friday", "min-stay": null},
           {"weekday": "saturday", "min-stay": null},
           {"weekday": "sunday", "min-stay": 2}
         ]}
      ],
      "seasonal-gap-fill-min-stays": [
        {"start-date": "2026-07-01", "end-date": "2026-07-31",
         "rollover": true,
         "gap-fill-min-stay": {"enabled": true, "gaps": 1, "buffer": 2}}
      ],
      "seasonal-time-based-min-stays": [
        {"start-date": "2027-01-01", "end-date": "2027-01-22",
         "rollover": false, "exclude": false,
         "time-based-min-stays": [
           {"days-away": 3, "direction": "within", "min-stay": 2}
         ]},
        {"start-date": "2027-04-01", "end-date": "2027-04-15",
         "rollover": false, "exclude": true}
      ]
    }
  }
}

Annual Minimum Stay

Use min-stay to set the default minimum stay across all dates, except where a day-of-week or seasonal rule overrides it. We recommend setting this to the shortest minimum stay you would accept during lower-demand periods.

If the annual minimum stay is left blank, it defaults to a 1-night stay.

Annual Minimum Stays By Day Of Week

Use day-of-week-min-stays to set year-round minimum stays for specific weekdays. These values take precedence over the annual minimum stay. Days set to null inherit the annual minimum stay value.

Seasonal Minimum Stays By Day Of Week

Use seasonal-day-of-week-min-stays to set weekday minimum stays for a date range. Each entry carries a min-stays list with all seven weekdays; days set to null fall back to the lower-precedence rules. Seasonal weekday minimum stays override annual rules and annual weekday rules for their date range. They are still superseded by seasonal minimum stays, time-based minimum stays, and gap-fill rules.

Seasonal Minimum Stays

Use seasonal-min-stays to create date-range specific rules for holidays, events, or other periods of predictable demand. Set rollover to true to repeat the rule every year on the same dates; a repeating range must be shorter than one year. Set min-stay-locked to true to protect the value from automatic changes. These rules override annual and day-of-week minimum stays, but time-based minimum stays and gap fills still take precedence.

Time-Based Minimum Stays

Use last-minute-min-stays to set a minimum stay based on how far away a booking is from today. Each rule carries days-away, a direction (within for dates within that many days, after for dates at least that many days away), and the min-stay to require. These rules take precedence over seasonal minimum stays.

Seasonal Time-Based Minimum Stays

Use seasonal-time-based-min-stays to tailor lead-time rules to specific date ranges so minimum-night requirements can vary by season. Each entry lists its own rules under time-based-min-stays, using the same shape as last-minute-min-stays. Set exclude to true to turn lead-time rules off for the range; an excluding entry carries no time-based-min-stays list.

Gap Fill Minimum Stays

Gap-fill settings apply minimum-stay protections around short openings between bookings. Use gap-fill-min-stay for the year-round setting and seasonal-gap-fill-min-stays for date-range overrides; a seasonal entry wraps its own gap-fill-min-stay object. gaps is the longest opening, in nights, that triggers the rule, and buffer adds extra nights around the gap that still count toward the rule.


Min/Max Prices

Use min-max-prices to define nightly and monthly price floors and ceilings for a listing.

Minimum prices are applied in this order:

  1. seasonal-prices
  2. seasonal-day-of-week-min-prices
  3. day-of-week-min-prices
  4. min-price

All minimum prices are honored by any discounting rules configured for the listing. Prices are in the listing's currency.

A GET returns every rule family (empty lists when unconfigured):

{
  "data": {
    "type": "min-max-price-customizations",
    "id": "123",
    "attributes": {
      "min-price": 95,
      "max-price": null,
      "monthly-min-price": null,
      "day-of-week-min-prices": [
        {"weekday": "monday", "min-price": null},
        {"weekday": "tuesday", "min-price": null},
        {"weekday": "wednesday", "min-price": null},
        {"weekday": "thursday", "min-price": null},
        {"weekday": "friday", "min-price": 120},
        {"weekday": "saturday", "min-price": 120},
        {"weekday": "sunday", "min-price": null}
      ],
      "seasonal-day-of-week-min-prices": [],
      "seasonal-prices": [
        {"start-date": "2026-12-20", "end-date": "2027-01-05",
         "rollover": true, "min-price": 150, "max-price": null}
      ],
      "seasonal-monthly-prices": []
    }
  }
}

Annual Minimum and Maximum Prices

Use min-price and max-price to set default nightly minimum and maximum prices across all dates, except where a day-of-week or seasonal minimum applies. We recommend setting min-price to the lowest nightly price you would accept at any time of year.

Annual Minimum Price by Day of Week

Use day-of-week-min-prices to set year-round nightly minimum prices for specific weekdays. These values take precedence over min-price. Any weekday left blank uses the min-price value.

Seasonal Minimum Prices by Day of Week

Use seasonal-day-of-week-min-prices to set weekday-specific nightly minimum prices for a defined date range. These values take precedence over day-of-week-min-prices, but are superseded by seasonal-prices.

Seasonal Minimum and Maximum Prices

Use seasonal-prices to set nightly minimum and maximum prices for specific date ranges, such as holidays or events. We do not recommend limiting our recommended prices by setting a maximum price.


Time-Based Adjustments

The time-based-adjustments customization supports two operating modes: dynamic time-based adjustments and manual time-based adjustments.

A GET returns both the dynamic settings and any manual rules:

{
  "data": {
    "type": "time-based-adjustment-customizations",
    "id": "123",
    "attributes": {
      "dynamic-time-based-adjustments": {
        "enabled": true,
        "tier": "revenue",
        "median-lead-time": 21
      },
      "time-based-adjustments": [
        {"days": 7, "percentage": -10, "direction": "within"},
        {"days": 270, "percentage": 15, "direction": "after"}
      ],
      "seasonal-time-based-adjustments": []
    }
  }
}

Dynamic Time-Based Adjustments

Dynamic Time-Based Adjustments is a core algorithm feature. When enabled, Beyond updates the listing's discount and premium rules based on the latest booking trends for the market and property type. Keeping this enabled ensures pricing rules are optimized daily to maximize revenue.

When dynamic time-based adjustments is enabled, the user can choose one of the available optimization tiers:

  • revenue
  • occupancy
  • rate

revenue is the default and recommended option.

median-lead-time is the median number of days between booking and arrival for listings of similar size in the listing's neighborhood, the same figure the Beyond dashboard shows next to dynamic time-based adjustments. It describes the market, not a listing setting, so it is returned whether or not dynamic time-based adjustments is enabled. It is read-only: a PATCH that sends it is accepted and the value is ignored. It is null when Beyond has no estimate for the listing's neighborhood.

Manual Annual And Seasonal Adjustments

When dynamic time-based adjustments is disabled, the user can configure manual annual and seasonal time-based adjustments.

Annual Time-Based Adjustments

Annual time-based adjustments help shape pricing across the full booking window. Discounting dates that are coming up soon can help improve short-term occupancy. Increasing prices for dates far in the future can help achieve higher ADRs and avoid booking those dates too quickly.

We recommend always including an increase for dates more than 270 days (9 months) in the future.

Seasonal Time-Based Adjustments

Seasonal time-based adjustments let users tailor discounts and premiums to seasonal demand patterns. For example, you may discount more aggressively in low season and less in high season.

Annual adjustments are pre-loaded for easy customization. Users can adjust the rules as needed and save them to create a seasonal setting.


Occupancy-Based Pricing

When enabled, occupancy-based pricing fine-tunes the listing's prices with discounts and premiums based on its occupancy compared with its market. It is separate from the tier of dynamic time-based adjustments, which steers lead-time rules only.

The payload includes:

  • enabled: whether occupancy-based pricing is applied. The other fields take effect only while it is true; while it is false they are still saved and apply once it is turned back on.
  • tier: the strategy for its discounts and premiums. occupancy favors deeper discounts and lighter premiums, rate favors lighter discounts and stronger premiums, and revenue balances both.
  • min-factor: the largest decrease it may apply, as a fraction between -1 and 0 with up to four decimal places. -0.05 caps decreases at 5%, 0 blocks decreases, and null means no cap.
  • max-factor: the largest increase it may apply, as a fraction between 0 and 1 with up to four decimal places. 0.1 caps increases at 10%, 0 blocks increases, and null means no cap.

Today occupancy-based pricing adjusts a price by at most about 20% in either direction, so a cap wider than that has no effect. - disabled-periods: up to 50 non-overlapping date ranges during which occupancy-based pricing is skipped, such as holidays, local events, or owner stays. end-date is the last skipped date; use the same value for both dates to skip a single date.

{
  "data": {
    "type": "occupancy-based-pricing-customizations",
    "id": "123",
    "attributes": {
      "enabled": true,
      "tier": "revenue",
      "min-factor": -0.05,
      "max-factor": 0.1,
      "disabled-periods": [
        {"start-date": "2026-12-24", "end-date": "2026-12-26"}
      ]
    }
  }
}

PATCH changes only the fields you send. disabled-periods, when sent, replaces the listing's whole list: include every period you want to keep, or send [] to remove them all. A request with overlapping periods is rejected with 400 and changes nothing.


Check-In and Check-Out Days

Use checkin-checkout-days to restrict the weekdays guests may arrive and leave. Beyond pushes these rules to the listing's channel, so what you can set depends on that channel. The read-only channel-support object reports it for the listing's primary channel:

  • checkin-days: the channel accepts check-in days. When false, every PATCH to this customization returns 422.
  • checkout-days: the channel accepts check-out days separately. When false, Beyond may replace the check-out days you send with the check-in days.
  • seasonal-checkin-days / seasonal-checkout-days: the channel accepts date-specific days. When seasonal-checkin-days is false, seasonal-checkin-checkout-days accepts only [].
  • day-selection / seasonal-day-selection: single means each day list must be exactly one weekday or all seven; multi allows any set.
  • changeover-days-gap-fill: whether changeover-days-gap-fill-enabled may be set to true.

The payload includes:

  • checkin-days / checkout-days: the year-round weekdays. Send at least one weekday; all seven means no restriction.
  • seasonal-checkin-checkout-days: date ranges that override the year-round days. end-date is the last date the season applies. A season lists at least one weekday in checkin-days or checkout-days; the other may be empty ([]) or null when the season restricts only one side. Set rollover to true to repeat the season every year on the same dates; the range must be shorter than one year, and its dates are then reported in the current year.
  • changeover-days-gap-fill-enabled: whether orphan changeover gaps keep adjacent check-in/check-out rules active.
{
  "data": {
    "type": "checkin-checkout-day-customizations",
    "id": "123",
    "attributes": {
      "changeover-days-gap-fill-enabled": true,
      "checkin-days": ["friday", "saturday"],
      "checkout-days": ["monday", "sunday"],
      "seasonal-checkin-checkout-days": [
        {
          "start-date": "2026-11-01",
          "end-date": "2026-11-03",
          "checkin-days": ["saturday"],
          "checkout-days": ["saturday"],
          "rollover": false
        },
        {
          "start-date": "2026-12-20",
          "end-date": "2026-12-27",
          "checkin-days": ["sunday"],
          "checkout-days": ["sunday"],
          "rollover": true
        }
      ],
      "channel-support": {
        "checkin-days": true,
        "checkout-days": true,
        "seasonal-checkin-days": true,
        "seasonal-checkout-days": true,
        "day-selection": "multi",
        "seasonal-day-selection": "multi",
        "changeover-days-gap-fill": true
      }
    }
  }
}

PATCH changes only the fields you send; channel-support is ignored. seasonal-checkin-checkout-days, when sent, replaces the listing's whole list: include every season you want to keep, or send [] to remove them all. Weekdays are returned in calendar order, so a GET body can be sent back unchanged.


Gap Price Adjustments

Use gap-price-adjustments to price the nights of short open gaps between two bookings, which are hard to fill at the full rate. Like time-based adjustments, it supports two operating modes: dynamic and manual.

A GET returns the dynamic setting, the listing's manual rules, whether those are Beyond's defaults, and the default rules themselves:

{
  "data": {
    "type": "gap-price-adjustment-customizations",
    "id": "123",
    "attributes": {
      "dynamic-gap-price-adjustments": {"enabled": false},
      "gap-price-adjustments": [
        {"days": 1, "percentage": -29, "excluded-days-of-week": []},
        {"days": 2, "percentage": 15, "excluded-days-of-week": ["friday", "saturday"]}
      ],
      "is-default": false,
      "default-gap-price-adjustments": [
        {"days": 1, "percentage": -30, "excluded-days-of-week": []},
        {"days": 2, "percentage": -20, "excluded-days-of-week": ["friday"]},
        {"days": 3, "percentage": -10, "excluded-days-of-week": ["thursday", "friday"]}
      ]
    }
  }
}

Dynamic Gap Price Adjustments

When dynamic-gap-price-adjustments.enabled is true, Beyond adjusts gaps of up to 3 nights from market-specific booking trends, and the manual rules are not applied. Minimum stay rules are still honored. The feature is only available in some markets: elsewhere, a request to enable it is ignored and the response keeps enabled: false.

Manual Gap Price Adjustments

While dynamic mode is disabled, each rule in gap-price-adjustments applies to every night of an open gap of exactly days nights (1 to 32767):

  • percentage: a whole-number percent applied to the night's price, where -30 means -30% and 15 means +15%. It must be between -99 and 999 and not 0.
  • excluded-days-of-week: optional. Gap nights falling on these weekdays keep their unadjusted price — for example, a Friday night in a two-night gap is often easy to book. Omit it to adjust every night of the gap.

Two rules for the same days must not adjust the same weekday; split the week between them with excluded-days-of-week instead.

A PATCH with gap-price-adjustments replaces the whole list: rules you leave out are removed, and an empty list removes every rule. This request switches the listing to manual mode with two rules:

{
  "data": {
    "type": "gap-price-adjustment-customizations",
    "id": "123",
    "attributes": {
      "dynamic-gap-price-adjustments": {"enabled": false},
      "gap-price-adjustments": [
        {"days": 1, "percentage": -29, "excluded-days-of-week": []},
        {"days": 2, "percentage": 15, "excluded-days-of-week": ["friday", "saturday"]}
      ]
    }
  }
}

Default Rules

default-gap-price-adjustments holds Beyond's default manual rules. They are the same for every listing and cannot be changed. A listing that never saved its own rules is priced with them: gap-price-adjustments returns them and is-default is true.

is-default becomes false once the listing saves rules that differ from the defaults. It stays false even after every rule is removed, so a listing with no rules does not fall back to the defaults. To restore them, send default-gap-price-adjustments as gap-price-adjustments: the listing then keeps them as its own rules, which price the same, and is-default stays false. Both read-only fields are ignored in a PATCH.

Manual rules cannot be changed while dynamic mode is enabled, including in the request that enables it: such a PATCH is rejected with 422. Send "dynamic-gap-price-adjustments": {"enabled": false} to change the manual rules. Rules sent unchanged, in any order, are accepted, so the body of a GET can be sent back as is.


Manual Overrides

Every other customization describes a rule Beyond applies while pricing. Use manual-overrides when you want to take over specific dates instead, the same way the Beyond web calendar's "Manual Override" panel does.

Each entry in overrides covers a date range and carries at most one of:

  • price: a fixed nightly price. Beyond stops repricing those dates and publishes exactly this amount until you remove the override. A fixed price is accepted even when it falls below the listing's minimum price — an explicit override outranks the floor.
  • percentage-adjustment: a percentage applied to Beyond's modeled price, where 10 means +10% and -10 means -10%. The price keeps moving with the model; the adjustment is applied after every other pricing factor.

The two are mutually exclusive on any given date: setting one clears the other. An entry with neither value clears both, returning the dates to fully modeled pricing.

Each entry accepts:

  • start-date / end-date: the range the override applies to. Use the same value for both to override a single date. Dates that have already passed in the listing's timezone are rejected.
  • days-of-week: optional. Restricts the override to the named weekdays within the range — for example, only Fridays and Saturdays. Omit it to cover every date in the range.

PATCH is additive: dates you do not mention keep whatever override they already had. To remove overrides, send an entry with no value for the dates you want cleared.

Reading overrides back

GET returns one entry per overridden date, with start-date equal to end-date, so a response body can be sent straight back as a request body. Dates with no override are omitted entirely.

Narrow the window with filter[start-date] and filter[end-date] (YYYY-MM-DD). The default window is today through today + 365 days in the listing's timezone.

GET /api/v1/listings/123/customizations/manual-overrides/?filter[start-date]=2026-06-01&filter[end-date]=2026-06-30
{
  "data": {
    "type": "manual-override-customizations",
    "id": "123",
    "attributes": {
      "overrides": [
        {"start-date": "2026-06-05", "end-date": "2026-06-05", "price": 250,
         "percentage-adjustment": null},
        {"start-date": "2026-06-06", "end-date": "2026-06-06", "price": null,
         "percentage-adjustment": 10}
      ]
    }
  }
}

To see which dates on the pricing calendar carry an override without fetching this resource, read price-override-type on the calendar entries.


Errors

All customization endpoints share the same error behavior. Writes are applied through Beyond's pricing engine, and its rejections are normalized into standard JSON:API error responses with the matching status code.

Status Cause
400 Malformed body or a value failing validation. Examples: base-price below 10, missing weekdays in a day-of-week set, a backwards date range, a rollover range of one year or more, a one-off range ending more than 5 years from today, a minimum price above the maximum, a manual override on a past date, or a range overlapping an earlier one in the same list. source.pointer names the list item, and the field when one is at fault.
401 Missing or invalid bearer token.
403 Token lacks the required scope (listings:read for GET, listings:write for PATCH), or the credential has no edit access to the listing.
404 No listing with that id is visible to your application.
422 The update is semantically impossible for the listing — e.g. manual gap price adjustments while dynamic gap price adjustments are enabled, a feature the listing's managed account does not support, or check-in/check-out days the listing's channel does not accept (see channel-support).
429 Rate limit exceeded. See Rate Limiting.