[Bug?] giftCards query created_at with full ISO timestamp returns empty; date-only works

GraphQL Admin API Troubleshooting
1

Summary

The Admin API docs for the giftCards query say created_at is a time filter and give this example:

created_at:>=2020-01-01T12:00:00Z

When we use a full ISO 8601 timestamp like that in the query argument, the API returns 0 gift cards (empty nodes). The response extensions.search shows the parser splitting the time part into invalid search terms. When we switch to date-only (e.g. created_at:>=2025-12-03), the same store returns the correct gift cards. We’re reporting this so the team can fix the parser or update the docs.

Environment

  • GraphQL Admin API (latest)

  • giftCards query with the query parameter

Query and variables (failing case)

query getGiftCards($first: Int!, $after: String, $query: String) {
  giftCards(first: $first, after: $after, query: $query, sortKey: CREATED_AT, reverse: true) {
    nodes {
      id
      createdAt
      maskedCode
      initialValue { amount currencyCode }
      balance { amount currencyCode }
      enabled
      order { id name }
      recipientAttributes {
        preferredName
        recipient { firstName lastName }
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Variables:

{
  "first": 200,
  "after": null,
  "query": "created_at:>=2025-12-03T13:01:34-05:00"
}

Result with full ISO timestamp: 0 gift cards

With the above variables, data.giftCards.nodes is an empty array , even though the store has gift cards issued after that date in the admin.

The extensions.search block shows how the query was parsed:

{
  "extensions": {
    "search": [
      {
        "path": ["giftCards"],
        "query": "created_at:>=2025-12-03T13:01:34-05:00",
        "parsed": {
          "and": [
            {
              "field": "created_at",
              "range_gte": "2025-12-03T00:00:00-05:00"
            },
            {
              "field": "default",
              "match_all": "00"
            },
            {
              "field": "01",
              "match_all": "34-05"
            }
          ]
        },
        "warnings": [
          {
            "field": "01",
            "message": "Invalid search field for this query.",
            "code": "invalid_field"
          }
        ]
      }
    ]
  }
}

So the parser uses the date part for created_at (e.g. range_gte: “2025-12-03T00:00:00-05:00”) but then treats the rest of the string (T13:01:34-05:00) as extra terms—e.g. field “01” with value “34-05”—which are invalid and likely cause the empty result.

Result with date-only: correct gift cards

With the same query and variables except:

{
  "query": "created_at:>=2025-12-03"
}

the API returns the expected data: data.giftCards.nodes is populated with the correct gift cards (in our case, 60+ nodes). Example shape of the successful response:

{
  "data": {
    "giftCards": {
      "nodes": [
        {
          "id": "gid://shopify/GiftCard/123456789",
          "lastCharacters": "xxxx",
          "enabled": true,
          "createdAt": "2026-01-26T20:05:18Z",
          "balance": { "amount": "48.0", "currencyCode": "USD" },
          "initialValue": { "amount": "48.0", "currencyCode": "USD" },
          "order": null
        }
        // ... more nodes (60+ in our case)
      ],
      "pageInfo": {
        "hasNextPage": false,
        "endCursor": "eyJ..."
      }
    }
  },
  "extensions": {
    "cost": { ... }
  }
}

So: full ISO → 0 gift cards; date-only → correct results.

Workaround

Use date-only in the query:

{
  "query": "created_at:>=2025-12-03"
}

Questions

  1. Is full ISO timestamp (created_at:>=YYYY-MM-DDTHH:MM:SSZ or with offset) intended to be supported for giftCards search? If yes, this looks like a parser bug (splitting the time into invalid fields and returning 0 results).

  2. If only date is supported, could the docs be updated to show created_at:>=2020-01-01 (or similar) instead of 2020-01-01T12:00:00Z, so developers don’t hit empty results without realizing why?

Happy to provide more examples or a store ID for debugging if that would help.