Updates listing details. Send any subset of the fields below; omitted
fields are left unchanged, and null clears a nullable field. Each
field documents its own constraints — values that violate them return
400.

Enabling a listing. Turning on messaging, availability, or pricing
enables the listing — you're billed for any enabled listing, and turning
all three off disables it. Enable them individually, but turning on
availability or pricing also turns on messaging.

Enabling sync. Turning on syncPricing or syncAvailability returns
400 if the listing's Airbnb account is in setup mode (no calendar
permission — reconnect in full mode first), or it's a co-hosted listing
whose owner hasn't granted sync permission yet. syncPricing also needs
an effective minNights of at least 1 (sent in the request or already
stored), and neither toggle can be enabled while turning
messagingEnabled off — messaging is the master switch. When a sync
toggle change triggers an immediate Airbnb push, the response includes
syncPushed (false = push failed but settings are saved; the next
periodic sync reconciles).

Which fields reach which channel. The listing's content is saved in
Host Tools first. Afterwards, while the listing's content sync is on
(see Content sync below), only the fields this request changed are
pushed in the background to each channel the listing is on. A field you
didn't send is never re-sent, so an edit the host made on the channel
stays. Check the outcome in contentSyncStatus from
/api/getListing/{listingID}. Airbnb and VRBO receive the fields in
this table, and only while content sync is on; a dash means the field
isn't sent there. What Booking.com receives is listed after it:

Airbnb's summary and VRBO's description are different fields here:
notes.shortDescription and notes.description. To show the same text
on both channels, send it in both. The same goes for Airbnb's other
sections (notes.space and the rest): VRBO only gets
notes.description, which they don't change. VRBO saves the headline and
description together, so when only one of them changed, the other goes
as VRBO has it.

Photos. A photo push makes the channel's photos match the
listing's. A photo the channel refuses (too small, a file that can't be
downloaded) is left out there and the others still go. The push's
contentSyncStatus error names the photo and the reason, and the
photo is sent again with the listing's next push. VRBO takes JPG, PNG
or GIF photos of at least 1024×683, up to 20 MB, and needs at least 6
on a listing: a push that would leave it fewer deletes none of VRBO's
photos, and says why.

Fees. While content sync is on, the listing's fees go to Airbnb,
VRBO, Booking.com and Houfy, each as the channel's fee of the same kind
(cleaning, linens, pet and so on). The kind is picked for each fee in Host Tools' listing
editor, or sent as the fee's kind, so a fee's name doesn't decide
where it goes and renaming it changes nothing on a channel. A fee kind the listing has is set on the
channel, one it had and then deleted is removed there, and a fee the
channel has that the listing never had is left as it is. A fee a
channel can't take isn't sent there: a kind it doesn't have, a
per-night fee on Airbnb, a percentage fee on VRBO, a pet fee on VRBO
charged per pet or on a listing that doesn't allow pets
(policy.petPolicy.allowedPets unset or NotAllowed; one sent
before is removed from VRBO when pets stop being allowed), a pet fee,
deposit or extra-guest fee on Booking.com or Houfy. Airbnb, VRBO and
Booking.com take one fee of each kind, so a second one (two cleaning
fees) isn't sent. VRBO also takes at most 6 fees besides cleaning,
extra guests and pets (the first 6 in the list go), and no fee over
20,000.
The answer's skipped lists them when the request changes which fees
can't be sent, and each fee's notSentTo in
/api/getListing/{listingID} says which channels won't get it, and
why. They don't make a contentSyncStatus error or an error
webhook, as nothing went wrong; a fee the channel answered for but
didn't keep does. While content sync is on, the fees on
Host Tools' Airbnb Settings page are read-only. Taxes are never sent.

Booking.com. While content sync is on, these go to the listing's
room on Booking.com:

• maxGuests (the room's maximum guests). Booking.com keeps how many
  of the guests may be adults, children and infants beside the
  maximum. When maxGuests changes, a limit at its usual place moves
  with it (adults equal to the guests, children and infants one
  fewer), and one the host set differently stays, lowered only to
  still fit.
• space with spaceUnit (its size, from 1 to 9999.99, sent only
  when both are set).
• policy.smokingAllowed (smoking or non-smoking).
• bedroomConfiguration: each bedroom and living room with its beds,
  replacing the room's on Booking.com, as Booking.com saves them
  together. Their order doesn't count. On a room type that is a single
  room (a double, a studio), every bed of the listing goes as the
  room's beds, and the other bed choices Booking.com offers on it
  stay. Booking.com's bed types are single (a twin goes as one),
  double, king (our queen), super-king (our king), bunk, sofa bed and
  futon; other beds aren't sent. A room with none of those beds is
  left out, as Booking.com refuses a bedroom without beds, and nothing
  is sent while no room has one.
• amenities whose channels in /api/getListingContentOptions
  include Booking and that Booking.com lists for a room, such as the
  kitchen, the TV or a washing machine: each is ticked or unticked on
  the room. A room facility Booking.com has that Host Tools doesn't
  (a minibar, slippers) is left as it is.
• bathrooms, in whole bathrooms, as Booking.com has no half
  bathroom: 2.5 goes as 2. A missing one is added as a private
  bathroom inside the unit, and the room's own keep their details.
• Photos (changed through the photo endpoints): the room's photo
  gallery on Booking.com ends up with the listing's photos, in the
  listing's order, and so does the property's gallery, which every
  room of the property shows, with the listing's first photo as the
  property's main photo. On a property with several rooms, the listing
  whose photos changed last sets them. Booking.com downloads a new
  photo from its url and takes a few minutes to process it, so the
  galleries change once it has. Nothing is deleted on Booking.com: a
  photo that leaves a gallery stays on the property, and in any other
  room's gallery. The property's smart ordering is left as the host
  set it, so while it's on, Booking.com may show the property's
  gallery in an order of its own. Captions aren't sent, as Booking.com
  has none, so changing only a caption sends nothing there. A photo
  Booking.com can't process is left out
  and named in the contentSyncStatus error, as is each new photo
  once the property holds Booking.com's limit of 299. A photo imported
  from Booking.com is only a small preview in Host Tools, so one
  Booking.com no longer has isn't sent back. Removing every photo
  isn't sent, and a property whose connection to Host Tools doesn't
  include Photos gets none: the error says so.
• fees (see "Fees" above) as the room's charges, from today in the
  listing's time zone, for every guest. A room's charge replaces the
  property's charge of the same type for that room, so a fee deleted
  here leaves the room with the property's charge, if it has one.
  management goes as Booking.com's service charge, and a percentage
  as a percentage of the room's price. Booking.com charges a pet fee to
  every guest, so it isn't sent.

And these go to the listing's property on Booking.com, which every
room of it shares. On a property with several rooms they end up as the
last synced listing's, and a push sends only the ones changed on its
own listing:

• name as the property's name. A listing imported from Booking.com
  is named after the property and the room (Casamare - 727764306),
  and the room's id isn't sent with it. A name Booking.com would
  refuse isn't sent, and the answer's skipped says why: one with
  fewer than 3 letters, more than 5 digits in a row, emoji or Chinese
  characters, or fewer than 3 or more than 255 characters. Punctuation
  and capitals are fine. The room keeps its own name on Booking.com.
• checkInTime (when check-in starts) and checkOutTime (when
  check-out ends). When check-in ends and check-out starts stay as
  Booking.com has them.
• policy.petPolicy.allowedPets and policy.childrenAllowed. The
  pets' price type and the children's ages stay as Booking.com has
  them.
• notes.description (English text) as the property's description.
  Booking.com says it may rewrite it or not use it, and takes 3 hours
  or more to show a change.
• amenities Booking.com lists for the whole property, such as a
  garden, an elevator or a hot tub: each is ticked or unticked there,
  so one the listing doesn't have is unticked for every room.
  Parking, the internet, a pool, a restaurant and meals need details
  Host Tools doesn't hold and aren't sent. Booking.com may untick an
  amenity along with another it depends on, such as a private beach
  area with the beach.

The address isn't sent to Booking.com.

A value the room or the property already has there isn't sent. A value
Booking.com refuses, such as more guests than the room type allows, is
named in its contentSyncStatus error, and the other fields still go.
A room Booking.com no longer sells gets nothing, and no error: its
changes go once it's listed again.

Houfy. While content sync is on, these go to the listing on Houfy:

• name as its listing name, and as its headline too.
• notes.description (English text) as its description, and
  notes.houseRules (English text) as its house rules.
• checkInTime (8 to 23, or 0 and 1, which Houfy calls midnight and
  1AM the next day) as when check-in starts, and checkOutTime. When
  check-in ends stays as Houfy has it.
• maxGuests.
• bedrooms when it's at least 1, and bathrooms, a .5 too. 0
  bedrooms isn't sent: an import from Houfy stores 0 for a listing
  whose rooms Houfy doesn't list, so it can't be told from a count
  Houfy has.
• space with spaceUnit, in whole square feet or meters. A space
  of 0 clears the size on Houfy.
• propertyTypeId as Houfy's type of the same kind, when its
  channels include Houfy. Houfy takes only the types its listing
  editor offers for the listing's kind (vacation rental, multi-room
  listing or boat), so it refuses a hotel on a vacation rental, for
  example. A type Houfy refuses is named in the contentSyncStatus
  error, and the other fields still go.
• amenities whose channels include Houfy, each ticked or
  unticked there. A Houfy amenity or view Host Tools doesn't have (a
  doorman, a city view) is left as it is.
• fees (see "Fees" above). Houfy has no list of fees: each goes by
  its name, and a fee whose kind is other too, one per name. Houfy
  keeps a pet fee, a deposit and an extra-guest fee in its own
  settings, so they aren't sent, nor is a fee per guest past a number
  of guests. Houfy has no way to remove a fee through its API, so a fee
  deleted here stays there, and the contentSyncStatus error names it
  until it's removed on Houfy.
• Photos (changed through the photo endpoints): the listing's photos,
  in its order, with their captions. The first is the cover, and
  photos on Houfy the listing doesn't have are deleted there. A photo
  Houfy turns away or can't download is named in the
  contentSyncStatus error and sent again on the next push.

A value Houfy already has isn't sent. Houfy isn't sent rooms or beds.

Other fields are not sent to any channel yet, including the address
and the rest of policy. Nothing else is sent to Booking.com or
Houfy. A text or amenities you clear is not sent, so
it doesn't clear the channel's copy.

Rules. These return 400 and save nothing:

• name must be at least 10 characters (spaces don't count) on every
  listing, and at most 50 on a listing on Airbnb or 80 on one on VRBO
  (the shorter applies on both). Only a name that differs from the
  listing's is checked, so re-sending a listing's current name is fine,
  even one saved before these rules.
• checkInTime must be 8–23 and checkOutTime 10–23 on every
  listing, on Airbnb or not: the hours Airbnb takes. Only a time that
  differs from the listing's is checked, so re-sending a listing's
  current time is fine, even one saved before these rules. An earlier
  time like that isn't sent to Airbnb, which keeps its own.
• Each amenity and bed type the request adds must be supported by at
  least one channel the listing is on that Host Tools sends content
  to: Airbnb, VRBO, Booking.com and Houfy (Houfy isn't sent beds, so it
  doesn't count for bed types). Each channel is only sent the
  amenities and bed types it supports. The property type the request
  adds must be supported by every one of those channels but
  Booking.com, which isn't sent one. An option's channels in
  /api/getListingContentOptions say which channels support it. The
  error names each value and the channels that don't support it, for
  example Amenity "HAC6043" is not supported on Airbnb or VRBO. or
  Property type "aparthotel" is not supported on VRBO. A listing on
  none of them accepts any option. A value the listing
  already has is always
  accepted, so writing back what /api/getListing/{listingID}
  returned still works. An old code that no channel supports counts as
  unsupported.

What isn't refused. Anything else is saved and answered with
200. While the listing's content sync and messagingEnabled are both
on, a change a channel won't be sent is listed in the answer's
skipped, with the reason in words you can show the user: house rules
VRBO can't hold, a fee a channel doesn't take, or a name Booking.com
would refuse. A channel can also refuse a value when it's pushed, such
as a text longer than a limit the channel doesn't publish. The push
runs after this answer, so that refusal shows up later: in
contentSyncStatus.<channel>.lastError from
/api/getListing/{listingID}, as a type: "error" webhook with the
code listing.contentSyncFailed, and in /api/getErrors. It stays
there until a later push to that channel goes through.

Content sync. Send contentSyncEnabled: true to make Host Tools'
copy the source of the listing's content on every channel:

• Turning it on pushes every field in the table above to the listing's
  channels straight away, photos and fees included (see Fees), so
  each channel matches Host Tools from then on. Airbnb's and VRBO's
  photos that Host Tools doesn't have are deleted. On Booking.com they
  leave the room's gallery and the property's, and stay on the
  property. A fee the channel
  has that the listing never had is left as it is. A value Host Tools
  doesn't have, such as an empty text or a photo without a caption,
  isn't sent, so the channel keeps its own.
• false turns it off and leaves the content as it is.
• While it's off, no listing content (fields, photos or fees) is sent
  to any channel. Prices and availability still follow their own
  sync settings. The Airbnb title, guest capacity, property type,
  bedroom, bathroom and bed counts, amenities, check-in method and
  instructions, and check-in and checkout times used to go to Airbnb
  with it off; they now wait for it too (see the changelog).