Power Quality Data API

The Power Quality Data (PQD Power Quality Data. Measurements of power supply characteristics exchanged between participants and AEMO.) API Application Programming Interface; a set of clearly defined methods of communication between various software components. provides an interface for submitting and retrieving structured basic power quality data within the NEM. For details about the API endpoints, server, payload and response schemas, and security details, see the Power Quality Data API Reference.

7.1 Access

Participant administrators provide access to the PQD API using the entity PQD_BPQD Basic Power Quality Data. A subset of power quality data consisting of voltage, current, and phase angle. The following permissions provide access to the associated resources and endpoints:

• R (read) - All endpoints using the GET method.
• C (create) - All endpoints using the POST  method.

For more information, see Guide to User Rights Management.

7.2 API gateway

Participants can connect to the AEMO API Gateway The gateway on AEMO’s side providing participant communication options, accessible over the internet or MarketNet. It uses resources and methods to push messages to Participants’ API Gateways . through MarketNet AEMO's private VPN for Registered Participants. A network of more than 300 registered participants in the National Electricity Market, including market generators, transmission network service providers, distribution network service providers, and market customers..

All communications between AEMO Australian Energy Market Operator’s API gateway and participants’ gateways use HTTPS Hypertext Transfer Protocol Secure, adds the security capabilities of SSL to standard HTTP communications.. AEMO APIs do not support HTTP.

7.3 Authentication

The API uses OAuth 2.0 with the client credentials grant type. A bearer token is returned and used to authenticate API requests. See securitySchemes in the Power Quality Data API reference.

7.4 Base urls

7.5 Compression

All BPQD payloads must be submitted as a gzip binary file. See 7.12.1 GZIP payload

7.6 Endpoints

For details, see the Power Quality Data API Reference.

7.7 HTTP response codes

For details, see the Power Quality Data API Reference.

7.8 Pagination

Cursor-based pagination is supported for GET API requests. For help, see Cursor Pagination.

7.9 Payload limit

The payload limit is 10 MB uncompressed.

7.10 PQD payload format

The PQD payload format is JSON JavaScript Object Notification. For schema details, see PQD schema.

A BPQD payload contains data at the 5-minute trading resolution.

7.11 Rate limiting

Each Participant ID Registered participant identifier; A company can have more than one Participant ID. is limited to 50 requests per minute per endpoint.

Exceeding the limit results in a 429 Too Many Requests response, and further requests are rejected.

7.12 Submission requirements

MCs and MDPs must:

• Send BPQD JSON payloads as a GZIP binary file.
• Provide a digital signature for each BPQD submission.
• Implement BPQD bundling and JSON minification as part of their BPQD submission workflow.

7.12.1 GZIP payload

A PQD payload must be sent as a GZIP‑compressed binary file, not as plain‑text JSON. The binary output is submitted as the HTTP request body, specifying gzip in the Content-Encoding http header as shown in the example below.

curl -X POST https://apis.nem.preprod.marketnet.net.au/pqd/v1/bpqd \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Encoding: gzip" \
  -H "Content-Type: application/json" \
  -H "x-initiatingParticipantId: SOLAR" \
  -H "x-signature: RSA-SHA256;<digital_signature>" \
  --data-binary @pqd-bpqd~solar~2026042211000b.gz

7.12.2 Message signing

All Basic Power Quality Data (BPQD) payloads submitted to the Industry Data Exchange See Relevant Rules or Procedures (IDX Industry Data Exchange) must be digitally signed by the initiating Participant.

The digital signature must be included in the x‑signature HTTP header of each submission request. IDX validates the signature before accepting the payload for processing.

Message signing supports non‑repudiation and applies to all IDX Business As defined in the NERL. Functions. For signing requirements, certificate usage, and certificate rollover behaviour, see Digital signature.

7.12.3 BPQD bundling

BPQD submissions use the IDX Fire and Forget API Channel designed for high-volume batch submissions. Participants must minimise message counts by automatically aggregating BPQD readings into payloads that utilise the 10 MB uncompressed limit.

Payloads must be sized as close as possible to the 10 MB uncompressed limit. Participant systems must not send individual messages per NMI See Relevant Rules or Procedures, except in unavoidable circumstances.

7.12.4 JSON minification

JSON minification must be applied to all outbound BPQD payloads. Minification involves removing unnecessary whitespaces, line breaks, and comments from JSON data prior to submission. Payloads must be minified to maximise the number of records per submission and minimise network utilisation.

Automated JSON minification should be integrated into the BPQD outbound process.

7.13 Submission size

A submission request has a payload limit of 10 MB uncompressed. For more details, see Submission requirements.

7.14 Validation

Validation A process to test the veracity and integrity of metering data. is applied only to HTTP headers, query, and path parameters in the request.

The BPQD payload schema and content is not validated.