Enphase Energy · Authentication Profile

Enphase Authentication

Authentication

Enphase Energy secures its APIs with oauth2, apiKey, and http across 6 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode, password, and clientCredentials flow(s).

EnergyUnited StatesSolarDERRenewablesBattery StorageEV ChargingDemand ResponseVirtual Power PlantGrid ServicesMicroinvertersHome Energy ManagementSmart MeteringTelemetry
Methods: oauth2, apiKey, http Schemes: 6 OAuth flows: authorizationCode, password, clientCredentials API key in: query, header

Security Schemes

oauth2_authorization_code oauth2
oauth2_password oauth2
oauth2_client_credentials oauth2
api_key_query apiKey
· in: query (key)
api_key_header apiKey
· in: header (x-api-key)
bearer http
scheme: bearer

Source

Authentication Profile

Raw ↑
generated: '2026-07-27'
method: searched
source: openapi/enphase-monitoring-api-openapi.json, openapi/enphase-commissioning-api-openapi.json,
  openapi/enphase-vpp-api-openapi.json
docs: https://developer-v4.enphase.com/docs/quickstart.html
notes: >-
  None of the three published Enphase specs declare a securityScheme - the Monitoring and
  Commissioning Swagger 2.0 documents carry no securityDefinitions at all, and the VPP OpenAPI
  3.0.1 document models its credentials as ordinary Authorization and x-api-key header
  parameters on every operation. The profile below is therefore searched from the Enphase
  Developer Portal quick start guide and the VPP Auth controller, not derived from the specs.
  Every Enphase API call carries two credentials at once: an OAuth 2.0 bearer access token AND
  the application API key.
summary:
  types:
  - oauth2
  - apiKey
  - http
  api_key_in:
  - query
  - header
  oauth2_flows:
  - authorizationCode
  - password
  - clientCredentials
  two_factor_credential: true
schemes:
- name: oauth2_authorization_code
  type: oauth2
  flow: authorizationCode
  used_by: Enphase Monitoring API (developer applications on the Watt, Kilowatt and Megawatt plans)
  authorizationUrl: https://api.enphaseenergy.com/oauth/authorize
  tokenUrl: https://api.enphaseenergy.com/oauth/token
  default_redirect_uri: https://api.enphaseenergy.com/oauth/redirect_uri
  client_authentication: HTTP Basic - base64(client_id:client_secret) in the Authorization header
  state_parameter: supported and recommended, echoed back to the redirect_uri
  consent: >-
    The system owner (homeowner) signs in with Enlighten credentials, sees the application name,
    developer name and requested access controls, then approves or rejects. Rejection returns
    access_denied as a query parameter on the redirect_uri.
  token_ttl: access_token 1 day (expires_in 86393), refresh_token 1 month
  refresh: POST /oauth/token with grant_type=refresh_token; a new refresh_token is issued each time
  token_response_fields:
  - access_token
  - token_type
  - refresh_token
  - expires_in
  - scope
  - enl_uid
  - enl_cid
  - enl_password_last_changed
  - is_internal_app
  - app_type
  - jti
  docs: https://developer-v4.enphase.com/docs/quickstart.html
- name: oauth2_password
  type: oauth2
  flow: password
  used_by: Enphase Commissioning API and full Monitoring API access on the Partner plan
  tokenUrl: https://api.enphaseenergy.com/oauth/token
  credentials: Enphase cloud (Enlighten) email and password of the installer - not the developer
    portal account
  client_authentication: HTTP Basic - base64(client_id:client_secret) in the Authorization header
  eligibility: >-
    Partner applications can only be created by a self-installer or a member of an installer
    company with at least ten installed systems; the application starts in a pending state and is
    enabled after Enphase verification.
  token_ttl: access_token 1 day, refresh_token 1 month
  docs: https://developer-v4.enphase.com/docs/quickstart.html
- name: oauth2_client_credentials
  type: oauth2
  flow: clientCredentials
  used_by: Enphase VPP API (grid-services partners)
  tokenUrl: https://vpp.enphaseenergy.com/auth/oauth2/token
  client_authentication: base64(clientId:clientSecret) in the Authorization header,
    Content-Type application/x-www-form-urlencoded, Accept application/json
  token_ttl: 3600 seconds, no refresh token - regenerate through the same call
  source_operation: openapi/enphase-vpp-api-openapi.json#getToken
- name: api_key_query
  type: apiKey
  in: query
  parameter: key
  used_by: Enphase Monitoring API and Enphase Commissioning API
  description: >-
    The per-application API key issued by the developer portal, sent on every request as ?key=.
    It must belong to the same application as the client_id the access token was minted for -
    a mismatch returns 401 "API Key -Client mismatch".
- name: api_key_header
  type: apiKey
  in: header
  parameter: x-api-key
  used_by: Enphase VPP API
  description: Unique API key of the grid-services partner account, required on every VPP operation.
- name: bearer
  type: http
  scheme: bearer
  used_by: all three APIs
  description: Authorization- Bearer <access_token> on every request alongside the API key.
transport_security:
  tls_minimum: TLS 1.2
  announced: Effective April 1, 2023 the Enphase API only supports TLS 1.2 and will not accept
    applications on older TLS versions.
  source: https://developer-v4.enphase.com/docs/quickstart.html
gaps:
- No OpenID Connect discovery document; /.well-known/openid-configuration returns 404 on
  api.enphaseenergy.com and developer-v4.enphase.com.
- No RFC 8414 authorization-server metadata; /.well-known/oauth-authorization-server returns 404.
- No PKCE, device code, or mTLS option documented.
- The Commissioning and Partner-plan flows use the OAuth 2.0 resource-owner password grant, which
  is deprecated by OAuth 2.1 and requires the installer to hand raw Enlighten credentials to the
  client application.
related:
- scopes/enphase-scopes.yml
- conventions/enphase-conventions.yml
- plans/enphase-plans.yml