GraphQL Admin API 2026-10: exclusive > timestamp filters now exclude the full second

What changed

As of GraphQL Admin API version 2026-10, an exclusive lower bound (>) on a timestamp filter excludes the full second. This applies to the [search syntax](https://shopify.dev/docs/api/usage/search-syntax) used in the query argument of a connection.

The API returns timestamps such as createdAt to the second, but some resources store them internally with fractional seconds. That gap is the cause of the change.

Before 2026-10, created_at:>'2026-09-15T12:00:02Z' compared against 12:00:02.000000. It returned records created later in that second, and the response showed those records with createdAt: "2026-09-15T12:00:02Z". The same records also matched created_at:<='2026-09-15T12:00:02Z'.

As of 2026-10, when a > value has no fractional seconds, the filter starts after the end of that second (12:00:02.999999). A record matches >T only when the timestamp the API returns for it is later than T. So >T and <=T no longer overlap. For example, created_at:>'2026-09-15T12:00:02Z' no longer returns an order created at 12:00:02.500.

These filters don't change on any version:

• >=, < and <=

• Date-only values, such as created_at:>2026-09-15

• Values with fractional seconds, such as created_at:>'2026-09-15T12:00:02.250Z'

Who is affected

The change affects apps that send a > bound without fractional seconds on a timestamp filter in the query argument of a GraphQL Admin API connection. An example is created_at on the orders query, where created_at is a time field.

Apps that only use >=, <, <=, date-only values or values with fractional seconds are not affected, because those filters behave the same on every version.

Apps on 2026-07 or earlier see no change. The new behaviour applies only to requests made on 2026-10.

What to do

Apps on 2026-07 or earlier don't need to change anything. Before you move an app to 2026-10, check its > filters.

• Find queries that pass a timestamp from an earlier response as a > bound, for example sync logic that fetches records newer than the last record the app saw.

• If the app must not miss records created later in that same second, use >= with that timestamp instead, and remove duplicates by id.

The >= filter is unchanged in 2026-10. It will return the record the app already has, which is why the id check is needed.

query OrdersSinceLastSync {
  orders(first: 50, sortKey: CREATED_AT, query: "created_at:>'2026-09-15T12:00:02Z'") {
    nodes {
      id
      createdAt
    }
  }
}

query OrdersSinceLastSync {
  orders(first: 50, sortKey: CREATED_AT, query: "created_at:>='2026-09-15T12:00:02Z'") {
    nodes {
      id
      createdAt
    }
  }
}

Deadline

Shopify has not announced a calendar deadline for this change. The changelog entry is dated 19 October 2026, but that is the date it was announced, not a date by which you must act.

The behaviour changes for an app when it starts sending requests with API version 2026-10. Apps on 2026-07 or earlier keep the current behaviour for as long as that version stays accessible.

The versioning page lists 2026-07 as accessible until July 16, 2027 15:00 UTC, and 2026-10 as the latest stable version. After a version stops being accessible, Shopify falls forward to the oldest accessible stable version, so an app still on 2026-07 after that date would be served by a newer version. The versioning page doesn't say which version that would be on that date, so check the > filters in any app before that point.