[qsysvcore]

Summary

NFTsAPI.validateMetadata() built its query string by hand and spelled the
parameter ignoreCachedItemUrls. The API documents it as
ignore_cached_item_urls, so the camelCase spelling put an undocumented
parameter on the wire, which the server accepts and ignores.

Calling api.nfts.validateMetadata(contract, tokenId, chain, true) therefore
returned the cached item URLs — the exact thing the flag exists to avoid — with
no error to notice. That is the same silent-failure mode as the deprecated
next in place of cursor that test/api/queryArgsDrift.spec.ts was written
for; it slipped past that test because the parameter is positional rather than a
field on a *Args interface.

Why it is easy to miss

This is the only hand-built query string in the SDK. Everywhere else, parameters
go through objectToSearchParams(snakeizeKeysDeep(query)) in OpenSeaAPI.get,
or are written in snake_case by hand (walletAuth.ts: tool_id,
registry_chain, content_type, …). post() takes a body rather than a query
object, so nothing snakeizes this one.

The change

• src/api/nfts.ts — send ignore_cached_item_urls. The string is now
  assembled with URLSearchParams, like the other hand-built query strings in
  the package, so an explicit false is sent rather than dropped. The JSDoc
  records why the wire spelling is snake_case so the two cannot drift again.

Scope

One behaviour change on one endpoint, no refactor, no public type change. The
deprecated api.validateNFTMetadata() forwarder is unaffected (it delegates,
and forwarderSignatures.spec.ts still holds).

[ryanio]

Thanks for digging into this. We checked it against the API and aren't taking the change, because the camelCase spelling is the one the server reads.

The OpenAPI spec lists this query parameter as ignoreCachedItemUrls for both validate_nft_metadata and refresh_nft_metadata (see opensea-api.json), and the server binds it by that name. With ignore_cached_item_urls, the server would ignore the flag and fall back to its default. The false case is also already sent today, since the template literal stringifies it.

If you have a request where ignoreCachedItemUrls=true appears to be ignored, please open an issue with the request and response and we'll look into it.