SP-API Errors FAQ

You're using an outdated model version. Update the Swagger model version in your integration (for example, regenerate the client libraries) and try again.

In the SP-API, the token bucket algorithm limits request rates. For information about how to avoid throttling errors, refer to Usage Plans and Rate Limits in the SP-API.

Batch operations

The following batch operations are available for SP-API:

• searchCatalogItems
• getItemOffersBatch
• getListingOffersBatch
• getMyFeesEstimates

For more information, refer to the May 2022 SP-API Release Announcement.

Notification API

This API sends notifications instead of you having to send multiple requests to other APIs. For more information, refer to the Notifications API v1 Use Case Guide.

Rate limiter

To learn how to implement a client-side rate limiter, refer to Optimize Rate Limits for Application Workloads.

The transaction status will be supported for following API operations:

• Acknowledge Order
• Submit Shipment Confirmations
• Submit Shipment Status Updates
• Shipping Label Request
• Inventory Feed

If the transaction status hasn't changed from Processing to Failure or Success after 5 minutes, the transaction hasn't successfully completed in our system. If the transaction status is successful, the status changes to Success. If the transaction status is successful, the status changes to Failure and has an associated error code.

You can’t use this API for Invoice messages as they are not supported to check and the status will always be Processing.

For shipping label requests, if the transaction failed with a terminal error reason code (for example, Internal server error), you must contact the Selling Partner API Developer Support team using the Contact Us form for investigation. This happens due to operational constraints.

The operation parameters must be filled out correctly. Consider these points when filling out the parameters to make the API call:

• Invoice numbers must be unique and they should never be reused (even after one year).
• If an invoice sent by API has failed due to incorrect data but paper invoice has the correct data then vendor should update it through API with correct data using the same Invoice ID.
• If invoice has wrong data (both paper and API) then invoice is cancelled and new invoice should be sent with new Invoice ID.
• No invoice with total amount 0 should be sent, as this would cause the invoice to fail.
• Amazon requires the full address details in the address segments for tax compliance reasons. This is especially important for the bill-to party. For this segment the Amazon Payee system requires an exact match.
• Payment terms sent in invoice should match the payment terms agreed upon with the Amazon buyer
• Item product identifier should match the order item product identifier that were sent to the vendor in matching Purchase Order. Invoice total amount should be equal to the total sum of the items, charges and allowances.
• Total of tax amount for each line level must be equal to total of tax amount at header level.
• Invoice total quantity should match the sum of the quantity of all items. Each different charges and allowance has to be itemized on the header level.

If one of these parameters are missing or filled out incorrectly, this will lead the API call to retrieve incorrect details. Make sure to provide the required information when submitting the operation.

This error can be caused by the use of certain HTML tags, in particular header tags <h1><h2><h3><h4>. Remove these header tags and only use the tags that are provided in the text editor.

This error can also indicate that the account status has moved to dormant due to lack of activity. You can update your credit card information to reactivate the account. The next time you log in to Seller Central or Vendor Central, you will be redirected the credit card update page. Your account will be reinstated approximately 48 hours after the credit card has been updated.

If you are receiving 500 Internal Server Error, check that Content-Type header is set to application/x-www-form-urlencoded and the request parameters are added to the body and not as query parameters.

The SP-API sandbox works like many mocking frameworks; it uses pattern matching to return a specified response when the specified parameters are present. A developer receives a response defined in the x-amazon-spds-sandbox-behaviors object when they send a request that matches the specified parameters.

If the request sent to the sandbox endpoint does not match the parameter values in the x-amazon-spds-sandbox-behaviors object, you will receive a "500 Internal Server Error" in the response. You must send the request with the exact values specified in the model.

If the API requires any parameters that are not specified in the x-amazon-spds-sandbox-behaviors object, the sandbox provides the response regardless of the parameter values in the request, as long as the request is valid.

To learn more about making a sandbox call to SP-API, refer to The Selling Partner API sandbox.

OAuth is the authorization process that other Sellers will initiate to authorize your application in the Appstore.

If you include the version=beta parameter, the workflow authorizes an application in Draft state. If you do not include the parameter version=beta, the workflow will authorize a published version of that app ID on the Appstore, otherwise will return an error code "MD1000".

If you have an SP-API application that is not published but the OAuth workflow points to Production workflow, this error is returned. To resolve, confirm the application is in Draft stage. If so, add version=beta parameter to OAuth Authorization URI constructed. After the application is published, this parameter can be removed.

The MD5100 could be caused by the following issues:

• Errors in the OAuth authorization URL.
• Missing redirect links in the application.
• Fragments in the URL.

Try these solutions to resolve a MD5100 error:

• Check the application status:
• If the application is in draft status, verify the URL includes version=beta.
• If the application is published, verify the URL does not include version=beta. If version=beta is included in the URL, the OAuth process is initiated for the draft state of the application instead of the published state.
• Verify you have followed all steps for Authorizing Selling Partner API applications.
• Verify that your application has a login URI and redirect URI. You can update the login URI and redirect URI by editing your application in the Solution Provider Portal and updating the login URI and redirect URI details.
• Verify the application supports the marketplace to which the developer is being authorized. In the Solution Provider Portal, choose the Edit listing option for your application, and in the Pricing section, choose the marketplaces that the application should support.

If after reviewing these details the issue persist, submit a support case.

This error occurs when you are trying to authorize an application as a secondary user. To avoid this error, contact the account owner and ask them to perform this action for you.

Check if your application is missing Login URI and Redirect URI. You can update Login URI and Redirect URI by editing the app. Navigate to Appstore > Develop Apps and choose Edit App for the app you are using to view the App registration form and update the Login URI and Redirect URI details.

The SKU you're using might have special characters, like a back or forward slash (\, /), that require URL encoding. This can be done programmatically in several languages. Here is an example in Java:

import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;
import java.io.UnsupportedEncodingException*;*

 // Method to encode a SKU using the UTF-8 encoding scheme
  private static String encodeSKU(String sSKU) {
    try {
      return URLEncoder.encode(sSKU, StandardCharsets.UTF_8.toString());
    } catch (UnsupportedEncodingException ex) {
      e*.*printStackTrace*();*
    }
  }

For more information, refer to URL encoding.

For more information, refer to Resolving 400 errors.