Why does the error not name the field?

Sometimes it does, in the details of the error payload, and it is worth logging the full response body rather than only the message: teams routinely discard the part that would have answered the question. When it genuinely does not name a field, you are left with bisection, which is why keeping a known-good request to diff against is worth the small effort.

Which parameters cause this most often?

Dates are first by a distance. SP-API expects ISO 8601 with explicit timezone, and a naive local timestamp or a date without a time component gets rejected. After that: marketplace IDs that do not match the endpoint region, a NextToken reused after changing filters, and list parameters serialised as a comma-joined string where repeated parameters were expected.

It worked last week without any change on our side.

Then something changed on the other side. Amazon adds required parameters, tightens validation, and deprecates enum values over time. A request that was acceptable under an older behaviour can become invalid without you touching it. This is the argument for watching the API changelog rather than discovering changes through failures.

Can I retry an InvalidInput?

No, and retrying is actively harmful here. A 4xx of this kind is deterministic: the same request will be rejected the same way every time. Retrying burns rate-limit budget and can push you into throttling, which then masks the original problem. Route these to a dead-letter queue for inspection instead.

How do you avoid this class of failure?

By generating request models from the published API specification rather than hand-writing parameter maps, so a shape change surfaces at build time instead of in production. Combined with validating outbound requests before sending them, and treating deterministic rejections as data problems rather than transient errors to retry.

InvalidInput: Invalid request parameters - Amazon SP-API

What the error means

InvalidInput is a client-side rejection. Amazon looked at the request, decided it was not usable, and stopped. It is deterministic: the same request will fail the same way every time.

That property matters for how you respond. Unlike throttling or a 500, there is nothing to wait for. Retrying an InvalidInput cannot succeed, and it consumes rate-limit budget that you will want for the requests that can.

The recurring causes

Dates and timezones. By some distance the most common. SP-API expects ISO 8601 timestamps with an explicit timezone offset. A local timestamp without a zone, a date with no time component, or a date range where the start is after the end will all be rejected. Timezone handling is also where a working integration breaks at a daylight-saving boundary.

Marketplace ID and region disagreement. A valid marketplace ID for the wrong regional endpoint is not a valid parameter combination. This can present as InvalidInput rather than as an access error, which sends people looking in the wrong place.

Pagination tokens reused across changed filters. A NextToken belongs to the exact query that produced it. Change a filter or a date range and reuse the token, and it is no longer meaningful.

List parameters in the wrong shape. Some operations expect a parameter repeated once per value; sending a single comma-joined string is a different thing and gets rejected.

Values outside the accepted set. Order statuses, fulfilment channels and report types are enumerations. A plausible-looking value that is not in the list is invalid, and enumerations gain and lose members over time.

Working out which one it is

Observation	Look at
Fails for every call to this operation	A required parameter is missing or malformed
Fails only for some date ranges	Date format, timezone, or range ordering
Fails on the second page only	Pagination token reuse
Fails for one marketplace only	Marketplace ID against endpoint region
Started failing without a deployment	Amazon tightened validation or changed an enum
Fails only around a clock change	Timezone handling

Log the full response body, not just the message. The error detail often names the parameter, and it is routinely thrown away by error handling that keeps only the summary. This is the cheapest improvement available for this whole class of problem.

Do not retry these

An automatic retry policy that catches all failures will retry InvalidInput forever. That has three costs: it never succeeds, it consumes rate-limit budget, and the resulting throttling masks the original error behind a different one.

Deterministic rejections belong in a dead-letter queue with the request and the full response attached, so a person can look at exactly what was sent.

What we do differently

Request models are generated from the published specification, not hand-written. When Amazon changes a parameter’s shape or an enum’s members, the mismatch surfaces at build time rather than in a production sync.
Outbound requests are validated before they are sent. A malformed date does not need a round trip to be identified as wrong.
Retry policy distinguishes deterministic from transient. Throttling and 500s are retried with backoff. A 4xx of this kind is not retried at all, it is captured for inspection.
Failed requests are stored with their full response. No reconstructing what was sent from partial logs after the fact.
We diff the API specification daily. A new required parameter or a removed enum value is something we schedule work for, rather than something your order sync discovers on a Sunday night.