Skip to main content
A listing that comes from a Connect feed is maintained in the seller’s own application, and the fields that feed supplies are overwritten on every import. So changing one through the API is not a change at all: it would last until the next run and then quietly disappear. Rather than accept it and undo it, we refuse it:
The error names the fields, so a client can show which ones to change at the source instead. It names them as we store them: shipping_costs for shippingCosts, certificate for papers, uploads for the gallery. A listing says whether a feed maintains it in feedManaged, so a client can know before it tries.

What the feed owns

Its own columns — name, reference, description, price, price on request, shipping, box, papers, warranty, the model, the reference it was matched to (referencedWatchUuid), the dealer product code — plus the specifications and the gallery. Both ways of giving a listing photographs land in the gallery, so imageSources and imageHandles are refused on a feed listing too. Deleting one is refused for the same reason, with a 409 feed_managed that says to remove it there: the next import would bring it straight back. A feed listing disappears when it leaves the feed.

What is still yours

Everything the feed does not supply. Marking a feed listing sold keeps working, because status is not something the feed writes — and that is usually the thing an integration actually needs.
This is the only inventory-ownership rule there is. Everything that is not from a feed belongs to the seller, whether they change it in the dashboard, in the app or over the API. Those are the same thing.