ishans9314858 is correct about the API quota limit of 20K calls per hour per Analytics company; however, that is for the 1.3/1.4 Analytics APIs. For the Analytics 2.0 APIs, the throttle limit is set at 120 calls per minute, per user, regardless of report suite or company. When the throttle limit is crossed, the server returns an HTTP 429 status to the user the with message content: "too many requests". Note that the throttle applies at the API gateway layer.
There is also a throttle applied by the underlying reporting engine per report suite which is independent of any reporting client (e.g. Workspace, Report Builder, API, etc.) When that throttle is hit, no errors are returned but report requests take longer to process. The end result is that report requests across all clients take longer to process as the load on the report suite increases. Thus, it's possible for Workspace or Report Builder usage to cause API requests to run slower and it's possible for API requests to cause Workspace or Report Builder to run slower on a given report suite. The Analytics reporting system is a shared, multi-tenant system and this throttle is designed to prevent reporting activities on any single report suite from consuming too high a percentage of the capacity of a given data center.
The Page variable id is always /variables/page. The Title or Name of the variable can be renamed on a per-report-suite basis but the id /variables/page shouldn't change. You can use the /dimensions endpoint for a report suite to get the list of dimensions and you can see the page variable as in the following example:
{
"id": "variables/page",
"title": "Page",
"name": "Page",
"type": "string",
"category": "Content",
"support": [
"oberon",
"dataWarehouse"
],
"pathable": true,
"segmentable": true,
"reportable": [
"oberon"
],
"supportsDataGovernance": true
}
ishans9314858 is also correct that you have to make multiple calls in the 2.0 API to do a breakdown.
A minimum of 2 calls is required: 1 call to get the item IDs of the dimensions and a second call to do the break down. This is because a breakdown of Dimension A by Dimension B is actually a filter on Dimension B where the values on the same hit were a specific value (itemId) of Dimension A. Multiple-level breakdowns across large numbers of dimension items require more calls. For example, breaking down a list of 1000 items two levels deep, with 5 dimensions at the first level and 10 dimensions at the second level will require 6001 actual API requests. With a throttle of 120 calls per user per minute it would take approximately 50 minutes for the 1000x5x10 breakdown to be completed assuming no other report requests are loading the report suite.
Previous versions of the API made the multiple breakdown calls for on behalf of the caller; however, this has the effect of "hiding" the performance costs of large complex breakdowns to the callers. API calls had to be queued and processed because of the load they placed on the reporting system. Callers had no idea how long a breakdown call would take and couldn't display any sort of progress while a request was working its way through the queue.
API 2.0 doesn't do any queuing at the API layer but it requires callers to make the breakdown calls themselves. Callers can know exactly how many calls need to be made and thus calculate and provide an indication or update on progress when working through large multi-level breakdowns. API 2.0 is a reporting API designed to support responsive interactive reporting and exploration but is not well-suited for bulk data export use cases. The 1.4 Data Warehouse API or Data Feeds are more suitable for use cases that require bulk data export.
