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