> ## Documentation Index > Fetch the complete documentation index at: https://developers.podero.com/llms.txt > Use this file to discover all available pages before exploring further. # Get an Organisation's Devices Savings > Get the savings for the specified organization ID within a date range. Three response shapes, driven by the optional params (default = single range total split by device class, backwards-compatible): * `resolution=` → `{metadata, data: [{start_period, end_period, total_savings, _savings…}]}`, one bucket per calendar period. Buckets use the same `Trunc*`/UTC daily-row semantics as the per-device savings endpoints, so a `1DAY` org bucket equals the sum of its devices' daily figures and the series sums to the range total (full periods only — a partial trailing period is dropped). * `by=device` / `by=device_type` / `by=oem` → `{metadata, data:[…range totals…]}`. `by=device` returns one page of the extremes — the top `limit` by savings, `order=desc` (best savers) or `asc` (worst performers); `by=oem` groups by device-model manufacturer (merged across classes), so whole-fleet and per-OEM aggregates come from `device_type`/`oem`, not the per-device list. `resolution` and `by` are mutually exclusive — a bucketed org series XOR range-total breakdowns, never the cross product. Amounts are in the org's currency (`currency` on the default shape, `metadata.currency` on the others): each day converts from the stored EUR at that day's rate, like the per-device `/savings/daily`, so a `1DAY` bucket equals the sum of its devices' daily figures. Restricted to support and admins, plus Console Support agents reading across organisations. ## OpenAPI ````yaml https://app.podero.com/api/partners/v2.0/openapi.json get /api/partners/v2.0/org/{org_id}/devices/savings openapi: 3.1.0 info: title: Podero Partner API version: '2.0' description: >- This API provides a unified interaction point for Podero's partner companies. The goal of this API is to give partners easily integratable endpoints that don't require extensive software development. For this reason, the endpoints focus around user and device management, setting of preferences and high level device controls. While direct control of devices is implemented for special use cases such as pause power, we abstract away low level direct device steering so developers and partners can focus on delivering maximum value to end users. ## Authentication Send an OAuth2 access token in the `Authorization: Bearer ` header of each request. A token request must have a JSON body. The token endpoints do not read a form-encoded body. Server-to-server integrations use the client credentials grant: ```http POST /oauth2/token/ Authorization: Basic base64(:) Content-Type: application/json {"grant_type": "client_credentials"} ``` The response does not contain a refresh token. The access token expires after `expires_in` seconds (one hour). To renew it, send the same request again. Use one token for all requests until shortly before it expires. Do not request a new token for each request. If a request returns `401`, get one new token and send the request again once. If it returns `401` again, the token is valid but the application has no access to that resource, and a new token does not change that. Apps where a person signs in use the password grant at `POST /api/partners/v2.0/auth/token`, and renew the session with the `refresh_token` grant at the same endpoint. termsOfService: https://www.podero.com/terms-and-conditions servers: [] security: [] paths: /api/partners/v2.0/org/{org_id}/devices/savings: get: tags: - Devices summary: Get an Organisation's Devices Savings description: >- Get the savings for the specified organization ID within a date range. Three response shapes, driven by the optional params (default = single range total split by device class, backwards-compatible): * `resolution=` → `{metadata, data: [{start_period, end_period, total_savings, _savings…}]}`, one bucket per calendar period. Buckets use the same `Trunc*`/UTC daily-row semantics as the per-device savings endpoints, so a `1DAY` org bucket equals the sum of its devices' daily figures and the series sums to the range total (full periods only — a partial trailing period is dropped). * `by=device` / `by=device_type` / `by=oem` → `{metadata, data:[…range totals…]}`. `by=device` returns one page of the extremes — the top `limit` by savings, `order=desc` (best savers) or `asc` (worst performers); `by=oem` groups by device-model manufacturer (merged across classes), so whole-fleet and per-OEM aggregates come from `device_type`/`oem`, not the per-device list. `resolution` and `by` are mutually exclusive — a bucketed org series XOR range-total breakdowns, never the cross product. Amounts are in the org's currency (`currency` on the default shape, `metadata.currency` on the others): each day converts from the stored EUR at that day's rate, like the per-device `/savings/daily`, so a `1DAY` bucket equals the sum of its devices' daily figures. Restricted to support and admins, plus Console Support agents reading across organisations. operationId: >- integrations_api_api_v2_organizations_devices_router_retrieve_all_devices_savings parameters: - in: path name: org_id schema: description: The organization ID of the user's organization format: uuid title: Org Id type: string required: true description: The organization ID of the user's organization - in: query name: start_datetime schema: description: Start datetime for savings calculation format: date-time title: Start Datetime type: string required: true description: Start datetime for savings calculation - in: query name: end_datetime schema: description: End datetime for savings calculation format: date-time title: End Datetime type: string required: true description: End datetime for savings calculation - in: query name: resolution schema: description: >- Bucket the org total into a time series (1DAY/1WEEK/1MONTH/1QUARTER/1YEAR). Mutually exclusive with `by`. title: Resolution type: string required: false description: >- Bucket the org total into a time series (1DAY/1WEEK/1MONTH/1QUARTER/1YEAR). Mutually exclusive with `by`. - in: query name: by schema: description: >- Range-total breakdown: `device`, `device_type`, or `oem` (manufacturer). Mutually exclusive with `resolution`. title: By type: string required: false description: >- Range-total breakdown: `device`, `device_type`, or `oem` (manufacturer). Mutually exclusive with `resolution`. - in: query name: limit schema: default: 50 description: >- Max rows for `by=device` (the top savers by range total). Ignored by other modes. maximum: 1000 minimum: 1 title: Limit type: integer required: false description: >- Max rows for `by=device` (the top savers by range total). Ignored by other modes. - in: query name: order schema: default: desc description: >- Sort direction for `by=device` by savings: `desc` (best savers) or `asc` (worst performers). Ignored by other modes. title: Order type: string required: false description: >- Sort direction for `by=device` by savings: `desc` (best savers) or `asc` (worst performers). Ignored by other modes. responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/OrganizationSavingsOutput' security: - OAuth2: [] components: schemas: OrganizationSavingsOutput: properties: currency: description: The organization's currency code; every amount is in it. title: Currency type: string total_savings: title: Total Savings type: number heat_pump_savings: title: Heat Pump Savings type: number electric_vehicle_savings: title: Electric Vehicle Savings type: number inverter_savings: title: Inverter Savings type: number required: - currency - total_savings - heat_pump_savings - electric_vehicle_savings - inverter_savings title: OrganizationSavingsOutput type: object securitySchemes: OAuth2: type: oauth2 flows: password: tokenUrl: /api/partners/v2.0/auth/token scopes: {} clientCredentials: tokenUrl: /oauth2/token/ scopes: {} ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.