Powershop · Authentication Profile

Powershop Authentication

Authentication

Powershop secures its APIs with oauth2, openIdConnect, and mutualTLS across 0 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode flow(s).

EnergyAustraliaUtilitiesElectricityGasConsumer Data RightEnergy RetailSmart MeteringSolarTariffsOpen Data
Methods: oauth2, openIdConnect, mutualTLS Schemes: 0 OAuth flows: authorizationCode API key in:

Security Schemes

Source

Authentication Profile

Raw ↑
generated: '2026-07-27'
method: searched
source: >-
  openapi/powershop-cdr-energy-api-openapi.json +
  openapi/powershop-cdr-common-api-openapi.json (no securitySchemes declared) and
  the DSB Consumer Data Standards security profile
docs: https://consumerdatastandardsaustralia.github.io/standards/#security-profile
summary:
  types: [oauth2, openIdConnect, mutualTLS]
  api_key_in: []
  oauth2_flows: [authorizationCode]
  note: >-
    Powershop's API surface is split cleanly in two, and the two halves have
    opposite auth models. The public half — the CDS Discovery endpoints on
    Powershop's own registered host, and the Generic Tariff (plan) endpoints the
    Australian Energy Regulator serves on Powershop's behalf — requires NO
    authentication at all: no API key, no registration, no terms click-through.
    The only mandatory request signalling is the CDS x-v version header. The
    consented half — accounts, balances, invoices, billing, payment schedules,
    concessions, service points, usage and DER — is reachable only by an ACCC
    accredited data recipient holding a valid consumer consent, over the CDR
    Register's mutual-TLS-secured infrastructure.
schemes: []
schemes_note: >-
  Neither Data Standards Body OpenAPI document declares components.securitySchemes
  and no operation declares security[]. The CDR authorisation model is specified
  out-of-band in the Consumer Data Standards security profile rather than inline
  in the API definitions, so a mechanical derive over the specs yields zero
  schemes. The profile below was captured from the published standards, not
  invented.
surfaces:
- name: CDS Discovery (Powershop's own registered CDR host)
  base_url: https://public.cdr.powershop.com.au/cds-au/v1
  authenticated: false
  credential: none
  required_headers:
  - {name: x-v, required: true, description: 'CDS endpoint version. Confirmed live: omitting it returns HTTP 400 urn:au-cds:error:cds-all:Header/Missing with detail "x-v header is mandatory for CDR endpoint requests".'}
  - {name: x-min-v, required: false, description: Minimum acceptable endpoint version.}
  operations: [getStatus, getOutages]
  verified: '2026-07-27 — HTTP 200 with x-v:1 response header'
- name: CDR Generic Tariff (AER Energy Made Easy host)
  base_url: https://cdr.energymadeeasy.gov.au/powershop/cds-au/v1
  authenticated: false
  credential: none
  required_headers:
  - {name: x-v, required: true, description: 'Confirmed live: max supported version for listEnergyPlans is 1; x-v:9 returns HTTP 406 urn:au-cds:error:cds-all:Header/UnsupportedVersion.'}
  operations: [listEnergyPlans, getEnergyPlanDetail]
  verified: '2026-07-27 — HTTP 200, meta.totalRecords 482'
- name: CDR Energy consumer data (accredited + consented)
  base_url: null
  base_url_note: >-
    Not published anonymously. The authenticated data-holder base URI is resolved
    through the CDR Register by accredited participants over mutual TLS, so no
    URL is asserted here.
  authenticated: true
  gate: accredited-only
  operations:
  - listEnergyAccounts
  - getEnergyAccountDetail
  - getEnergyAccountBalance
  - listEnergyAccountBalancesBulk
  - listEnergyAccountBalancesSpecificAccounts
  - getEnergyAccountInvoices
  - listEnergyAccountInvoicesBulk
  - listEnergyInvoicesForSpecificAccounts
  - getBillingForEnergyAccount
  - listEnergyAccountBillingBulk
  - listEnergyAccountBillingForSpecificAccounts
  - getEnergyAccountPaymentSchedule
  - getEnergyAccountConcessions
  - listElectricityServicePoints
  - getElectricityServicePointDetail
  - getElectricityServicePointUsage
  - listElectricityUsageBulk
  - listElectricityUsageForServicePoints
  - getElectricityDERForServicePoint
  - listElectricityDERBulk
  - listElectricityDERForSpecificServicePoints
  - getCustomer
  - getCustomerDetail
cdr_security_profile:
  regime: Consumer Data Right (Australia) — energy sector designation
  standard: CDR Consumer Data Standards v1.36.0 security profile
  docs: https://consumerdatastandardsaustralia.github.io/standards/#security-profile
  protocols:
  - {name: OAuth 2.0, role: authorisation framework}
  - {name: OpenID Connect, role: identity layer and authorisation code flow}
  - {name: FAPI, role: financial-grade API hardening profile mandated by the CDS security profile}
  - {name: Mutual TLS, role: client authentication and sender-constrained tokens using CDR Register-issued certificates}
  - {name: PAR (RFC 9126), role: pushed authorisation requests}
  - {name: JARM, role: signed authorisation responses}
  grant: authorization_code
  client_registration: >-
    Dynamic client registration against the data holder, brokered by the CDR
    Register; the accredited data recipient's software product must be listed on
    the Register and hold Register-issued transport and signing certificates.
  scopes: scopes/powershop-scopes.yml
consumer_authorisation_flow:
  source: https://www.powershop.com.au/privacy-policy/cdr-policy
  steps:
  - The consumer starts in the accredited data recipient's app and selects Powershop as their energy provider.
  - The consumer is redirected to Powershop to authenticate.
  - Powershop verifies identity with a one-time password sent to the email address on the account.
  - The consumer selects which accounts, which data clusters, and the sharing duration.
  - Powershop issues the authorisation; the ADR exchanges it for a mutual-TLS-bound access token.
  dashboard: https://dashboard.cdr.powershop.com.au/
  dashboard_note: Consumer-facing consent management UI (HTTP 200 on 2026-07-27), not a developer surface.
what_a_developer_must_do:
  public_data: Nothing. Send an x-v header. No signup, no key, no accreditation.
  consumer_data: >-
    Become an ACCC accredited data recipient (or operate as the authorised
    representative or CDR representative of one), be listed on the CDR Register,
    hold Register-issued mutual-TLS certificates, and obtain an explicit,
    time-bounded, scoped consent from each consumer. There is no commercial,
    partner or sandbox path around this. Powershop issues no API key at any tier.
no_first_party_program: >-
  Powershop runs no developer portal, no API key issuance, no sandbox and no
  partner API programme. It stated publicly in 2017 that it has no public API and
  directed customers to download usage data from the account UI instead.
cross_links:
  scopes: scopes/powershop-scopes.yml
  conventions: conventions/powershop-conventions.yml
  conformance: conformance/powershop-conformance.yml