Thanks for the question, @erv_jackie, and for looking into some of the documentation.
The 15-minute window is endpoint-specific and depends on the time that the first request* was made. Let’s use GET accounts as an example. When I make the first request, the response headers provide the following information:
-> "x-rate-limit-limit: 2000"
-> "x-rate-limit-remaining: 1999"
-> "x-rate-limit-reset: 1509684755"
The x-rate-limit-reset value corresponds to 2017-11-03T04:52:35+00:00. Also notice that I’ve made one request, so the number remaining is 1999. When I make the second request, I get the following:
-> "x-rate-limit-limit: 2000"
-> "x-rate-limit-remaining: 1998"
-> "x-rate-limit-reset: 1509684755"
The x-rate-limit-reset value is the same. If I make a request to the GET accounts/:account_id/campaigns endpoint, for example, remaining would be 1999 and reset would be a different value.
Back to GET accounts. After 2017-11-03T04:52:35+00:00, the 15-minute window will reset.
You’re right that writes are typically given 300 requests per 15-minute window. However, even though creating an asynchronous analytics job is POST request, it’s not actually a write. Instead, the POST stats/jobs/accounts/:account_id endpoint is limited in the number of concurrent (PROCESSING) jobs that could be running at any given time, which is set to 100.
We’ll do an audit of our endpoint and ensure the Rate Limiting documentation is up to date and clear.
Thanks again for asking these questions. If you need further clarification, please let us know.
* The first request corresponds to the first request within a given 15-minute window.
