5 APIs

The Industry Data Exchange See Relevant Rules or Procedures (IDX) Hub includes APIs to manage and support the message exchange lifecycle. This includes flow control, transaction visibility, business function and resource metadata, and message management. They are applicable across B2B Business-to-Business. Generic term used to refer to defined business-to-business interactions between participants; excludes interactions between a participant and market systems such as MSATS. and B2M Business-to-Market business functions and resources.

A business function API Application Programming Interface; a set of clearly defined methods of communication between various software components., for example the Power Quality Data (PQD) API, performs the data exchange for a Business As defined in the NERL. Function and Business Function Resources. It represents a transaction group with its own schema, versioning, and endpoints. For information about the PQD API, see Industry Data Exchange - Basic Power Quality Data - June 2026.

5.1 OAuth 2.0 authentication

Industry Data Exchange (IDX) APIs use OAuth 2.0 tokens to authenticate and authorise participant systems. An OAuth 2.0 access token is required for all IDX APIs and represents:

• A registered OAuth client
• A specific URM account
• The Participant ID(s) and permissions assigned to the URM account

All IDX APIs are OAuth 2.0 enabled and are accessed through 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 . on 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..

5.1.1 OAuth API

See the OAuth OpenAPI specification.

5.1.2 OAuth client

To access the IDX APIs, participants must create a Participant user account in User Rights Management (URM User Rights Management; see the Guide to URM on AEMO's website) and assign the required IDX entities. The URM account represents the OAuth client.

The URM account credentials (username and password) are used to authenticate when requesting an OAuth 2.0 access token from the OAuth 2.0 token endpoint. Specifically:

• The username is used as the client_id.
• The password is used as the client_secret.
• Tokens are obtained using the OAuth 2.0 client_credentials grant type.
• Authorisation is enforced using OAuth scopes.

OAuth scopes

An OAuth scope defines what a participant is allowed to access when calling IDX APIs. Each scope represents a URM entity, a Participant ID Registered participant identifier; A company can have more than one Participant ID., and a set of permitted actions: Create, Read, Update, and Delete (CRUD Create, read, update, and delete access rights.). Scopes determine which APIs and HTTP methods an OAuth access token can be used with.

For a scope to be valid, the referenced entity must be allocated to the user in URM, and the user must be granted the appropriate Rights for that entity. If an entity is not allocated to the user, it cannot be included as part of an OAuth scope.

When requesting an access token, participants can optionally include the scope parameter. If provided, the token is limited to the specified scopes only, resulting in a smaller, more efficient token and reduced security risk. If no scope is provided, the token will include no scopes.

AEMO Australian Energy Market Operator recommends to only request scoped tokens and include only the scopes required.  

Multiple participant IDs

For a URM account associated with multiple Participant IDs, all matching scopes across all Participant IDs are returned. You cannot request a token for one Participant ID.

Example scopes

Scenario	Example	Result
No scope provided	A participant has PQD_BPQD and FCTRL_FCTRL No scope is provided when calling the OAuth token endpoint	Returns a token containing no scopes
Specific scopes provided	scope: PQD_BPQD FCTRL_FCTRL across two Participant IDs	Returns a token with matching scopes for all Participant IDs Scope: PQD_BPQD|ParticipantID1|RUCD FCTRL_FCTRL|ParticipantID1|RUCD PQD_BPQD|ParticipantID2|RUCD FCTRL_FCTRL|ParticipantID2|RUCD
Permission enforcement	scope: PQD_BPQD The Participant User has the PQD_BPQD entity assigned with read only permission	Returns a token with PQD_BPQD scope with read only permission. BPQD API POST requests are rejected. GET requests are allowed Scope: PQD_BPQD|ParticipantID|R

5.1.3 Obtain an OAuth token

Obtain an OAuth 2.0 access token by calling the OAuth token endpoint POST /oauth/v1/token and providing the following details in the request.

Type	Property	Description
Request header	Content-Type: application/x-www-form-urlencoded	Specifies the request body content encoding
Body parameter	client_id	URM username
Body parameter	client_secret	URM password
Body parameter	grant_type	Must be client_credentials
Body parameter	scope	Optional. A  space‑separated list of scopes. For help, see OAuth scopes

Example request:

A successful request returns a token with a 1-hour expiry and resolved scopes.

Example 200 response:

You include the token in the Authorization header for an API request.

Authorization: Bearer <access_token>

5.2 Event Notification API

The Event Notification A transaction that does not have a corresponding reply transaction, see Notification Business Transaction Pattern. API is a WebSocket event‑driven API providing a persistent, bi‑directional connection between AEMO’s Industry Data Exchange (IDX) platform and participant systems.

The API enables near real‑time delivery of notifications to participants when:

• A message becomes available for retrieval.
• Flow‑control conditions change.

Participants must subscribe to the relevant business function events before establishing a WebSocket connection to IDX. Once a connection is established, AEMO pushes notifications to participants over the WebSocket connection.

Each event includes metadata such as event type, priority, and message context, allowing participants to determine follow-up actions.

5.2.1 API gateway

Participants can connect Energy Rules Terms to the AEMO API Gateway Part of AEMO's API -e-Hub used by participants and AEMO to push or pull messages using RESTful APIs. Some APIs are accessible over the internet and MarketNet. through MarketNet.

All communications between AEMO’s API gateway and participants’ gateways use HTTPS Hypertext Transfer Protocol Secure, adds the security capabilities of SSL to standard HTTP communications. for REST The Representational State Transfer API architecture APIs and WSS for WebSocket connections. AEMO APIs do not support HTTP.

5.2.2 Authentication

The API uses OAuth 2.0 tokens with the client credentials grant type. A bearer token must be supplied for the initial WebSocket connection.

Authorization: Bearer <token>

See OAuth 2.0 authentication.

5.2.3 AsyncAPI specification

To view and download the specification, see the Event Notification AsyncAPI specification.

5.2.4 Connection lifecycle

The Event Notification API implements a RFC 6455 standard WebSocket keep-alive mechanism using Ping and Pong control frames. IDX sends periodic ping frames, and participants must respond with pong frames to keep the connection active. If no ping pong activity occurs for 3 hours, IDX closes the connection.

A WebSocket connection is maintained for up to 24 hours. After this period, participants must obtain a new OAuth 2.0 access token and establish a new WebSocket connection.

5.2.5 Initiate a WebSocket connection

A WebSocket client initiates a WebSocket connection to the Event Notification API using the wss endpoint, providing the OAuth token in the Authorization request header during the WebSocket handshake and specifying the idxevents.v1 subprotocol.

5.2.6 Endpoints

Environment	Protocol	Host	Path
Pre‑production	wss	apis.nem.ppd.marketnet.net.au	/events
Production	wss	apis.nem.marketnet.net.au	/events

5.2.7 Error codes

Refer to the Events Notification AsyncAPI specification.

5.2.8 Event subscription

Participants must subscribe to the required event types to receive WebSocket event notifications. Business function events and flow control events are managed as separate subscriptions and must be requested independently.

To subscribe, submit an AEMO Support Hub request specifying the event type to be enabled (for example, Power Quality Data business function events or flow control events), along with your Participant ID and URM account username. AEMO will confirm subscription to receive event notifications.

5.2.9 Prerequisites

To access the API, you must have:

• A registered URM account. 
• The Event Notification API entity and relevant business function entities assigned by your Participant Administrator.
• A valid OAuth 2.0 access token using the client credentials grant.
• Subscribe to relevant business function or flow control events. See Event subscription.

5.2.10 Rate limiting

The Event Notification API applies rate limiting to connections and message flow to protect system stability.

The API has a limit of 5 connections per Participant ID. If the limit is exceeded, an event message is sent with Connection Requests Exceeded - You have exceeded the number of connections allowed for WebSockets. Please end other sessions before making new connections.

5.2.11 Response codes

Refer to the Events Notification AsyncAPI specification.

5.2.12 Retry mechanism

The Event Notification API supports a retry mechanism for message event notifications delivered by WebSockets so participants can receive notifications if delivery is not successfully completed. The retry mechanism does not apply to Flow Control event notifications.

A message event notification is sent to a Participant. If an acknowledgement is not received within 5 minutes, the event notification is updated to an event retry status.

An acknowledgement is a protocol‑level event acknowledgement as defined in the Event Notification AsyncAPI specification.

IDX maintains a list of pending events requiring delivery. The retry scheduler resends eligible events in the event retry status every 5 minutes. After 3 failed delivery retries, the event status is set to expired.

Expired events are not retried further. Participants are expected to reconcile missed message availability events via the relevant Business Function API.

5.2.13 User rights access

Your Participant Administrator Creates and maintains access to AEMO systems for their Participant ID users. provides access to the API using the entity EVENT_NOTIFY. For more information, see Guide to User Rights Management.

5.3 REST APIs

Details	Flow Control API	Business Function Information API	Transaction Log API	Archive API
About	Monitors and controls message delivery across B2B business functions on IDX. It provides: Visibility into the flow control status for subscribed business functions Control to stop or resume outbound delivery of a business function to your queue (once per day) Insight of other Participants’ flow‑control status	Gets business function and business function resource metadata	Gets message and transaction logs associated with your Participant ID	Gets an archived message or a list of archived messages in your outbound archive
API gateway	Participants can connect to the AEMO API Gateway through MarketNet. All communications between AEMO’s API Gateway and participants’ gateways use HTTPS. AEMO APIs do not support HTTP.
Authentication	OAuth 2.0 with the client credentials grant type. A bearer token is returned and used to authenticate API requests. See OAuth 2.0 authentication
Base URLs	MarketNet production: https://apis.nem.marketnet.net.au/flowcontrol/v1 MarketNet pre-production: https://apis.nem.ppd.marketnet.net.au/flowcontrol/v1	MarketNet production: https://apis.nem.marketnet.net.au/businessfunctioninfo/v1 MarketNet pre-production: https://apis.nem.ppd.marketnet.net.au/ businessfunctioninfo /v1	MarketNet production: https://apis.nem.marketnet.net.au/translog/v1 MarketNet pre-production: https://apis.nem.ppd.marketnet.net.au/translog/v1	MarketNet production: https://apis.nem.marketnet.net.au/archive/v1 MarketNet pre-production: https://apis.nem.ppd.marketnet.net.au/archive/v1
Compression	For details, see the Industry Data Exchange Platform Standard
Endpoints	GET /businessFunctions:  Get a list of Business Function with Flow Control breaches for your Participant ID GET /businessFunctions/{businessFunctionId}:  Get flow control information for a Business Function for your Participant ID PATCH /businessFunctions/{businessFunctionId}: Enable or disable the outbound message flow to your queue for a Business Function GET /participants: get a list of participants with stopped message queues GET /participants/{participantID}: get Flow Control details of a Participant with stopped message queue	GET /businessfunctions: Get a list of Business Functions GET /businessfunctions/{businessFunctionId}: Get Business Function details GET /businessfunctions/{businessFunctionId}/resources: Get a list of Resources in a Business Function GET /businessfunctions/{businessFunctionId}/resources/{businessFunctionResourceId}: Get Business Function Resource details	GET /messages: Get a list of message logs for messages where your Participant ID was the initiating or receiving Participant GET / message/{messageContextId}: Get transactions for a message	GET /retrieve: Get metadata for archived outbound messages GET /retrieve/{messageContextId} : Get an archived outbound message from a specified business function. It also includes a digital signature for non-repudiation
HTTP response codes	See the draft OpenAPI specifications
OpenAPI specification	Flow Control OpenAPI Specification	Business Function Information OpenAPI Specification	Transaction Log OpenAPI Specification	Archive OpenAPI Specification
Pagination	Cursor-based pagination is supported for GET requests
Payload format	JSON	n/a	n/a	n/a
Payload limit	10 MB compressed	n/a	n/a	n/a
Prerequisites	To connect to the IDX Hub, participants need: A Participant ID. If your company is a Registered Participant, it is set up during the registration process. A user ID and password with user access rights provided by your company's Participant Administrator. Access to MarketNet. For details about MarketNet, see Guide to Information Systems. Primary and secondary AEMO-signed TLS certificates for MTLS authentication. For help, see TLS Certificate Management. An AEMO certificate authority trusted by your systems. Your IP address range allow listed by AEMO. The appropriate IDX URM entities assigned to the Participant User. See User Rights Management.
Rate limiting	PATCH /businessFunctions/{businessFunctionId}: 2 requests per businessFunctionId per Participant per day. All other endpoints: 288 requests per participant per day. Excess requests return HTTP 429.	TBC	TBC	TBC
User rights access	URM entities: FCTRL_FCTRL — access to your Business Function Flow Control endpoints FCTRL_STATUS — read access to other Participant status	Not applicable. Only a valid OAuth2 token is required	URM entity: TRANSLOG_TRANSLOG	URM entity:  ARCH_RETRIEVE
Validation	Validation is only applied to HTTP headers, query, and path parameters in the request