> ## 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 applied-mode history for a heat pump > The mode changes one heat pump was actually put into over a window, oldest first — the measured companion of the planned `/schedules`, drawn instead from the steering workflow's own record of what it sent and what the manufacturer accepted. Each item is one change: the time it took effect, the mode, the channel it steered, and how much of it landed. Modes use the same four-value vocabulary as `state` on `/schedules`, so the two series can be read against each other over one window. A change is listed once the manufacturer accepted at least one of the writes behind it, and `delivery` says whether it accepted all of them; a command that landed nothing is not listed. Acceptance is not proof the pump moved — physical compliance is judged separately against telemetry. A repeated mode is the workflow re-asserting a lever that expires, not a new change. The window is half-open, both bounds are required, and it may span at most 31 days. History reaches back 30 days: the steering log this is read from drops older rows, so a window further back returns fewer changes than the pump had. Applied modes are recorded for the manufacturers steered by the Temporal workflows; an empty response means no change was recorded, never that the pump refused one. ## OpenAPI ````yaml https://app.podero.com/api/partners/v2.0/openapi.json get /api/partners/v2.0/org/{org_id}/users/{user_id}/heat-pumps/{heat_pump_id}/applied-modes 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. termsOfService: https://www.podero.com/terms-and-conditions servers: [] security: [] paths: /api/partners/v2.0/org/{org_id}/users/{user_id}/heat-pumps/{heat_pump_id}/applied-modes: get: tags: - User Heat Pumps summary: Get applied-mode history for a heat pump description: >- The mode changes one heat pump was actually put into over a window, oldest first — the measured companion of the planned `/schedules`, drawn instead from the steering workflow's own record of what it sent and what the manufacturer accepted. Each item is one change: the time it took effect, the mode, the channel it steered, and how much of it landed. Modes use the same four-value vocabulary as `state` on `/schedules`, so the two series can be read against each other over one window. A change is listed once the manufacturer accepted at least one of the writes behind it, and `delivery` says whether it accepted all of them; a command that landed nothing is not listed. Acceptance is not proof the pump moved — physical compliance is judged separately against telemetry. A repeated mode is the workflow re-asserting a lever that expires, not a new change. The window is half-open, both bounds are required, and it may span at most 31 days. History reaches back 30 days: the steering log this is read from drops older rows, so a window further back returns fewer changes than the pump had. Applied modes are recorded for the manufacturers steered by the Temporal workflows; an empty response means no change was recorded, never that the pump refused one. operationId: >- integrations_api_api_v2_organizations_users_heat_pumps_applied_modes_router_get_heat_pump_applied_modes parameters: - in: path name: org_id schema: description: The organization ID format: uuid title: Org Id type: string required: true description: The organization ID - in: path name: user_id schema: description: The user ID the heat pump belongs to format: uuid title: User Id type: string required: true description: The user ID the heat pump belongs to - in: path name: heat_pump_id schema: description: The heat pump ID format: uuid title: Heat Pump Id type: string required: true description: The heat pump ID - in: query name: from schema: description: Inclusive lower bound on the effect time (ISO 8601, UTC) format: date-time title: From type: string required: true description: Inclusive lower bound on the effect time (ISO 8601, UTC) - in: query name: to schema: description: Exclusive upper bound on the effect time (ISO 8601, UTC) format: date-time title: To type: string required: true description: Exclusive upper bound on the effect time (ISO 8601, UTC) responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/HeatPumpAppliedModesResponse' security: - OAuth2: [] components: schemas: HeatPumpAppliedModesResponse: properties: metadata: $ref: '#/components/schemas/HeatPumpAppliedModesMetadata' data: items: $ref: '#/components/schemas/HeatPumpAppliedModeItem' title: Data type: array required: - metadata - data title: HeatPumpAppliedModesResponse type: object HeatPumpAppliedModesMetadata: properties: query: $ref: '#/components/schemas/HeatPumpAppliedModesQuery' required: - query title: HeatPumpAppliedModesMetadata type: object HeatPumpAppliedModeItem: description: One mode change that reached the pump. properties: time: description: When the mode took effect, which is the time it was steered for. format: date-time title: Time type: string mode: anyOf: - type: string - type: 'null' description: >- Mode the pump was put into: `min`, `low`, `mid` or `max` — the same vocabulary as `state` on `/schedules`. Null when the recorded mode is outside it, which no optimizer schedule produces. title: Mode channel: description: >- What the change steered: `combined` for a pump steered as one, or `dhw` and `room_heating` for a pump whose hot water and heating are steered apart. A pump on split channels reports one series per channel over the same window; `/schedules` plans the combined one. title: Channel type: string delivery: $ref: '#/components/schemas/AppliedModeDelivery' description: >- How much of the change the manufacturer took: `complete` when it accepted every write the command made, `partial` otherwise. A `partial` change reached the pump but not in full — some of its writes were refused, or the manufacturer accepted a write our own steering recorded as failed — so its `mode` is what was asked for rather than a mode the pump can be assumed to have held. Judge a `partial` against telemetry before reading it as followed. required: - time - mode - channel - delivery title: HeatPumpAppliedModeItem type: object HeatPumpAppliedModesQuery: description: Echo of the request, so a stored response says what it answered. properties: org_id: format: uuid title: Org Id type: string user_id: format: uuid title: User Id type: string heat_pump_id: format: uuid title: Heat Pump Id type: string from_datetime: description: Inclusive start of the window the response covers. format: date-time title: From Datetime type: string to_datetime: description: Exclusive end of the window the response covers. format: date-time title: To Datetime type: string required: - org_id - user_id - heat_pump_id - from_datetime - to_datetime title: HeatPumpAppliedModesQuery type: object AppliedModeDelivery: description: >- How much of a steering command the manufacturer took, as the steering log recorded it. enum: - complete - partial title: AppliedModeDelivery type: string securitySchemes: OAuth2: type: oauth2 flows: password: tokenUrl: /api/partners/v2.0/auth/token scopes: {} clientCredentials: tokenUrl: /api/partners/v2.0/auth/token scopes: {} ````