Collections accept query parameters for paging, filtering and sorting. Each endpoint documents the ones it supports in the API reference.

​
Universal parameters

Every collection accepts these: See Pagination.

​
Unknown parameters are refused

If you send a parameter an endpoint does not define, the request is refused with 400 invalid_query. It is not ignored.
This is deliberate, and it is the behaviour most APIs get wrong.If stauts=published were ignored, you would receive a 200 with every product in the response, including drafts. The call looks like it worked. You would discover the typo when a draft product appeared somewhere a shopper could see it, possibly weeks later.Refusing at the first call turns a silent data bug into an obvious one.
The same rule applies to request bodies: an unknown field is refused at every nesting depth, not silently dropped.

​
Values are validated too

A parameter that exists but carries an unusable value is also refused rather than coerced to a default.
A limit=1000 is not quietly clamped to 100. Clamping would mean your bulk read runs ten times slower than you think it does, with nothing in the response to say so.

​
Text values

Query values must be valid UTF-8 without control characters or bidirectional overrides. Anything else is refused with invalid_text. This applies to path segments and request bodies as well. Bidirectional override characters can make a stored string display in an order other than the one its bytes are in, so a value can render as something other than what it actually is. Refusing them at the boundary keeps what you sent and what everyone later sees the same thing.

​
Encoding

Standard URL encoding. Encode spaces, &, =, + and non-ASCII characters in values.
Use your HTTP client’s parameter builder rather than concatenating a query string by hand. curl -G --data-urlencode, URLSearchParams, requests’ params=, and Go’s url.Values all encode correctly.

​
Filters must stay stable while paging

Keep every parameter other than after identical across a paged walk. A cursor encodes its position relative to the filter and ordering it was issued under, so changing a filter mid-walk is refused rather than returning a mixed result set drawn from two different queries.