> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ridergy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Controllo dello stato

> Controllo dello stato non autenticato. Non richiede una chiave API.



## OpenAPI

````yaml /api-reference/energy-management/openapi.it.yaml GET /health
openapi: 3.1.0
info:
  title: RiDERgy Energy Management API
  version: '1.0'
  license:
    name: Proprietary
    identifier: LicenseRef-Proprietary
  description: |
    Controllo programmatico dei limiti di potenza di ricarica su location,
    singoli charger, organizzazioni e cluster cross-location.

    ## Autenticazione
    Ogni endpoint, eccetto `GET /health`, richiede un header `x-api-key`. La
    chiave determina il tenant — non viene mai letta dal corpo della richiesta
    né da altri header, quindi una chiave di un tenant non può accedere ai
    dati di un altro tenant.

    Il tuo tenant deve avere abilitata la funzionalità Energy Management API,
    altrimenti le richieste falliscono con `403 FEATURE_NOT_ENABLED`. Contatta
    RiDERgy per abilitarla.

    ## Modello di priorità
    I limiti di location e charger sono controllati tramite **profili con
    finestre di priorità**:

    - Le priorità vanno da **0 (più bassa) a 10 (più alta)**, in stile stack
      OCPP.
    - Un target (location o connettore del charger) può avere fino a 11
      profili, uno per livello di priorità, ciascuno con la propria finestra
      `[startTime, endTime)`.
    - In ogni momento, il **limite effettivo** è il `limitKw` del profilo a
      priorità più alta la cui finestra è attualmente attiva.
    - Se nessun profilo è attivo, una location ricade sul proprio
      `permanentLimitKw`.
    - L'invio di un profilo a una priorità che ne ha già uno per quel target
      lo **sostituisce**.
    - I profili vengono applicati e ripristinati automaticamente in base a
      `startTime`/`endTime` — una volta creato un profilo non sono necessarie
      ulteriori chiamate API. I record dei profili non vengono mai eliminati,
      quindi la cronologia rimane interrogabile.

    ## Errori
    Tutti gli errori condividono questa struttura:

    ```json
    {
      "error": {
        "code": "LOCATION_NOT_FOUND",
        "message": "Location 123 was not found for the provided tenant",
        "requestId": "b1f6e6b0-..."
      }
    }
    ```
servers:
  - url: https://api.ridergy.com/v1
    description: Production
security:
  - ApiKeyAuth: []
tags:
  - name: Health
    description: Controllo dello stato del servizio non autenticato.
  - name: Locations
    description: >-
      Leggi e imposta i limiti di potenza e i profili di priorità a livello di
      location.
  - name: Chargers
    description: >-
      Blocca singoli connettori del charger su un limite di potenza fisso per
      una finestra temporale.
  - name: Organizations
    description: >-
      Profili di cap a livello di tenant (solo registrati — l'enforcement non è
      ancora attivo).
  - name: Clusters
    description: >-
      Raggruppa location sotto un cap kW condiviso e applica schedulazioni su di
      esse.
paths:
  /health:
    get:
      tags:
        - Health
      summary: Health check
      description: Controllo dello stato non autenticato. Non richiede una chiave API.
      operationId: getHealth
      responses:
        '200':
          description: Il servizio è operativo
          content:
            application/json:
              schema:
                type: object
                properties:
                  status:
                    type: string
                    example: ok
      security: []
components:
  securitySchemes:
    ApiKeyAuth:
      type: apiKey
      in: header
      name: x-api-key
      description: >-
        Chiave API per-tenant. Il tenant viene derivato dalla chiave — mai dalla
        richiesta.

````