generated: '2026-07-27' method: derived source: >- openapi/ (76 documents, 798 operations), well-known/aemo-derr-openid-configuration.json, well-known/aemo-security.txt, https://dev.aemo.com.au/oauth description: >- Which cross-cutting and industry standards the AEMO API estate actually conforms to, asserted from evidence in the harvested specs and probed discovery documents. AEMO's strongest conformance claim is the Consumer Data Right: its energy APIs implement the Consumer Data Standards Australia contract (v1.36.0 in the harvested documents), which itself layers on FAPI-style headers and OAuth 2.0 / OIDC. Everything outside CDR is a mixture of OpenAPI 3.0 REST and SOAP/aseXML with no adopted API-design standard. standards: - id: openapi-3.0 conforms: true evidence: >- All 76 documents in openapi/ are OpenAPI 3.0.1 or 3.0.3. AEMO publishes them itself from its Azure API Management developer portal (openapi-link export plus the portal's operations API). - id: consumer-data-standards-au conforms: true version: 1.36.0 evidence: >- openapi/aemo-cds-energy-api-openapi.yml and openapi/aemo-cds-common-api-openapi.yml implement the CDS Energy and Common contracts (x-v / x-min-v version negotiation, x-fapi-* headers, x-cds-client-headers, x-cds-arrangement, page / page-size pagination, CDS error object, the mandated 400/404/406/422 error-code sets). docs: https://consumerdatastandardsaustralia.github.io/standards/ regulator: https://www.cdr.gov.au/ - id: cdr-energy-secondary-data-holder conforms: true evidence: >- AEMO operates as the Consumer Data Right secondary data holder for energy, exposing /NEMRetail/cds-au/v1/secondary/energy and the CDR discovery endpoints (openapi/aemo-cdr-openapi.yml, openapi/aemo-cdr-common-openapi.yml). docs: https://aemo.com.au/initiatives/major-programs/cdr-at-aemo - id: fapi conforms: partial evidence: >- The CDR APIs carry the FAPI interaction headers required by the Consumer Data Standards — x-fapi-interaction-id (29 operations), x-fapi-auth-date and x-fapi-customer-ip-address (23 each). AEMO publishes no independent FAPI certification of its own; conformance is inherited from the CDS profile. - id: oauth2 conforms: true evidence: >- AEMO documents an OAuth 2.0 client_credentials flow at https://api.aemo.com.au/oauth/v1/token (docs https://dev.aemo.com.au/oauth), returning a JWT access token. No scopes are published for this flow. - id: openid-connect conforms: true evidence: >- The DER Register consumer-registration API authenticates through an Azure AD B2C OpenID Connect provider. Discovery document harvested to well-known/aemo-derr-openid-configuration.json (issuer, authorization/token endpoints, jwks_uri, RS256, scopes_supported [openid]). - id: mutual-tls conforms: true evidence: >- AEMO issues and requires AEMO-signed TLS client certificates for the e-Hub gateway, and ships a self-service certificate lifecycle API (openapi/aemo-tls-certificate-mgmt-v1-openapi.yml: list, download, generate, reissue, renew, revoke). - id: rfc9116-security-txt conforms: true evidence: >- https://www.aemo.com.au/.well-known/security.txt returns 200 with a Contact field (mailto:cybersecurity@aemo.com.au). It omits the mandatory Expires field, so it is not a fully conformant RFC 9116 document. - id: rfc9457-problem-details conforms: false evidence: No application/problem+json response is declared in any of the 798 operations. - id: rfc8594-sunset-header conforms: false evidence: No Sunset or Deprecation header is documented on any operation. - id: idempotency-key conforms: false evidence: No Idempotency-Key header or equivalent appears in any specification or in the docs. - id: asexml conforms: true evidence: >- The B2B / B2M / P2P e-Hub messaging APIs carry aseXML business documents as payloads over HTTPS (openapi/aemo-b2bmessaging-*, openapi/aemo-b2mmessaging-*, openapi/aemo-p2pmessaging-*, openapi/aemo-hubmsgmgt-*). - id: soap-1.1 conforms: true evidence: >- The WEM balancing, LFAS, pre-balancing, market and system-management report APIs are SOAP pass-throughs exposed through APIM as POST with a soapAction query parameter; 409 operations across the catalogue carry a soapAction discriminator. - id: json-api conforms: false - id: odata conforms: false - id: scim conforms: false - id: fhir conforms: false - id: graphql conforms: false evidence: No GraphQL endpoint was found on any AEMO host. - id: asyncapi conforms: false evidence: >- AEMO operates a real asynchronous message-delivery surface (the e-Hub push-push model) but publishes no AsyncAPI document for it. See asyncapi/aemo-ehub-events.yml. certifications: published: false note: >- AEMO publishes no trust centre and no SOC 2 / ISO 27001 / PCI DSS / HIPAA / FedRAMP certification for its API platform. AEMO does administer the Australian Energy Sector Cyber Security Framework (AESCSF) on behalf of the Australian energy sector — that is a maturity framework AEMO runs for others, not a certification of AEMO's own platform, and it is not recorded here as an AEMO compliance claim. regulatory_context: - name: Consumer Data Right (energy) role: AEMO is the CDR secondary data holder for energy. regulator: https://www.cdr.gov.au/ standards: https://consumerdatastandardsaustralia.github.io/standards/ - name: National Electricity Rules / National Gas Rules role: >- AEMO's market IT interfaces exist to discharge statutory functions under the energy rules; participant obligations for using them sit in the market procedures. - name: Privacy Act 1988 (Cth) and the Australian Privacy Principles role: AEMO is subject to the Privacy Act; see its published privacy policy. url: https://aemo.com.au/en/privacy-and-legal-notices/privacy-policy cross_references: authentication: authentication/aemo-authentication.yml scopes: scopes/aemo-scopes.yml errors: errors/aemo-error-codes.yml security: security/aemo-vulnerability-disclosure.yml