Resolve Common HTTP and Authorization Error Codes

This page describes common errors you may encounter when using a Selling Partner API (SP-API) and provides guidance on how to resolve them.

If these steps don't resolve your issue, refer to Troubleshoot SP-API Errors for additional guidance or open a case.

HTTP 400 Bad Request

This error occurs due to invalid request parameters or a malformed request.

Common 400 error messages

If an error message accompanies the 400 status code, search the following table for its meaning and solution.

Troubleshoot 400 errors

If the preceding table doesn't resolve your 400 error, follow these troubleshooting steps.

Step 1. Verify your developer profile and application have all required roles

To learn more, refer to Selling Partner API Roles.

Step 2. Ask the affected seller to confirm their account is active

Inactive accounts display a banner on the Seller Central Charge Information page requesting a credit card update. The seller must update their credit card information and allow 48 hours for the updates to propagate through all Amazon systems before they can try again.

Step 3. Inspect HTTP client logs and wire logs

Use the following methods to inspect your outgoing requests and determine whether your HTTP client is sending them as expected:

• Try to reproduce the issue using curl or wget. If you cannot reproduce it with those tools, the problem is likely specific to your HTTP client.
• Identify where your code creates HTTP requests and inspect them before they are sent.
• Inspect all headers and URI values. Many HTTP clients provide programmatic methods to retrieve header information.
• Check whether your HTTP client supports logging, or whether logging can be enabled through configuration.
• If your HTTP client is open source, review the source code to identify how requests are constructed and check for incorrect assumptions.
• If you use an adapter or plugin in your request pipeline, verify that it is not modifying requests in unintended ways.
• Enable wire logs if your client supports them. Wire logs provide the most detailed view of outgoing requests.

Step 4. Verify the request conforms to HTTP RFC 7230

SP-API requires that requests conform to HTTP RFC 7230. If you receive a 400 status code with an HTML response instead of a standard SP-API response body, your request likely contains a malformed element.

The following request errors commonly cause a 400 response with an HTML body:

• A body, Content-Length header, or Transfer-Encoding header is included in a GET or HEAD request.
• Content-Length contains a non-parseable value or an invalid number.
• Multiple Content-Length headers are present.
• Both Content-Length and Transfer-Encoding headers are present.
• The Host header is duplicated or malformed.
• A header is empty or contains only whitespace.
• A multi-line header doesn't conform to RFC 7230.
• A header line is not terminated correctly.
• A header line is missing the colon (:) separator.
• The URI or a header value contains a carriage return, null character, or control (CTL) character.
• The request ends with an empty line.
• The request doesn't include a URI.
• The HTTP method is malformed.

If the 400 response persists, the issue might be due to the requirements of the API. Refer to Troubleshoot SP-API Errors for additional troubleshooting steps.

HTTP 403 Forbidden

This error occurs due to failed authentication. Possible reasons include denied access, missing or expired credentials, or an invalid signature.

Common 403 error messages

If an error message accompanies the 403 status code, search the following table for its meaning and solution.

Troubleshoot 403 errors

If the preceding table doesn't resolve your 403 error, follow these troubleshooting steps.

Step 1. Update your credentials

You must rotate your Login with Amazon (LWA) credentials for all applications every 180 days. For instructions, refer to Rotate your Application’s LWA Credentials.

Step 2. Verify regional support

Ensure that the seller account you're making a request to and the request endpoint are in the same region. The selling partner application is global but seller accounts are not. For details, refer to SP-API Endpoints.

Step 3. Ensure that you have the correct roles to access the operation

To verify role permissions in Solution Provider Portal:

1. Next to the app that you want to verify, choose Edit App.
2. Review the roles selected for your application.

If you're missing the role that you need for API access, check your developer profile to verify that you requested access. If you're missing access to a restricted role, you might need to re-submit your developer profile to get access to that restricted role. After the role is added, generate a new LWA refresh token to make valid API calls.

If the 403 response persists, open a case to resolve the issue.

HTTP 404 Not Found

A 404 error occurs when the requested resource is not found.

Common 404 error messages

If an error message accompanies the 404 status code, search the following table for its meaning and solution.

Troubleshoot 404 errors

If the preceding table doesn't resolve your 404 error, follow these troubleshooting steps:

Step 1. Confirm the resource exists and has not been deleted

Verify that the resource you are requesting has not been removed or deactivated. Confirm that the marketplace scope in your request matches the marketplace where the resource was created.

Step 2. Verify that the resource identifier is valid and correctly formatted

Check the spelling and casing of all identifiers in your request, such as order IDs, SKUs, ASINs, shipment IDs, and subscription IDs. Ensure the identifier belongs to the correct marketplace.

For more information about SP-API request and response formatting, refer to Call Structure.

Step 3. Verify the API endpoint and resource path

Confirm that the URL path is correctly formed and includes the required version or date (for example, /listings/2021-12-01/items). Ensure you are not using a deprecated endpoint. To keep up to date on API deprecations, refer to the SP-API Deprecation Schedule.

Step 4. Check for premature polling on asynchronous operations

If you request a resource that is created asynchronously, ensure that enough time has passed for the system to finish generating it.

If the 404 response persists, open a case to resolve the issue.

HTTP 429 Too Many Requests

This error occurs when you exceed the allowed number of requests for an operation. Amazon enforces resource quotas and burst rates to ensure system stability. Wait a few minutes, then retry the request.

To reduce HTTP 429 responses, follow these best practices:

• Respect Rate Limits: Always review usage plans for an SP-API operation before integration, monitor x-amzn-RateLimit-Limit response headers, and design your application to stay within defined limits. Refer to How to find your usage plan for more information.
• Implement Proactive Load Management: Don't wait for throttling. Build retry mechanisms with exponential backoff into your application to ensure resilience. For implementation guidance, refer to Implement retry and back-off techniques.
• Optimize Request Pattern: Avoid burst traffic that wastes quota. Consolidate API calls and distribute requests evenly throughout the day. For details on how to optimize large-scale operations, refer to Optimize Calls to the Selling Partner API.

For more information, refer to Performance Management.

Null enum value

A null enum value returns when you use an outdated model version after a new enum value has been introduced. Update the Swagger model version in your integration (for example, regenerate the client libraries) and try again.

Authorization error codes

Authorization errors occur during the OAuth authorization workflow and indicate issues with your application's configuration, credentials, or permissions. The following section covers solutions to common authorization error codes.

MD1000

This error occurs when you authorize an SP-API application in Draft state through the OAuth production workflow.

To resolve this error: Add the version=beta parameter to the OAuth authorization URI:
https://sellercentral.amazon.com/apps/authorize/consent?application_id=appidexample&state=stateexample&version=beta
After you publish your application, remove the version=beta parameter.

MD5101

This error occurs when the OAuth redirect URI that you provide during authorization doesn't match one of the redirect URIs listed for the SP-API application.

To resolve this error: Verify that you're using the correct redirect URI. For more information, refer to the following instructions:

Solution Provider Portal

1. From the Solution Provider Portal menu, choose Apps, and then choose Develop Apps Console.
2. Next to the app that you want to verify, choose Edit App.
3. In the console, verify that the redirect URI matches the redirect URI of the page where you received the error.
4. If the URLs don't match, add the redirect URI to the console.
5. If you're using the published version of your app, make sure that you publish the update.

Seller Central

1. From the Seller Central menu, choose Apps and Services, and then choose Develop Apps.
2. Next to the app that you want to verify, choose Edit App.
3. In the console, verify that the redirect URI matches the redirect URI of the page where you received the error.
4. If the URLs don't match, add the redirect URI to the console.
5. If you're using the published version of your app, make sure that you publish the update.

MD5110

This error occurs when the redirect URI contains fragments. For more information, refer to section 3.1.2 of the OAuth 2.0 authorization framework.

To resolve this error: Check the redirect URI for fragments. For more information, refer to the following instructions:

Solution Provider Portal

1. From the Solution Provider Portal menu, choose Apps, and then choose Develop Apps Console.
2. Next to the app that you want to verify, choose Edit App.
3. Verify that the redirect URI is valid and doesn't contain fragment characters, such as #.

Seller Central

1. From the Seller Central menu, choose Apps and Services, and then choose Develop Apps.
2. Next to the app that you want to verify, choose Edit App.
3. Verify that the redirect URI is valid and doesn't contain fragment characters, such as #.

MD9100

This error occurs when your application doesn't have a login URI and redirect URI.

To resolve this error: Update your app's login URI and redirect URI. For more information, refer to the following instructions:

Solution Provider Portal

1. From the Solution Provider Portal menu, choose Apps, and then choose Develop Apps Console.
2. Next to the app that you want to verify, choose Edit App.
3. Update the login URI and redirect URI.

Seller Central

1. From the Seller Central menu, choose Apps and Services, and then choose Develop Apps.
2. Next to the app that you want to verify, choose Edit App.
3. Update the login URI and redirect URI.

SPDC8143

This error occurs when you access the account as a non-primary user.

To resolve this error: Access the account as the primary user.

SPSA0404

This error occurs when your application doesn't support the business entity that attempts to authorize it.

To resolve this error: Update the supported business entities. For more information, refer to the following instructions:

1. From the Solution Provider Portal menu, choose Apps, and then choose Develop Apps Console.
2. Next to the app that you want to verify, choose Edit App.
3. Update the supported business entities.

CONSENT_LIMIT_REACHED for OAuths

This error occurs if you reach the limit of authorizations for your current application. For more information, refer to App Authorization limits.