# InvalidInput: Invalid request parameters

*Amazon SP-API · error message*

**In short:** InvalidInput means the request was rejected before it was processed: a malformed or missing parameter, a value outside the accepted set, or a combination the operation does not allow. The frustration is that the response usually does not say which parameter. The recurring culprits are date formats and timezones, marketplace IDs that do not match the endpoint region, pagination tokens reused with changed filters, and list parameters serialised in the wrong shape.

## 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.

## Frequently asked questions

### 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.

## Integrations this affects

- [JTL ↔ Amazon](https://seamless.engineering/integrations/jtl-amazon/): JTL Amazon integration
- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration
- [Amazon ↔ NetSuite](https://seamless.engineering/integrations/amazon-netsuite/): Amazon NetSuite integration

## Request a scoping call

Seeing this in production and want it to stop being your problem? We design, build, and permanently operate the pipeline, including the validation and retry logic that stops this class of failure reaching you. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact