15.09.2026-3

New fields on devices:upsert and locations:upsert, fields that are now required where they previously were not, and a new way to list only what has changed since your last pass.

These change what a valid upsert looks like

Unlike the corrections in 15.09.2026-1, which documented rules the platform already applied, the requirements below are new. Review your upsert payloads before they become enforced.

New fields

device.panel

The physical display panel, in millimetres:

{
  "panel": { "widthMm": 1085, "heightMm": 610 }
}

Both dimensions are needed — one without the other describes nothing. The diagonal that supply-side platforms ask for is computed from them (a 1085 × 610 mm panel registers as 49″), so the two can never disagree. A device whose panel size we do not hold cannot be described completely to an exchange that requires one.

device.deployment.guaranteed

Whether the device sells guaranteed deals. Guaranteed outranks the bid round, so a device that accepts it may serve a deal that is behind pace before any bidding happens. A device that declines skips guaranteed entirely.

Value	Means
GUARANTEED_UNSPECIFIED	Never answered. Sells guaranteed.
GUARANTEED_ACCEPTED	Sells guaranteed.
GUARANTEED_DECLINED	Opted out.

Guaranteed is on by default — a device sells guaranteed unless its owner opts out.

Now required

Field	On	Why
timezone	Location	Opening hours are meaningless without the zone they are evaluated in.
supportedLanguages	Location	Booking is language-keyed; a location declaring none exposes no bookable formats.
panel (+ both dimensions)	Device	A screen with no known size cannot be offered to an exchange that needs one.
deployment	Device	It carries how the device sells, including guaranteed.
deployment.guaranteed	Device	Answered explicitly rather than inferred.

Remember that *_UNSPECIFIED counts as absent, so "guaranteed": "GUARANTEED_UNSPECIFIED" does not satisfy the requirement — send GUARANTEED_ACCEPTED or GUARANTEED_DECLINED.

What to do

Add panel, deployment and deployment.guaranteed to your device upserts, and timezone and supportedLanguages to your location upserts. Because an upsert replaces the whole resource, these belong in every request, not only the first.

See Devices and Locations.

Listing only what changed

Both listings accept a modifiedSince filter: only resources whose metadata.lastUpdatedAt is strictly after the instant you give, as an RFC 3339 timestamp. It is for incremental sync — record the highest lastUpdatedAt you have seen, then pass it back on the next poll instead of walking the whole estate.

It sits in a different place on each listing, matching the shape each one already has:

// POST /v1alpha/inventory/devices
{ "modifiedSince": "2026-09-01T00:00:00Z" }

// POST /v1alpha2/inventory/locations
{ "filters": { "modifiedSince": "2026-09-01T00:00:00Z" } }

For locations, this compares the canonical record — the agreement across all partners. An edit to one partner’s version that leaves the agreed values unchanged does not bring the location back.

Keep your paging stable

Filtering by a timestamp and ordering by that same timestamp is how a walk silently skips a row: an edit moves a resource between pages while you are part-way through.

• Locations — a new sort field, LOCATION_SORT_FIELD_FIRST_CREATED_AT, is fixed when the location is first registered. Pair it with modifiedSince, rather than sorting by storeSubchain, merchant or city, which an edit can move.
• Devices — nothing to do. The listing is ordered by an identifier that never changes after registration, so pages hold on their own.