> ## 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. # Zugriffstoken anfordern > Tauscht Client-Zugangsdaten gegen ein kurzlebiges Bearer-Token (3600s) ein. Akzeptiert Zugangsdaten über: - `Authorization: Basic base64(client_id:client_secret)` mit `grant_type=client_credentials` im Request-Body (RFC 6749) - JSON-Body mit `client_id`, `client_secret` und `grant_type` ## OpenAPI ````yaml api-reference/energy-management/openapi.de.yaml POST /oauth/token 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` und `POST /oauth/token` erfordert ein Bearer-Token, das über den OAuth 2.0 client_credentials-Flow bezogen wird: 1. Erstellen Sie OAuth-Client-Zugangsdaten im RiDERgy-Dashboard. 2. Tauschen Sie diese über `POST /oauth/token` gegen ein kurzlebiges Access-Token ein. 3. Übergeben Sie das Token als `Authorization: Bearer ` bei jeder Anfrage. Token laufen nach 3600 Sekunden ab. Ihr Mandant ist im Token eingebettet und kann nicht gefälscht werden. Zugangsdaten eines Mandanten können nicht auf einen anderen Mandanten zugreifen. 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. ## Scopes Token enthalten Scopes, die steuern, welche Endpunkte zugänglich sind: `locations:read`, `locations:write`, `clusters:read`, `clusters:write`, `chargers:write`, `org:write`. Anfragen an Endpunkte, die einen Scope erfordern, den das Token nicht besitzt, schlagen mit `403 INSUFFICIENT_SCOPE` fehl. ## 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: - BearerAuth: [] tags: - name: Auth description: OAuth 2.0 Token-Endpunkt für den client_credentials-Grant. - 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: /oauth/token: post: tags: - Auth summary: Obtain an access token description: > Tauscht Client-Zugangsdaten gegen ein kurzlebiges Bearer-Token (3600s) ein. Akzeptiert Zugangsdaten über: - `Authorization: Basic base64(client_id:client_secret)` mit `grant_type=client_credentials` im Request-Body (RFC 6749) - JSON-Body mit `client_id`, `client_secret` und `grant_type` operationId: createToken requestBody: required: true content: application/json: schema: type: object required: - grant_type properties: grant_type: type: string enum: - client_credentials client_id: type: string description: Erforderlich, wenn kein Basic-Auth-Header verwendet wird. example: emcl_a1b2c3d4e5f67890a1b2c3d4e5f67890 client_secret: type: string description: Erforderlich, wenn kein Basic-Auth-Header verwendet wird. example: emcs_... examples: jsonBody: value: grant_type: client_credentials client_id: emcl_a1b2c3d4e5f67890a1b2c3d4e5f67890 client_secret: emcs_a1b2c3d4... responses: '200': description: Access-Token ausgestellt content: application/json: schema: type: object properties: access_token: type: string description: JWT-Bearer-Token example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... token_type: type: string example: Bearer expires_in: type: integer description: Token-Lebensdauer in Sekunden example: 3600 scope: type: string description: Leerzeichen-getrennte Liste der gewährten Scopes example: >- locations:read locations:write clusters:read clusters:write chargers:write org:write '400': description: >- Ungültige Anfrage (fehlender grant_type oder nicht unterstützter Grant) content: application/json: schema: type: object properties: error: type: string example: unsupported_grant_type error_description: type: string example: Only client_credentials grant type is supported '401': description: Ungültige Client-Zugangsdaten content: application/json: schema: type: object properties: error: type: string example: invalid_client error_description: type: string example: Invalid client credentials security: [] components: securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT description: > OAuth 2.0 Access-Token, bezogen über `POST /oauth/token` mit client_credentials-Grant. Mandant und Scopes sind im JWT eingebettet. Keine zusätzlichen Header erforderlich. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.