Openbridge employs a conservative API request strategy, ensuring we operate within published rate limits and the throttling constraints that Amazon imposes. We carefully model each endpoint and how best to request and re-request data to minimize our consumption of API rate limits.

Amazon recommends that you do not request reports at a frequency greater than the data for that report to be refreshed, typically once daily.

Data collection, including history requests, is impossible if the Amazon API consistently responds with a CANCELED response. Despite numerous attempts and re-attempts to retrieve this data, a CANCELED response from the Amazon API is considered a blocker.

We know there are use cases where other applications are attached to a customer account. Unfortunately, these applications do not follow Amazon documentation for limits and throttles. It is common to see these applications or tools requesting data many times an hour, even though Amazon states that it can only be requested once daily.

Another error that is more common in Vendor Reports is "FATAL." Amazon says, "If you request a report for a reporting period that is not yet available, the report will not be generated, and the processing status for the report will be FATAL."

There are two common outcomes of over-aggressive use of the Amazon API:

As a result, these applications fail to properly work within Amazon limits, which Openbridge from collecting data on your behalf. Openbridge has no control over Amazon's FATAL, CANCELED, or NO_DATA responses. We will attempt a series of retries to collect the data, but given API limits, we can only retry for a set period.

Excessive requests from third-party applications can monopolize the API's capacity, blocking other applications like Openbridge from accessing those report resources.

Amazon's UI will even report these issues when report requests exceed capacity, stating you can not request or download a report:

Below is a screenshot of the number of requests repeatedly made for the same or similar reports on June 26th. This indicates a third-party application or service spamming the Reporting API with request after request for the same or similar reports. This behavior will block Openbridge or any other application from accessing these resources.

This indicates that a third-party service or application is making repeated, excessive, and duplicative requests for the same reports, causing Amazon to limit the Seller account as this excessive behaviour far exceeds the available API capacity.
​

Please review any other applications attached to the seller account for usage levels for the Amazon Reporting API. Applications making calls to this API should be reviewed and access restricted if they are no longer used or overly aggressive with API calls. This will unlock additional API capacity.

One check you can perform is to review your Report logs in the Amazon interface. You likely need to audit application access if you see reports with many CANCELED reports. They may be calling too frequently.
​
​
Here is an example of a UI blocking report requests in the UI for Inventory Ledger Reports:

Below is an example of Amazon Fulfilled Inventory requests being canceled:
​

In the Inventory Health example below, you can see a mix of success and CANCELLED responses concerning requests for the data:
​

Lastly, the Received Inventory report below shows most requests returned CANCELED:
​

NO_DATA is another common response from Amazon. For example, the Amazon Orders report indicates there is NO_DATA:

In a different report type, Returns, it also reports NO_DATA:

Here is another example of data sporadically being available for download:
​

Getting a combination of NO_DATA and CANCELLED responses from the API is possible. The Daily Inventory Report below highlights both use cases, NO_DATA and CANCELED:

Here is a combination of No Data and Cancelled with no success outputs:

There are cases when Amazon may not be responding to requests and is exceeding the expected timing for the delivery of a report.

The example below shows that order-by-date reports are working correctly, but orders by the last update are "stuck" in an "in-progress" state.

"In-progress" states can impact our ability to deliver data. We depend on Amazon to return information per published specifications in these cases. We attempt to re-request in-progress reports in these cases, though Amazon may remain stuck for over 24 hours. Normally, it may take a few minutes to provide the report. A delay of this magnitude can cause us to "time out" waiting for them to respond.

​

Generally, most reports are daily and should be requested no more than once a day. Specifically, here is what Amazon will do in response to an application or tool exhausting API limits:

If you have other applications or scheduled processes in the Seller Central UI, these errors are more likely to occur.

Per Amazon, you should not have multiple requests for the same data. If you have another app or tool that is exhausting API capacity, it will impact our ability to collect data on your behalf! Openbridge cannot collect this data if Amazon always reports NO_DATA or CANCELLED. This is a hard limit that Amazon sets, not Openbridge.

Check if you have any other applications or Seller Central reports scheduled. If you do, remove or pause them. This will reduce the number of requests that end in a CANCELLED or NO_DATA state.

Here is an example of a page in your Seller Central account that shows various apps and their states. If you do not recognize an app, and that app is active, you will want to investigate what it is doing. It is possible it is making API calls for resources that are not needed.

Lastly, if reports have been generated from Seller Central UI, these requests will count against API limits. If you have scheduled reports in the Seller Central UI and are attempting to export via the API programmatically, we suggest stopping any scheduled reports in the Seller UI.