> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-api/cloud-consumption-dashboard/cloud-consumption-overview.md). # Cloud Consumption Dashboard API overview Public APIs for accessing the data behind the **Cloud Consumption** dashboard in Cortex Cloud. Each endpoint maps 1:1 to a dashboard widget, so you can retrieve the same data the UI displays — license entitlements, consumption per asset type, consumption over time, and a paginated details grid — outside the product. The dashboard provides centralized visibility, historical tracking, and granular, account-level auditing for your cloud infrastructure resources. It tracks workload consumption across all connected cloud accounts and providers, breaking the data down by asset type, and normalizes diverse cloud resources into a single currency called a **workload unit**. *** ## Prerequisites Before using these APIs, confirm the following conditions are met: * **Permission:** The API key's role must include the `Cloud Consumption Command Center: View` permission. This permission is granted by default to Administrator roles and can be delegated to custom roles. * **License:** The tenant must hold an active Cloud Posture Security or Cloud Runtime Security license (purchased as an individual add-on or as part of a core bundle). Tenants without a qualifying license receive HTTP 403. * **Data collection:** Data must be collected for at least seven days before the dashboard (and these APIs) return results. Historical data is not backfilled. * **Feature flag:** All endpoints respect the tenant-level `consumption_dashboard_enabled` flag. When the dashboard is disabled, endpoints return HTTP 404. > **Note:** After the initial seven days, the system progressively matures over 90 days, gradually expanding available data ranges and rolling-average accuracy as historical data accumulates. Eventually, data for the past 365 days is available for custom date ranges. *** ## Workload unit conversion Cortex Cloud normalizes all raw cloud assets into workload units to simplify multi-cloud billing. Individual workload unit calculations are rounded up when aggregated. Assets discovered by multiple concurrent protection mechanisms are automatically deduplicated and reported as a single workload unit. Deleted assets and infrastructure managed internally by Palo Alto Networks are excluded from consumption counts. | Workload category | Asset type | Conversion metric (= 1 workload unit) | | ----------------- | ---------------------------- | ----------------------------------------------------------------------------------- | | Compute | Scanned VM | 1 virtual machine | | Compute | Agent protected endpoint | 1 endpoint | | Containers | Scanned CaaS instances | 10 managed containers | | Containers | Registry scans | Free quota: 10 images per deployed workload. Beyond quota: 10 container image scans | | Serverless | Scanned serverless functions | 25 serverless functions | | Storage & DB | Storage buckets | 10 cloud buckets | | Storage & DB | PaaS databases | 2 PaaS databases | | Storage & DB | DBaaS data storage | 1 terabyte (TB) stored | | Other | SaaS users | 10 SaaS users | | Other | Unmanaged assets | 4 unmanaged assets | *** ## What you can do with this API ### License entitlements Two parameterless `GET` endpoints return the purchased vs. consumed workload entitlements for each active license: * **`GET /platform/cloud-consumption/v1/license-runtime/`** — Cloud Runtime Security license card. Returns purchased workloads, consumed workloads (90-day rolling average of hourly snapshots), utilization percentage, over-quota flag, and a per-category breakdown with conversion tooltips. * **`GET /platform/cloud-consumption/v1/license-posture/`** — Cloud Posture Management license card. Same shape as the runtime endpoint. Dashboard-level filters do **not** apply to these endpoints — entitlements are always reported tenant-wide. If the tenant holds multiple active licenses, call each endpoint separately to get side-by-side tracking. ### Consumption per asset type **`POST /platform/cloud-consumption/v1/per-asset-type/`** — Returns workload consumption for the selected time window, aggregated by asset type and broken down by cloud provider. Powers the horizontal stacked-bar widget. * For time windows under 7 days, the chart uses an average of hourly snapshots. * For custom ranges longer than 7 days, the system uses an average of daily snapshots. * The top 5 highest-consuming cloud providers are returned individually. All other active providers are aggregated under an `Additional` category. ### Consumption over time **`POST /platform/cloud-consumption/v1/over-time/`** — Returns a daily consumption time series for the selected time window. Powers the line-chart widget. The response contains three series by default: * **`purchased`** — A static baseline showing the total allocation threshold of the active contract. * **`used`** — The daily average of raw hourly counts collected over a 24-hour cycle, representing real-time elasticity. * **`average`** — A 90-day rolling average of hourly snapshots, calculated once daily. This is the true billable metric used to evaluate quota compliance. Set `by_cloud_provider: true` to replace the single `used` series with one series per cloud provider (top 5 environments). The `average` and `purchased` series remain unchanged. > **Note:** For the first 90 days after feature release, the final `used` values in this chart may differ from the Cloud Runtime Security license overview. ### Consumption details grid **`POST /platform/cloud-consumption/v1/details/`** — Returns paginated, per-cloud-account consumption rows with workload counts for every asset type. Powers the details grid widget. * Data is displayed in workload units, not raw asset counts, aligning directly with billing logic. * If a cloud account is deleted or modified, the historical ledger row remains intact, substituting the deleted account name with its unique cloud account ID. * Supports sorting by any column and filtering by cloud provider, cloud account, and asset group. * Pagination via `offset` and `limit` (maximum 500 rows per page). The response includes `total_count` (rows before filters) and `filter_count` (rows after filters) so clients can build paginators. ### Tenant license info **`POST /public_api/v1/system/get_tenant_info/`** — Returns the full license and add-on entitlement information for the authenticated tenant (purchased quotas, usage, expiration dates). The response shape varies by tenant type (XSIAM, XDR, XSOAR, Xpanse). Send an empty body. *** ## Authentication All endpoints use standard Cortex public API JWT authentication: ``` Authorization: Bearer ``` *** ## Time window rules The `per-asset-type`, `over-time`, and `details` endpoints accept a required time window (`from_time` and `to_time` in epoch seconds, UTC): * `to_time` must be strictly greater than `from_time`. * The span may not exceed one year (365 days). * Both values are rounded down to UTC midnight of their respective day. * Only the most recent 12 months of consumption data are retained; older windows return no data. *** ## Filters Optional filters available on `per-asset-type`, `over-time`, and `details` (sent in the POST request body): | Filter | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------ | | `cloud_providers` | Restrict to one or more cloud providers: `AWS`, `AZURE`, `GCP`, `OCI`, `IBM`, `ALIBABA`, `ON_PREM`, `OTHER`. | | `cloud_account_ids` | Restrict to specific cloud account IDs. | | `asset_group_ids` | Restrict to assets belonging to specific realm-only asset groups (filtered by Realm/Account). | License-card endpoints (`license-runtime` and `license-posture`) are parameterless `GET` requests — dashboard-level filters do not apply. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-api/cloud-consumption-dashboard/cloud-consumption-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.