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

# Verificação de integridade

> Verificação de integridade sem autenticação. Não requer uma chave de API.



## OpenAPI

````yaml /api-reference/energy-management/openapi.pt.yaml GET /health
openapi: 3.1.0
info:
  title: RiDERgy Energy Management API
  version: '1.0'
  license:
    name: Proprietary
    identifier: LicenseRef-Proprietary
  description: >
    Controle programático dos limites de potência de carregamento em locais,

    carregadores individuais, organizações e clusters entre locais.


    ## Autenticação

    Todos os endpoints, exceto `GET /health`, exigem um cabeçalho `x-api-key`. A

    chave determina o seu tenant — ela nunca é lida do corpo da requisição ou de

    qualquer outro cabeçalho, portanto uma chave de um tenant não pode acessar
    os

    dados de outro tenant.


    O seu tenant precisa ter o recurso Energy Management API habilitado, caso

    contrário as requisições falharão com `403 FEATURE_NOT_ENABLED`. Entre em

    contato com a RiDERgy para habilitá-lo.


    ## Modelo de prioridade

    Os limites de locais e carregadores são controlados por meio de **perfis com

    janelas de prioridade**:


    - As prioridades variam de **0 (mais baixa) a 10 (mais alta)**, no estilo da
      pilha OCPP.
    - Um alvo (local ou conector de carregador) pode ter até 11 perfis, um por
      nível de prioridade, cada um com sua própria janela `[startTime, endTime)`.
    - A qualquer momento, o **limite efetivo** é o `limitKw` do perfil de maior
      prioridade cuja janela esteja atualmente ativa.
    - Se nenhum perfil estiver ativo, um local volta a usar o seu
      `permanentLimitKw`.
    - O envio de um perfil em uma prioridade que já possui um perfil para esse
      alvo **substitui** o existente.
    - Os perfis são aplicados e revertidos automaticamente em seus horários
      `startTime`/`endTime` — não são necessárias chamadas adicionais à API após
      a criação de um perfil. Os registros de perfis nunca são excluídos, então
      o histórico permanece consultável.

    ## Erros

    Todos os erros compartilham este formato:


    ```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: Verificação de integridade do serviço sem autenticação.
  - name: Locations
    description: >-
      Leia e defina limites de potência em nível de local e perfis de
      prioridade.
  - name: Chargers
    description: >-
      Trave conectores de carregadores individuais em um limite de potência fixo
      durante uma janela de tempo.
  - name: Organizations
    description: >-
      Perfis de limite máximo em toda a organização (apenas registrados — a
      aplicação ainda não está ativa).
  - name: Clusters
    description: >-
      Agrupe locais sob um limite de kW compartilhado e aplique cronogramas
      entre eles.
paths:
  /health:
    get:
      tags:
        - Health
      summary: Health check
      description: >-
        Verificação de integridade sem autenticação. Não requer uma chave de
        API.
      operationId: getHealth
      responses:
        '200':
          description: O serviço está saudável
          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: >-
        Chave de API por tenant. O tenant é derivado da chave — nunca da
        requisição.

````