> ## 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.

# Health-Check

> Nicht authentifizierter Health-Check. Erfordert keinen API-Schlüssel.



## OpenAPI

````yaml /api-reference/energy-management/openapi.de.yaml GET /health
openapi: 3.1.0
info:
  title: RiDERgy Energy Management API
  version: '1.0'
  license:
    name: Proprietary
    identifier: LicenseRef-Proprietary
  description: |
    Programmatische Steuerung von Ladeleistungslimits über Standorte, einzelne
    Ladepunkte, Organisationen und standortübergreifende Cluster hinweg.

    ## Authentifizierung
    Jeder Endpunkt außer `GET /health` benötigt einen `x-api-key`-Header. Der
    Schlüssel bestimmt Ihren Mandanten — er wird nie aus dem Request-Body oder
    einem anderen Header gelesen, sodass ein Schlüssel eines Mandanten nicht
    auf die Daten eines anderen Mandanten zugreifen kann.

    Ihr Mandant muss das Feature der Energy Management API aktiviert haben,
    andernfalls schlagen Anfragen mit `403 FEATURE_NOT_ENABLED` fehl.
    Kontaktieren Sie RiDERgy, um es zu aktivieren.

    ## Prioritätsmodell
    Standort- und Ladepunkt-Limits werden über **prioritätsbasierte
    Zeitfenster-Profile** gesteuert:

    - Prioritäten reichen von **0 (niedrigste) bis 10 (höchste)**, im
      OCPP-Stack-Stil.
    - Ein Ziel (Standort oder Ladepunkt-Connector) kann bis zu 11 Profile
      haben, eines pro Prioritätsstufe, jeweils mit eigenem
      `[startTime, endTime)`-Zeitfenster.
    - Zu jedem Zeitpunkt ist das **effektive Limit** der `limitKw`-Wert des
      Profils mit der höchsten Priorität, dessen Zeitfenster gerade aktiv ist.
    - Ist kein Profil aktiv, fällt ein Standort auf sein `permanentLimitKw`
      zurück.
    - Wird ein Profil mit einer Priorität übermittelt, für die für dieses Ziel
      bereits eines existiert, wird dieses **ersetzt**.
    - Profile werden automatisch zu ihrer `startTime`/`endTime` angewendet und
      wieder rückgängig gemacht — nach dem Erstellen eines Profils sind keine
      weiteren API-Aufrufe erforderlich. Profil-Datensätze werden nie gelöscht,
      sodass die Historie weiterhin abfragbar bleibt.

    ## Fehler
    Alle Fehler haben diese Form:

    ```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: Nicht authentifizierter Service-Health-Check.
  - name: Locations
    description: >-
      Lesen und Setzen von Leistungslimits und Prioritätsprofilen auf
      Standortebene.
  - name: Chargers
    description: >-
      Sperren einzelner Ladepunkt-Connectoren auf ein festes Leistungslimit für
      ein Zeitfenster.
  - name: Organizations
    description: >-
      Mandantenweite Cap-Profile (werden nur erfasst — Durchsetzung noch nicht
      aktiv).
  - name: Clusters
    description: >-
      Gruppierung von Standorten unter einem gemeinsamen kW-Limit und Anwendung
      von Zeitplänen über diese hinweg.
paths:
  /health:
    get:
      tags:
        - Health
      summary: Health check
      description: Nicht authentifizierter Health-Check. Erfordert keinen API-Schlüssel.
      operationId: getHealth
      responses:
        '200':
          description: Service ist gesund
          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: >-
        Mandanten-spezifischer API-Schlüssel. Der Mandant wird aus dem Schlüssel
        abgeleitet — nie aus dem Request.

````