HomeDocumentationCode SamplesAPI ReferenceAnnouncementsModelsRelease NotesFAQGitHubVideos
Developer HubAPI StatusSupport
Announcements
Developer HubAPI StatusSupport
Back to All

API request validation for 400 errors with HTML response

June 1st, 2023 by AlexR_Amazon

Effective June 5, 2023, Amazon will reject requests that are not consistent with HTTP RFC 7230. We have enforced this restriction to a portion of requests since April 25, 2023.

Requests not consistent with HTTP RFC 7230 will return an error 400 status code and an HTML response. Check your metrics and logs to see if you have received an error with 400 status code and an HTML response.

If you receive this error, use the following instructions to identify and resolve the issue with your client code. If you do not receive this error, no action is needed.

Troubleshooting 400 Errors with HTML response

When to troubleshoot

Use the following troubleshooting information when a request results in an error with a 400 status code with an HTML response. Note that the standard response from SP-APIs are in application/JSON format. As a result, a response in text/HTML format indicates that the error was raised before Selling Partner API (SP-API) could process the request.

Example error response:

 {
    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
 }

What to do

If you see a 400 error AND do not see a standard SP-API response body, check the following list of known causes for rejected requests. The most common cause of errors is the presence of a body or content length header for GET requests. Once you identify the source, resolve it in your client code.

Request patterns not compliant with RFC that can cause a request to be rejected:

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

How to inspect the request

There is no single method to inspect an outgoing request as hundreds of standard and third-party developed HTTP clients are available and Amazon does not have visibility and awareness of each client’s behavior.

Some common areas to check are:

  • Identify when HTTP requests are created to send to SP-API and inspect the requests.
  • Gather all headers and URI information for the outgoing request. 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 may be able to view the code to determine how the request is being created, or if there are any bad assumptions.
  • If you are using an adapter or plugin before sending the request, adapters and plugins can modify the request.
  • Check if it is possible for you to enable wire logs that can provide more detail about the outgoing requests.
  • If you are able to create a similar curl or wget command to call SP-API and are not seeing same issue, this might indicate some difference of behavior with your HTTP client.