Resolve 400 Errors

There are many possible reasons for a 400 response.

Permissions and credentials

Ensure the following:

• Required roles are approved for your profile and application.
• The seller account is active.
  If it isn't, and a 400 error is being returned for that seller, contact the seller and request that they navigate to Seller Central > Settings > Account Info > Charge Information. If the Charge Information page displays a banner requesting a credit card update, ask the seller to update their credit card information. Allow 48 hours for the updates to propagate through all Amazon systems. If a seller account has not been used for 90 or more days, the account will be marked dormant, and the seller will be advised to update their credit card. Allow for a 48-hour waiting period to ensure a successful update. Afterwards, API calls can be made by that account.

If permissions and credentials are correct, there is likely an issue with the requests.

Request issues

The standard response from SP-API is in application/JSON format. If you receive a response in text/HTML format, the error was raised before SP-API could process the request.

Example:

{
   HTTP/1.1 400 Bad Request Server:
   Server Date: Tue, 16 May 2023 06:02:44 GMT
   Content-Type: text/html
   Transfer-Encoding: chunked Connection: close
}

SP-API requires that requests be consistent with HTTP RFC 7230. If you get a 400 status code with an HTML response, instead of a standard SP-API response body, make sure that your requests are consistent with RFC 7230. The most common cause of errors is the inclusion of a body or content length header for GET requests or duplicate or malformed host headers. Other possible errors include the following:

• Inclusion of a body, Content-Length header, or Transfer-Encoding header for GET/HEAD requests
• Content-Length is a non-parseable value or an invalid number
• Multiple Content-Length headers
• Presence of both Content-Length and Transfer-Encoding headers
• Duplicated or malformed Host headers
• An empty header or a line with empty spaces
• Non RFC-compliant multi-line headers
• Non-terminated header lines
• Header line doesn’t have colon separator
• The URI or header contains a carriage-return, null character, or control (CTL) character
• Empty line at the end of the request
• No URI in the request
• Malformed HTTP method

Inspecting requests

The method for inspecting requests depends on your HTTP client. Review the following possible approaches.

• If you are able to create a similar curl or wget command to call SP-API and are not seeing the same issue, this might indicate an issue with your HTTP client.
• Identify where HTTP requests are created to send to SP-API and inspect the requests.
• Inspect all headers and URI information for the requests. Some clients provide programmatic ways to get header information.
• Check the HTTP client for logging ability or if logging can be enabled through a configuration.
• If the client is an open-source HTTP client, you might be able to view the code to determine how the request is being created. If so, check for any bad assumptions.
• If you are using an adapter or plugin before sending the request, make sure they are not modifying the requests in undesired ways.
• Check if it is possible for you to enable wire logs that can provide more detail about the outgoing requests.

If you are still receiving 400 responses, the issue might be due to problems with the application.

Application issues

There are several errors that can be returned in response to issues with the application:

• Developer ID XXXX-XXXX-XXXX is not associated with the application id.: ensure that the developer ID has been provided for the hybrid application for the correct region and that the application is submitted for a review.
• application is missing OAuth setup.: ensure that the application has the redirect URI.

If you are still receiving 400 responses, the issue might be due to the requirements of the API.

API requirements

Ensure that all parameters are passed correctly per the documentation and that you are abiding by the requirements of the API you're calling:

• Amazon Fulfillment APIs: ensure that the seller has signed up for Fulfillment by Amazon.
• Merchant Fulfillment APIs: a 400 exception can be returned if fulfillment via API is attempted after the order has been shipped.
• Reports API: a 400 exception can be thrown if a report that can only be requested is scheduled. For example, the GET_MERCHANT_LISTINGS_ALL_DATA report can only be requested.
  • Requesting a settlement report can result in a 400 exception. Settlement reports cannot be requested or scheduled. They are automatically scheduled by Amazon. You can search for these reports using the getReports operation.
• Feeds API: when creating feeds, the contentType specified in Step 3. Upload the feed data must match the contentType specified during Step 1. Create a feed document. Amazon recommends UTF-8 character encoding. A mismatch of the content types in these two steps will cause the feed upload to fail, and could generate a 400 exception. For more information, refer to the Feeds API use case guide.
• Feeds API: when updating price and quantities, if the listing is absent in the seller account, an InvalidInput error will be returned.
• Fulfillment Outbound API: you can receive a Value for parameter SellerId is invalid. Reason: InvalidValue. error if you use the API in a marketplace other than AU, CA, DE, ES, FR, IT, JP, MX, UK, US, or CN.

If you are still encountering issues, you can open a Support Case for help troubleshooting.