MISO Market User Interface (MUI 2.0)

MISO Market User Interface

(MUI 2.0)

API User Guide

January 18, 2024

Revision 1.22

MISO MUI 2.0 API User Guide

Table of Contents

About This Document......................................................................................................................................... 3

Purpose of This Document ...................................................................................................................................................................... 3

Scope of This Document .......................................................................................................................................................................... 3

Related Documents ................................................................................................................................................................................... 4

1. Introduction ...................................................................................................................................................... 4

User Authentication ..................................................................................................................................4

Technology Prerequisite Knowledge ........................................................................................................................................... 5

Test Tools ....................................................................................................................................................5

External Interface Data Exchange Overview ........................................................................................................................... 5

Data Exchange Synopsis ................................................................................................................................................................... 6

OpenAPI / Swagger Editor ............................................................................................................................................................... 7

2. Introduction to the API .................................................................................................................................. 8

Messaging Overview.......................................................................................................................................................................... 8

The Role of the End User ........................................................................................................................8

The Role of MISO ....................................................................................................................................8

The Role of the MP..................................................................................................................................9

Required Capabilities ........................................................................................................................................................................ 9

Authentication ..................................................................................................................................................................................... 9

HTTP/HTTPS and TLS ....................................................................................................................................................................... 9

Security Best Practices .................................................................................................................................................................. 10

Session Management ............................................................................................................................10

Check for MISO Public Key ..................................................................................................................10

IP Whitelisting Notifications Connections .........................................................................................10

Rate Limits .......................................................................................................................................................................................... 11

Historical Data Availability ........................................................................................................................................................... 11

Using JSON ......................................................................................................................................................................................... 11

Notifications....................................................................................................................................................................................... 12

Notifications – Registering URL and Sending Test Messages ..........................................................13

3. Common Principles ...................................................................................................................................... 13

Participant Registration ................................................................................................................................................................ 13

OpenAPI Specification Schema................................................................................................................................................... 14

HTTP Methods .................................................................................................................................................................................. 15

MISO MUI 2.0 API User Guide

HTTP Headers ................................................................................................................................................................................... 15

Delete Behavior ................................................................................................................................................................................ 16

Pnode Based GET Endpoint Behavior ...................................................................................................................................... 16

POST Endpoints Supporting Multiple Locations or Pnodes ............................................................................................. 18

Retrieving Bulk Real-Time Prices ............................................................................................................................................... 19

Confirming Financial Schedules and Contracts .................................................................................................................... 19

Optional JSON Elements ............................................................................................................................................................ 20

API and Error Responses ............................................................................................................................................................ 20

HTTP Status Codes .............................................................................................................................21

Transaction Semantics and Transaction Identifier .........................................................................22

Transaction Log ..................................................................................................................................22

JSON Data Type and Specification Semantics .................................................................................................................... 22

JSON Date and Time in the MUI interface. ......................................................................................22

MP Representing Asset Owners .............................................................................................................................................. 23

MP Query/Submit on Behalf of Asset Owners ................................................................................24

Notification Dispatch Messages sent to MP ....................................................................................24

4. Testing in the Customer Connectivity Environment (CCE).............................................................. 24

CCE URL .............................................................................................................................................................................................. 24

Historical Data in CCE .................................................................................................................................................................... 24

Rate Limits in CCE ............................................................................................................................................................................ 25

Notification Testing in CCE .......................................................................................................................................................... 25

5. Terms and Acronyms ................................................................................................................................... 26

Recent Change Summary ..................................................................................................................................................................... 29

MISO MUI 2.0 API User Guide

About This Document

This document introduces software engineers to the Application Programable Interfaces (APIs) of the MISO Market

User Interface 2.0 (MUI) component of the MISO Day-Ahead and Real-Time Energy and Operating Reserves market.

Purpose of This Document

This document is intended to introduce readers to the API design and implementation strategy for the MISO MUI

2.0 being built as part of the MISO Market System Upgrade project.

Readers of this document should be familiar with the general context of APIs, RESTful webservices and JSON.

Scope of This Document

The document will not cover implementation details for individual APIs. This information is provided by way of an

OpenAPI 3 specification which can be viewed using Swagger tooling.

MISO MUI 2.0 API User Guide

Related Documents

Document Name

Description

MUI 2.0 API Specification.yaml

For detailed descriptions and technical definition of the

individual APIs and payloads

LSA Policy Guide

Information related to the Local Security Administrator role

Self-Service LSA User Guide Information related to provisioning and managing users that

access the MUI

Market Participant Registration

Website for more information on Market Participant

registration

1. Introduction

Market participants (MP) interact with the MISO Energy and Operating Reserves market through a variety of

software systems hosted by MISO. These include asset registration and equipment modeling, SCADA over ICCP for

telemetry and controls, settlements and invoicing among others.

The Market User Interface (MUI) provides participants an interface to interact with the MISO Energy and Operating

Reserves market. The MUI provides this interface using standard internet technologies. At a high level, the MUI

provides the following capabilities:

• The ability to submit any parameters that can change daily or hourly as part of market participation, such as

resource limits, runtimes, ramp rates and other physical parameters, generation offers, demand bids, virtual

bids, virtual offers and others depending on the system operator

• The ability to query out what has been submitted

• The ability to query results of the day-ahead and real-time markets as they clear

• The ability to do all the above as an authenticated user over the public internet through either a

programmatic web API or a web-based user interface

• The ability to receive web API push messages from certain events in the market, such as operational

messages to the participants, clearing results, resource start and stop commands, and dispatch instructions.

User Authentication

User Authentication is accomplished by a user Digital Certification managed by a Local Security Administrator

within each Market Participant Company. See Self-Service LSA User Guide

for details on user management.

Should be reviewed using Swagger Editor

MISO MUI 2.0 API User Guide

Technology Prerequisite Knowledge

In order to design and implement a JSON-based data exchange with the MUI using the programmatic APIs, the

reader should be familiar with:

• Using JSON for data description, JSON parsing and validation

• RESTful Web Services

• OpenAPI Specification and Swagger Editor

• Protocols HTTP, HTTPS and TCP/IP

• Security and authentication technologies: encryption, authorization, and secure sockets layer/transport

level security (SSL/TLS).

• General network communication software methodology.

Test Tools

These API test tools can help developers quickly interact with the MUI API. While MISO finds these tools useful,

they are not neither endorsed nor supported by MISO. There are other equivalent tools available.

• Talend API Tester: a simple browser plugin for REST/JSON interactions

• Postman and SoupUI: Feature-rich desktop applications for REST/JSON interactions

• Swagger Editor: for reviewing the OpenAPI specification document

External Interface Data Exchange Overview

The participants of the Day-Ahead and Real-time market that exchange data with MISO include:

• Companies that provide energy supply in the form of generation

• Companies that provide energy supply in the form of demand response resources

• Companies that require energy demand to service loads

• Local Balancing Authorities that monitor and manage load and generation in a geographic region

• Other interested registered participants

Individual generating companies or load serving entities are represented by MPs who act as agents to submit energy

supply offers or demand bids. Other participants may be registered and query or submit data as well (e.g.

distribution companies, virtual energy traders).

MISO MUI 2.0 API User Guide

Data Exchange Synopsis

Data exchange is described in terms of data submitted by the participant and data received as a result of a query in

different functional categories as shown in the table below. For detailed descriptions and technical definition of the

individual APIs and payloads supported review the MUI 2.0 API Specification.yaml

OpenAPI specification.

Category Description

Day-Ahead Market (DA)

Day-Ahead Energy and Operating Reserve Market: The forward

market for purchases and sales of Energy, Operating Reserve, Up

Ramp Capability, Down Ramp Capability, and Short-Term Reserve

conducted by the Transmission Provider the Day prior to the

Operating Day

The Day-Ahead Market includes Resource Offers, Financial/Physical

Bilateral Transactions, Price Sensitive Demand Bids, Fixed Demand

Bids and Virtual Bids/Supply Offers.

Real-Time Market (RT) Real-Time Energy and Operating Reserve Market: The Market for

purchases and sales of Energy, Operating Reserve, Up Ramp

Capability, Down Ramp Capability, and Short-Term Reserve

conducted by the Transmission Provider during the Operating Day.

The Real-Time Market information includes Resource Offers,

Financial/Physical Bilateral Transactions and Self Schedules.

Financial Schedules

This data exchange set allows for the definition of bilateral financial

schedule contracts and daily hourly schedules of energy and ancillary

services.

The financial schedules center is open to receive Day-Ahead contract

definitions and schedules up to noon the day before the operating

day and noon the day after for real-time adjustments to the Day-

Ahead schedules.

Operations and Local

Balancing Authority

Data set that is submitted by local balancing authorities or required

by market operations. Includes emergency notifications, energy

supply resource start/stop and dispatch instructions.

Portfolio Management

Portfolios are participant named and specified collections of energy

supply resource locations, and demand bid locations that can be used

by the interactive web browser user and the XML query processor.

Portfolios are used to group resources and location nodes together

for the benefit of the participant in viewing and managing data.

Independent Market

Monitor

Data set that is submitted by the Independent Market Monitor

(IMM). Includes reference prices and cost schedules that are bundled

as resource assignments.

Should be viewed using the Swagger Editor

MISO MUI 2.0 API User Guide

OpenAPI / Swagger Editor

The Swagger Editor is a tool to easily visualize any Open API specification. The figure below is an example

screenshot that shows the OpenAPI specification MUI 2.0 API Specification.yaml in the Swagger Editor software. On

the left is the raw file, on the right in is an interpreted version of the specification showing the different API

endpoints supported.

MISO MUI 2.0 API User Guide

2. Introduction to the API

The MUI supports REST-based (RESTful) programmatic APIs using the JSON data-exchange format. These

programmatic APIs are used by market participants to exchange data with MISO via the MUI. In function, the

programmatic API mimics the interactive web user interface; almost all functions supported by the web pages are

supported by the programmatic API.

To use these APIs the participant software must implement the messaging protocol according to the guidelines

described in this document and its associated OpenAPI Specification. This software implementation relies heavily on

standard technologies that can be obtained freely on the internet (i.e. open software) or that can be obtained from

third-party vendors.

Messaging Overview

The programmatic API is a messaging API used by MISO to exchange data with the MPs. In this communication there

are roles for the participant, MISO, and MP.

The Role of the End User

This role description presumes a generic end user. It does not address the requirements or rules stipulated for an MP

acting as an agent for other MPs.

The end user uses the programmatic API to implement an automated interface to the market services provided by

MISO. Using the programmatic API, the end user can implement software that integrates efficiently with other

applications and processes on the end user side of the network. This allows the necessary message exchange to fit

more easily into the end user’s business processes and methods.

The end user uses the programmatic API to query MISO for market results and other public data.

The Role of MISO

MISO provides services that support the programmatic API. These services are identified by Universal Resource

Locators (URL) and made available to the end user. When the MISO server receives a request at a given URL, the

following processing is performed:

• The request is validated both syntactically and semantically. Any error results in an error response.

• If the request is a data submission. then the change is verified to conform to market business rules. Any

violations result in an error response and the total rejection of all data in the message. If there are no errors,

then the data is accepted.

• If the request is a data query and the request is correctly formatted, then the data requested is packaged as

a JSON objects and returned to the participant.

MISO sends (pushes using asynchronous messaging) notification and dispatch messages to MPs who are registered

to receive such messages. The MP must implement and make a message listener available to receive such messages.

MISO MUI 2.0 API User Guide

The Role of the MP

An MP is a market participant that is qualified to represent a transmission customer or energy supplier (asset owner

(AO)) for purposes of scheduling and/or settlement with MISO. MISO will only settle with such an MP that is

registered with MISO (See MISO Market Participant Registration

website for more information on MP registration).

An MP can represent multiple asset owners.

An MP uses the programmatic API to:

• Submit market bids and offers on behalf of the AO into the day-ahead and real-time markets

• Query MISO for market results and other public and private data

• Receive notification and dispatch messages with a registered message listener

It is the responsibility of the MP’s Local Security Administrator (LSA) to provision access for end users in order to use

programmatic API to implement an automated interface to the market services provided by MISO. See the

LSA

Policy Guide for more information related to the LSA role and the Self-Service LSA User Guide for more information

related to provisioning end users.

Required Capabilities

A REST API client should support the following:

• HTTPS and the configuration of a client certificate

• Operations for standard methods (GET/POST/PUT/DELETE)

• Ability to set and read request and response headers

• Ability to generate and process JSON data

Authentication

The MUI API uses X.509 digital certificates to provide authentication, which maps a session to a client identity and

company registered with MISO. Discussion of this user management process is outside the scope of this document.

See the Self-Service Local Security User Guide

for more information on the user management process.

HTTP/HTTPS and TLS

Connecting to the MUI API requires using HTTPS

and Transport Layer Security (TLS). The REST API & Notifications

supports HTTP 1.1 and TLS protocol version 1.2. Once TLS 1.3 becomes the norm, MISO will move to TLS 1.3.

All message exchange between the participant and the MISO server uses HTTPS protocol, which is HTTP over an SSL/TLS (encrypted) session.

The name HTTP names the protocol commands, the suffix of S refers to the secure connection. When discussing the protocol, the name HTTP will

be used.

MISO MUI 2.0 API User Guide

Security Best Practices

Session Management

For security reasons, MISO requires establishing a session with a small transaction. MISO recommends sending a

GET operations with an invalid parameter.

For example:

https://markets.midwestiso.org/dart2/markets/X

Or if working in the CCE environment:

https://cce.midwestiso.org/dart2/markets/X

This will establish the session, while failing quickly and using the least amount of resources. Even though the invalid

GET operation will return an error response, the session is still established and an MRHSession cookie is returned.

The MRHSession cookie is a set of hex digits and you can find in the http header as below:

Set-Cookie: MRHSession=HexDigits;path=/;secure

The MRHSession cookie should be included on subsequent API transactions. Without the MRHSession cookie some

API transaction calls will be rejected with a failure for security reasons.

Be prepared to reestablish your session. When you get a session error message, reestablish the session using the

same GET operation as above, and retry the transaction. There can be several reasons for a session to drop. For

example, idle sessions are eventually dropped. Do NOT reestablish the session for each API call.

Check for MISO Public Key

Best practice is to validate your connection against the MISO service certificate. This allows a client connecting to

the MUI to validate that they are actually connected to MISO. MISO MUI exposes this public key for clients and is

available here

. This server certificate is valid for all member accessible production and test environments.

IP Whitelisting Notifications Connections

In addition to the MUI for submitting data and retrieving results, MISO also pushes notifications to market

participant listeners that have one or more registered listener URLs (see section Notifications). To ensure that the

notifications received are indeed from MISO, market participants should allow only MISO servers to reach their

notification listeners through network configuration. This is often referred to as IP white listing.

For Production, MISO will send Notifications from the either of the following IP addresses.

• 148.142.64.100

• 148.142.74.105

For Customer Connectivity Environment (CCE), MISO will send Notifications from the following IP Address.

• 148.142.64.15

In addition, you can validate against the MISO server certificate (see section Check for MISO Public Key).

MISO MUI 2.0 API User Guide

Rate Limits

The MUI API imposes rate limits on API usage. In the case where a rate limit is exceeded, the API will respond with

an error message and the HTTP status code: 429 Too Many Requests. Invalid requests will be counted towards this

limit. Client applications can reattempt any rejected request and should implement self-throttling to the published

limits.

The rate limit default is 100ms and applies to only GET requests for a given endpoint. Endpoints with a different rate

limit than the default are list below. These can be adjusted without notice to address excessive traffic affecting

system availability. See External Systems Acceptable Use Policy

for more information.

The rate limit is enforced for a given user (defined by the client certificate) and the acting asset owner (see section

MP Representing Asset Owners). In other words, if a give client certificate is querying for two different asset

owners, the two queries do not count against each other.

Group Endpoint Rate Limit (ms)

Forecast

/markets/real-time/{day}/forecast/dir/participants/{participantName}

60,000

Forecast

/markets/real-time/{day}/forecast/rt-demand/participants/{participantName}

60,000

Forecast

/markets/real-time/{day}/forecast/5-minute/participants/{participantName}

60,000

Notifications

/markets/notifications/{day}/resource-start-stop/participants/{participantName}/messages

300,000

Offers

/markets/real-time/{day}/offer/ramp-curves/participants/{participantName}

1,000

Offers

/markets/real-time/{day}/offer/overrides/participants/{participantName}

60,000

Offers

/markets/day-ahead/{day}/offer/auto-overrides/participants/{participantName}

60,000

Reports

/markets/day-ahead/{day}/reports/lmp-exante

60,000

Reports

/markets/day-ahead/{day}/reports/lmp-expost

60,000

Reports

/markets/day-ahead/{day}/reports/locational-results/participants/{participantName}

10,000

Reports

/markets/real-time/{day}/reports/hourly-lmp-expost

10,000

Reports

/markets/real-time/{day}/reports/lmp-exante

1,000

Reports

/markets/real-time/{day}/reports/lmp-expost

1,000

Default

100

Historical Data Availability

In addition to the current operating day, MISO retains 10 days of past market results data. The MISO website

contains additional historical public market results data.

Using JSON

The MUI uses standardized JSON messages for both requests and responses. The format of these messages is

described in the OpenAPI Specification. In addition to standard HTTP status codes, a common API Response JSON

message is returned for errors or on successful submission of a request to update a resource (see section API and

Error Responses).

MISO MUI 2.0 API User Guide

Notifications

The MUI supports push notifications with asynchronous messaging. The client is MISO, which issues a notification or

a dispatch instruction message that is sent to the participant’s server. To receive push-style messages, the

participant must have a message listener active at all times. This is because these messages are asynchronous with

participant activity. The participant does not request these messages (no polling is performed).

For all push messages, MISO is always the client and the participant is always the server. MISO will log the HTTP

status code returned from the server but will not log the response payload (if it was sent by the server). A response

should take place immediately.

To protect against inefficient or non-functioning servers, MISO will quickly close the connection after the HTTP

response from the server is received.

Figure 5 illustrates the push (asynchronous) protocol.

Figure 5: Push (asynchronous) protocol

The client is MISO and the server is the participant. The processing steps are:

Step 1 – MISO’s software formulates the message (notification or dispatch instruction) and sends it to the

server (participant). After sending the message, MISO client software waits for the response (step 2).

Because MISO initiates the message sending without any request message from the participant, this is

called push or asynchronous messaging.

Step 2 – The server (participant) software is actively listening for new messages and receives the message

sent by MISO. The server software validates the message request and gives an immediate response with an

HTTP status 200 before processing the message action. A successful response is indicated by returned

HTTP status 200 OK, while any another HTTP status is treated as unsuccessful. The response body is not

relevant and will not be stored.

Regardless of HTTP status response, MISO will never attempt to resend a notification.

MISO MUI 2.0 API User Guide

Step 3 & 4 – MISO’s software receives the response message and logs the HTTP status code. The response

body is not stored. If the response is not sent before the connection is close, HTTP status 408 Request

Timeout is recorded.

MISO sends messages by sending an HTTP POST message to the registered participant server computer. The

participant’s server is implemented like a standard web server that can receive and acknowledge the sent messages.

The participant’s web server is identified by a URL that is registered with MISO and must support HTTPS (or SSL)

requests. Although at this time MISO allows self-signed certificates, MISO recommends using well established third

party signed certificates. At some time, MISO will require third-party issued certificates.

Notifications – Registering URL and Sending Test Messages

The registration of the participants URL and subsequent subscriptions to different message types is supported by

the MUI user interface. Participants are expected to self-service the registration and subscriptions.

The MUI user interface also allows participants to send test messages to subscribed URLs. Messages sent via the

notification test screen will have the test element of the message set to true, “test”: true.

Recommended Best Practice: Your production Listener should check that the test element is not true. This

would prevent test messages from accidentally being processed by your production system. In addition, IP

Whitelisting would provide an additional layer of protection (see section IP Whitelisting Notifications

Connections).

To register a URL and send a test notification, the MUI user must have their Local Security Administrator grant their

certificate “DART: Notification URLs (submit)” access in CCE or Production. With this access, you can update the

target URL for notifications and send a test notification from either CCE or Production.

Since the push messaging exchange is all performed using SSL/TLS and authenticated using digital certificates, the

participant must be able to support the following related activities:

• Establish a web listener identified by a server style digital certificate whose root authority is a well

established third party signed certificates. MISO does not allow self-signed listener certificates.

• Recognize the digital certificate used by MISO to authenticate all notification and dispatch messages.

Additionally, it is recommended to check the MISO public certificate and whitelist the IP address of MISO clients

(see section Check for MISO Public Key).

3. Common Principles

This chapter describes common requirements and messaging concepts used by all message types.

Participant Registration

All market participants using the JSON programmatic interface must be registered with MISO. Each registered user

must have a digital certificate to specify:

MISO MUI 2.0 API User Guide

• A unique username that is defined within the digital certificate

• A participant identifier or company name defined at the time of registration

• Access permission based on the roles defined by the registration system

An MP who represents other participants must establish permission to operate as an agent for each participant via

the registration system. Only after such a relationship has been defined and entered into the registration system will

the MP be able to submit data or query requests on behalf of another participant.

OpenAPI Specification Schema

The API’s specification is provided via an OpenAPI 3.0.3 specification schema. The schema describes API paths, path

and query variables, and request/response messages. MISO’s schema is located at the URL specified below.

https://cdn.misoenergy.org/MUI%202.0%20API%20Specification%20(3.1.2)623177.yaml

It is recommended to view the schema via the Swagger Editor or other software that can interpret the OpenAPI

specification.

All functions and data provided by the MISO server are addressed using a URL. This URL is made up of base URL,

resource name and query string where the base URL is the root location of resources.

<base-url><resource-name><query-string>

The API descriptions in the OpenAPI specification describe the resource and query elements along with associated

JSON payloads and responses. The base URL contains the protocol, host and base API path, which may vary based

on environment and thus is not covered in the specification.

Note the breakdown of this URL:

https://markets.midwestiso.org/dart2/markets/day-ahead/2020-08-15/reports/lmp-

exante?portfolio=”ALL ASSETS”

Base URL

CCE: https://cce.midwestiso.org/dart2

(customer facing test environment)

...or

Production: https://markets.midwestiso.org/dart2

(note: not in production at this time)

Resource-name

/markets/day-ahead/2020-08-15/reports/lmp-exante

Query-string

?portfolio="ALL ASSETS"

The field and naming requirements of the X.509 digital certificates and the registration process are defined outside of this document.

MISO MUI 2.0 API User Guide

HTTP Methods

All requests submitted to MISO Server use either the HTTP POST or HTTP GET methods. Most available resources

specify a collection such as the market results for a day or schedule offers for an Asset Owner. A collection that is

tied to a participant will reference that participant in its path.

/markets/day-ahead/{day}/offer/schedule/participants/BigPower

While general information will not include the participant reference.

/markets/day-ahead/{day}/reports/lmp-exante

All submissions that modify data use the POST method while queries use GET. Though PUT and DELETE are often

supported in RESTful API’s, they are not used in this system. To understand how to delete objects, see section Delete

Behavior.

When querying a collection resource, query string parameters are used to filter the data

GET /markets/day-ahead/{day}/offer/schedule/participants/BigPower?portfolio="ALL ASSETS"

If no filters are provided for a query then all data that is applicable for the API, for which the user is authorized will

be returned.

HTTP Headers

The following headers should be set, or are returned, as applicable when making HTTP requests to the MUI API:

• Accept:

Since only the application/json content type is supported this value is somewhat superfluous.

• content-type:

Required when making a POST. The only content type currently accepted or returned is application/json.

• http-x-request-id:

Response header contains a unique transaction identifier assigned by MUI. Identifier is a GUID represented

without hyphens.

Example: '34571c664e48ca0b1e30d7ffb9b3b287'

• http-x-request-time:

Response header contains a timestamp string of when the request was received by the MUI.

• x-acting-participant:

Header to override default acting participant of NERC ID. Will be validated against participant collection

resource when specified in path.

• User-Agent:

The user-agent header must not emulate a browser and should be explicitly overwritten. For example, using

a value of the NERC ID of the client.

• Cookie:

When using a browser-based API tool such as Chrome Talend, a “Cookie” header with a null/blank value is

MISO MUI 2.0 API User Guide

required on POST transactions to overwrite the XSRF session token value. If it is not included, the response will be a

403 Forbidden.

Delete Behavior

Delete is achieved via posting a payload with elements which are null. The HTTP DELETE request is not used.

Elements or higher-level objects that can be deleted are described as nullable in the specification. If a collection

resource is nullable then an empty JSON array ([]) will be treated as null for submission.

Deleting data occurs for certain types of data (i.e. Offer Overrides) not in the value of a name/value pair but at the

Object level if that Object is listed as nullable: true (i.e. unitLimitOverrides: null).

Pnode Based GET Endpoint Behavior

Generally, the API GET endpoints associate with Pnodes are divided into two types: public and private. Both public

and private GET endpoints support three options for setting the scope of a GET call (which Pnodes you are

requesting data for).

1. Provide the pnode parameter – return data for that Pnode

2. Provide the portfolio parameter – return data from the collection of Pnodes within the portfolio

3. Provide neither the pnode nor the portfolio paramenter – return data for all eligible pnodes

If the GET endpoint is public, then all pnodes in scope return data.

If the GET endpoint is private, then return data varies. Please refer to the API Specification for details on each

endpoint and the table below.

Path

Description

/markets/day-ahead/{day}/reports/lmp-exante Returns all public pnodes that are part

of the Day-Ahead market Ex-Ante

results for the operating day.

/markets/day-ahead/{day}/reports/lmp-expost Returns all public pnodes that are part

of the Day-Ahead market Ex-Post

results for the operating day.

/markets/day-ahead/{day}/reports/locational-

results/participants/{participantName}

Returns all participant resources as

well as any location with cleared

demand or virtual bids/offers by the

participant from the Day-Ahead

market Ex-Ante results for the

operating day.

/markets/real-time/{day}/reports/lmp-exante

Returns all public pnodes that are part

of the Real-Time market Ex-Ante

results for the operating day and

specific interval report.

/markets/real-time/{day}/reports/lmp-expost Returns all public pnodes that are part

of the Real-Time market Ex-Post

MISO MUI 2.0 API User Guide

results for the operating day and

specific interval report.

/markets/real-time/{day}/reports/hourly-lmp-expost

Returns all public pnodes that are part

of the Real-Time market Ex-Post

results during the operating day.

/markets/day-ahead/{day}/demand/participants/{participantName} Returns all valid demand bid locations

for the participant for which bids exist

on the operating day.

/markets/day-ahead/{day}/virtual/participants/{participantName}

Returns all valid virtual locations for

which participant bids/offers exist on

the operating day.

/markets/real-time/{day}/offer/ramp-

curves/participants/{participantName}

Returns all valid resources supporting

Real-Time market rate curves for the

participant on the operating day. EAR

and SER resources do not support

ramp rate curves.

/markets/common/{day}/offer/cc-

status/participants/{participantName}

Returns all valid Combined Cycle

Aggregate resources for participant

on the operating day.

/markets/{market}/{day}/offer/auto-

overrides/participants/{participantName}

Returns all valid regulation qualified

resources for participant which have

had their regulation offer overridden

on the operating day. Regulation

Offers are overridden under the

following circumstances.

1. The Participant’s combined

Regulation Capacity and Mileage

Offers exceed the allowable Total

Regulation Offer range (this can occur

if a Deployment Rate change occurs).

2. The Participant’s Resource is

awarded regulation capacity in the

Day Ahead Market, and Participant’s

Real-Time regulation offer differs

from its Day Ahead regulation offer

for the operating day.

/markets/{market}/{day}/offer/qualification-

status/participants/{participantName}

Returns all valid resources for

participant on the operating day.

/markets/{market}/{day}/offer/schedule/participants/{participantName} Returns all valid resources for

participant on the operating day.

/markets/{market}/{day}/offer/defaults/participants/{participantName}

Returns all valid resources for

participant on the operating day.

/markets/real-

time/{day}/offer/overrides/participants/{participantName}

Returns all valid resources for

participant on the operating day.

/markets/real-time/{day}/forecast/5-

minute/participants/{participantName}

Returns all valid Wind or Solar

resources for participant on the

operating day for which there is 5-

MISO MUI 2.0 API User Guide

minute forecast data created by the

Midwest ISO forecast tool.

/markets/real-time/{day}/forecast/rt-

demand/participants/{participantName}

Returns all valid Load Zones,

Intermittent and Dispatchable

Intermittent Resources (DIR) for

participant on the operating day for

which there is hourly forecast data.

/markets/real-time/{day}/forecast/dir/participants/{participantName} Returns all valid Dispatchable

Intermittent Resources (DIR) for

participant on the operating day for

which there is 5-minute generation

capability forecast.

/markets/real-time/{day}/forecast/drr-

load/participants/{participantName}

Returns all valid DRR Type-I and Type-

II resources for participant on the

operating day for which there is 5-

minute level contingency reserve

deployment forecast.

POST Endpoints Supporting Multiple Locations or Pnodes

In general, POST endpoints support submitting one location or pnode per POST. There are a several POST endpoints

which will support multiple locations or pnodes within one POST. These cover Demand Bids, Schedule Offers, and

Virtuals.

While supporting multiple locations in one POST, MISO limits the number of locations for security and performance

reasons.

The table below lists the POST endpoints that support multiple locations in one POST and the maximum number of

locations allowed. The locations within the POST must be the same type.

POST Endpoint supporting multiple locations or pnodes within one POST

Location Limit

/markets/day-ahead/{day}/demand/participants/{participantName} 200

/markets/day-ahead/{day}/virtual/participants/{participantName} 1000

/markets/{market}/{day}/offer/schedule/participants/{participantName} 200

/markets/real-time/{day}/offer/ramp-curves/participants/{participantName} 200

/markets/common/{day}/offer/cc-status/participants/{participantName}

200

/markets/{market}/{day}/offer/defaults/participants/{participantName} 200

/markets/real-time/{day}/offer/overrides/participants/{participantName} 200

/markets/common/{day}/offer/cc-status/participants/{participantName} 200

/markets/real-time/{day}/offer/ramp-curves/participants/{participantName} 200

/markets/{market}/{day}/offer/defaults/participants/{participantName} 200

MISO MUI 2.0 API User Guide

/markets/real-time/{day}/offer/overrides/participants/{participantName} 200

/markets/real-time/{day}/forecast/rt-demand/participants/{participantName}

200

/markets/real-time/{day}/forecast/dir/participants/{participantName} 200

/markets/real-time/{day}/forecast/drr-load/participants/{participantName}

200

/markets/real-time/{day}/forecast/rt-demand/participants/{participantName} 200

/markets/real-time/{day}/forecast/dir/participants/{participantName}

200

/markets/real-time/{day}/forecast/drr-load/participants/{participantName} 200

Retrieving Bulk Real-Time Prices

In order to support retrieving bulk real-time prices, the “interval5” query parameter can contain a list of intervals.

• interval5 can be a single value or a list of values

• When multiple intervals are requested, they still must fall on the {day} referenced in the URL, be in the past,

and cannot exceed 12 intervals (one hour)

• When neither pnode, portfolio, nor interval5 is provide, then all public pnodes for the latest interval are

returned

Example:

GET /markets/real-time/{day}/reports/lmp-exante?pnode=ITCI

&interval5=2020-11-05T21:00:00-05:00,2020-11-05T21:05:00-05:00,2020-11-05T21:10:00-05:00

The following real-time endpoints support this feature:

GET /markets/real-time/{day}/reports/lmp-exante}

GET /markets/real-time/{day}/reports/lmp-expost

GET /markets/real-time/{day}/reports/zonal-lmp-exante

GET /markets/real-time/{day}/reports/zonal-lmp-expost

The query parameter allows providing multiple values as a comma-separated list or “exploded” into multiple query

parameters. This is true for any APIs that support lists in the MUI 2.0 APIs. For example, the following two calls are

equivalent:

GET /markets/real-time/{day}/reports/lmp-exante?pnode=ITCI

&interval5=2020-11-05T21:00:00-05:00, 2020-11-05T21:05:00-05:00

Is equivalent to:

GET /markets/real-time/{day}/reports/lmp-exante?pnode=ITCI

&interval5=2020-11-05T21:00:00-05:00&interval5=2020-11-05T21:05:00-05:00

Confirming Financial Schedules and Contracts

The POST endpoint /markets/bilateral/participants/{participantName}/contract-confirmation is used to confirm

both contracts and schedules. It can be used to approve a contract and a schedule in one transaction. If only one type

is being confirmed, then the type not included must be set to null or an empty data set.

MISO MUI 2.0 API User Guide

Optional JSON Elements

The OpenAPI specification documents if an element is optional or required. It also often the cases that a higher-level

object is optional, but if it is included, all fields must be supplied. Again, this is described in full by the OpenAPI

specification.

The concept of sparse updates is also supported. Therefore, if an optional element is not posted as part of an update,

but previously it has been, the absence of the element will not cause a delete of the element in the database.

Deletes must be explicitly specified.

API and Error Responses

A common API Response JSON message is returned for errors or on successful submission of a request to update a

resource in addition to the status returned by the HTTP status code. This is done to provide the possibility of

warnings or other feedback beyond what the HTTP status code can convey.

For example, a successful submission could return:

{

"responses": [],

"action": "SUBMITTED",

"transactionId": "<transaction id>",

"transactionTime": "YYYY-MM-DDTHH:MI:SS-05:00"

}

While an error on a submit (or query) could return something like:

{

"action": "SUBMIT_FAILED",

"responses": [

{

"messages": [

{

"level": "ERROR",

"msgId": "MESSAGE_ID",

"params": [],

"userMsg": "Bad request message for MESSAGE_ID."

}

]

}

"transactionId": "<transaction id>",

"transactionTime": "YYYY-MM-DDTHH:MI:SS-05:00"

}

{

"responses": [],

"action": "SUBMITTED",

"transactionId": "-1",

MISO MUI 2.0 API User Guide

"transactionTime": "2020-08-20T02:24:51-05:00"

}

See the OpenAPI specification MUI 2.0 API Specification.yaml

for details regarding the specific API response

formats for each endpoint.

HTTP Status Codes

The follow HTTP Status Codes are used by the RESTful MUI API.

HTTP Status Code Description

200 OK

Successful operation.

201 Created

Created.

202 Accepted

The request has been received but not yet acted upon.

Only applies to asynchronous APIs.

400 Bad Request

User error. Request was invalid for some reason. See

response for details.

403 Forbidden

Participant does not have token.

2) Rejected due to insufficient permissions.

404 Not Found

Resource not found. The path provided does not point

to an entity in the system.

405 Method Not Allowed

HTTP request method is not supported.

406 Not Acceptable

Target resource does not have an acceptable

representation based on content negotiation headers

and default representation.

415 Unsupported Media Type

Server refuses to accept the request due to

unsupported payload format.

429 Too Many Requests

User has sent too many requests in a given amount of

time.

500 Internal Server Error

Servers are not working as expected. The request is

probably valid but needs to be requested again later.

503 Service Unavailable

Service Unavailable.

504 Gateway Timeout

Gateway did not a get a response in time from the

upstream server needed to complete the request.

MISO MUI 2.0 API User Guide

Transaction Semantics and Transaction Identifier

Each submittal is executed using a transaction and the server logs the submittal request message and identifying

aspects of the message.

Each API request produces a uniquely identifying transaction identifier. This identifier is then returned in the http-x-

request-id response header for all requests, and as part of the response body itself when errors are encountered or

for successful submissions.

The data submitted is saved and can be recalled by a subsequent query. It should be noted that there is a limited on-

line data retention window after which special requests will need to be made to MISO in order to retrieve historical

data.

Transaction Log

The transaction event log maintains a complete history of all changes initiated by the participant interface, whether

initiated by the web user or directly against the exposed APIs. This log is available for review via the web interface.

The fields supported include:

• Transaction ID

• Time and Date of Transaction Event

• REST Operation

• URL Path, including query parameters

• Status

• Participant ID of the owner of the data set

• Username of the submitter (or web user)

• Service handling the request

• For submissions the data that was posted by the client

Note: Response payloads for GET response are not stored.

JSON Data Type and Specification Semantics

The API adheres to the OpenAPI specification, for a general discussion of the supported data models (schemas) see

the Swagger website (www.swagger.io

JSON Date and Time in the MUI interface.

Time is described in different ways depending upon the message and use case. All values are processed in Eastern

Standard Time and if the time value is included it must include the ‘-05:00’ offset so the intention is clear.

If a different Coordinated Universal Time (UTC) offset is supplied the message will be rejected.

MISO MUI 2.0 API User Guide

Schema

Description

Type

Example

HourLabel Hour-ending label.

Represents an hour segment

of time. The first hour of a day

is HE1 and the last hour of a

day is HE12.

Integer 1

MarketOperatingDay

Effective market operating

day of data. RFC 3339. 'YYYY-

MM-DD'.

String

‘2019-03-14’

MarketIntervalLabel

Effective market interval of

data.

Date-time as defined in RFC

3339. 'YYYY-MM-

DDTHH:MM:SS-05:00'.

Note: 5-minute intervals are

interval ending. Therefore, for

a given day, ‘00:05:00-05:00’

represents the first 5-minute

interval of the first hour. The

last or twelfth 5-minute

interval is ’01:00:00-05:00’.

This applies to both Real-Time

5-minute data and dispatch

notifications.

String

'2019-03-14T14:50:00-05:00'

Daylight Savings Time Transition

MISO does not recognize daylight savings time transitions in the Spring and in the Fall. As a result, all times are

Eastern Standard Time. All days are composed of 24 hours. There are no 23- or 25-hour days.

All passed in time values must include the ‘-05:00’ UTC offset to be clear that it is Eastern Standard Time. Likewise,

all returned time values are Eastern Standard Time and include the ‘-05:00’ UTC offset.

MP Representing Asset Owners

The following examples show how an MP submits query requests or submits data on behalf of asset owners. To use

this method, the MP must be an authenticated user with the proper permissions granted to act as an agent for other

participants. Also, the asset owner must be registered granting permission to the MP to submit and query data on

their behalf.

MISO MUI 2.0 API User Guide

MP Query/Submit on Behalf of Asset Owners

When an MP queries data on behalf of an asset owner, the asset owner NERC ID is specified using the x-acting-

participant header as part of the request. The x-acting participant is the equivalent of “party” in the legacy MUI

XML. If the resource requested applies to a particular asset owner, then the asset owner will also be present in the

URL, and validation will be performed such that the x-acting-participant header provided aligns with the participant

specific resource being requested. If the x-acting-participant is not provided, then the NERC ID is the default value

for this authorization.

The rule is that whenever an MP is representing an asset owner, the x-acting-participant header is required to be the

asset owner and needs to match the participantName parameter.

If the MP chooses to submit a query request without representing an asset owner, then the request should not

include the x-acting-participant attribute.

Notification Dispatch Messages sent to MP

When an MP is the registered handler for notification and deployment dispatch instructions, then they will have

subscription in addition to, or instead of, the asset owner. The asset owner name must be registered to be

represented by the MP receiving the message.

4. Testing in the Customer Connectivity Environment (CCE)

MISO provides a test environment where members can safely test their systems. This section describes the

particulars of this environment and how it differs from production.

CCE URL

Forming proper paths in CCE is exactly like production, except for the base URL. For testing in CCE please use base

URL below.

https://cce.midwestiso.org/dart2

See section OpenAPI Specification Schema for more information.

For CCE, MISO will send Notifications from the following IP Address.

148.142.64.15

Historical Data in CCE

While production data is a rolling 10 days of data as each market day passes, CCE contains a static 10 days of data.

MISO periodically refreshes CCE data with a snapshot from production and will send an announcement when this

occurs. Below list a few caveats to CCE data refresh.

• Permissions are not copied or synced between CCE and production. Permissions between these

environments are managed independently by the LSA.

MISO MUI 2.0 API User Guide

• Historical transaction logs and notifications are not copied from production to CCE. This is temporary as the

new MUI 2.0 system does not use the same data source as the current production MUI for this type of data.

Once the new MUI 2.0 is in production, data refreshes will include both transaction log and notification

history.

• Transactions submitted to CCE will create a transaction log entry in CCE that can then be queried.

• Notification initiated from CCE using the notification test tool will create a historical notification that can

then be queried.

To determine the current range of data within CCE, log in to the interactive CCE MISO User Interface. The

announcement on the splash screen indicates the current data range.

Rate Limits in CCE

Currently in the Customer Connectivity Environment (CCE) MUI 2.0 rate limits are set to what we expect to have

them set in production and may vary from the legacy MUI. For an explanation of rate limits in production see section

Rate Limits.

Notification Testing in CCE

Notifications target URLs are set up in either in CCE or in Production. These are independently set up and are NOT

synced between CCE and Production nor between legacy MUI and the new MUI 2.0. Below are important aspects of

Notification behavior in CCE:

• MUI 2.0 does not contain legacy notifications. To create a set of historical notifications, use the Tools-

>Notification Subscription screen in the MUI 2.0 user interface and generate test messages. A MUI user

must have their Local Security Administrator grant them “DART: Notification URLs (submit)” access in CCE

to generate test messages.

• During the time where both legacy and new MUI 2.0 are running in parallel, the Notifications target URLs

between legacy and MUI 2.0 are independently managed. Meaning target URLs in legacy are NOT

replicated into MUI 2.0 and vice versa. This is by design as the notifications from legacy and MUI 2.0 cannot

both hit the same listener. This is because the MUI 2.0 Notifications have a JSON body and the legacy

Notifications have an XML body.

• A MUI user must have their Local Security Administrator grant their certificate “DART: Notification URLs

(submit)”. Access between CCE and Production is unlinked, meaning any access granted in CCE does not

grant access in Production and vice versa.

• Access between legacy and MUI 2.0 is synced within the same environment, but not across environments. In

other words, an LSA access change to CCE applies to both Legacy MUI and MUI 2.0 for both the MUI API

and Notifications. But that access change made to CCE will NOT show up in production.

• Setting up URLs in CCE does not count against the URL limit in Production and vice versa.

• While MISO periodically copies Production data into CCE, the Notifications data and permissions are not

copied over.

MISO MUI 2.0 API User Guide

5. Terms and Acronyms

Term or

Acronym

Description

Asset Owner

(AO)

An asset owner is a transmission company customer such as a generation company

or load serving entity that is represented in the market by a Market Participant

(MP).

Asynchronous

Messaging

See push messaging.

Coordinated

Universal Time

(UTC)

The primary standard by which time is measured worldwide. It is not adjusted for

daylight saving time.

Energy The generic name applied to generation supply and demand response resource

offers submitted into the day-ahead and real-time markets. The schedule offer

applies to energy supply and is used both by generation company participants as

well as demand response resource participants.

Hyper-text

Transfer Protocol

(HTTP)

An application-level protocol for distributed, collaborative, hypermedia, information

systems. Or, more simply, HTTP is a network communications protocol used to send

and receive data over the internet. The version of HTTP used by this specification is

1.1 and this is often referred to as HTTP/1.1. The HTTP/1.1 protocol is defined by

RFC 7231.

Hyper-text

Transfer Protocol

Secure (HTTPS)

A secure protocol where the security is established by SSL/TLS (see terminology

entry). HTTPS does not define, nor does it add new communications features to

HTTP, it is merely a secure version of HTTP. The HTTPS name is used to specify the

protocol in the URL declaration to identify it as being secured by an SSL.

Inter-control

Center

Communications

Protocol (ICCP)

Enables data exchange over Wide Area Networks between utility control centers,

Independent System Operators (ISOs), Regional Transmission Operators (RTOs),

and other generators

Independent

Market Monitor

(IMM)

The entity responsible for monitoring energy and capacity markets, generation

market power indices, energy imbalance markets and congestion management

mechanisms. The monitor also collects data and analyzes markets for potential

indicators of market power such as withholding capacity or bidding anomalies.

Internet Protocol

(IP)

The principal communications protocol to relay datagrams across network

boundaries

JavaScript Object

Notation (JSON)

An open standard file format, and data interchange format, that uses human-

readable text to store and transmit data objects consisting of attribute–value pairs

and array data types.

Local Security

Administrator

(LSA)

Each Market Participant has one or more individuals designated as an LSA. The LSA

manages MUI users (creation, access management, and termination).

MISO MUI 2.0 API User Guide

Term or

Acronym

Description

Market

Participant (MP)

A market participant is a registered user who is authorized to submit offers and bids

into the day-ahead and real-time market on behalf of another participant known as

an asset owner (AO). All settlements are between the MP and the Regional

Transmission Organization (RTO).

Market User

Interface (MUI)

A web user interface provided by MISO that can be used to interact with REST APIs.

Node

See entry for Pnode.

OpenAPI

Specification

(OAS)

OpenAPI Specification (OAS), formerly Swagger Specification, is an API description

format for RESTful APIs. See https://swagger.io/specification/

for more details.

Pricing Node

(Pnode)

All resources, generators, demand response resources, and demand and virtual

bid/offer locations are specified at specific pricing nodes defined by MISO. Pricing

nodes are network locations where a locational marginal price (LMP) has been

computed. All nodes described in this document are pricing nodes. Pricing nodes are

commonly associated with the location of the resource and therefore the attribute

or field name of location is commonly used.

Private Data Private data refers to access control of data. Private data is data that is private to a

given participant. Private data includes supply offers, resource attributes and

parameters, demand bids, virtual offers and bids, and market clearing results. Access

permission must be granted to read and write private data. Such access permission

is implicit to the participant who owns the data or the MP that operates as an agent

for the owner participant. Not all private data is necessarily equally available for

access by MPs and participants.

Public Data

Public data refers to access control of data. Public data is data that is common to all

registered participants and the general public (see entry for general). Not all public

data may be available to the general public. Contrast public data with private data.

Push Messaging Push messaging, also called a webhook, is an asynchronous sending of messages by

MISO to participant message listeners. This is referred to as asynchronous because

it is not a response to a requested message (e.g. Request/Response). Thus, it is

activity asynchronous to the activity of the participant. Therefore, the participant

must always be listening to asynchronous messages. This type of messaging has

become more popularly known as push style messaging because the message is

pushed by MISO to the participant as opposed to the more normal request message

issued by the participant.

Request/

Response

Request/Response is a messaging style where a client sends a request message to a

server and the server responds with a response message. Request/Response is also

sometimes called Client-Server messaging. In the case of the RTO interface, the

participant is always the client who initiates the request and the RTO is always the

server who responds with a reply.

MISO MUI 2.0 API User Guide

Term or

Acronym

Description

Representational

state transfer

(REST)

A software architectural style that defines a set of constraints to be used for

creating Web services. Web services that conform to the REST architectural style,

called RESTful Web services, provide interoperability between computer systems

on the internet. RESTful Web services allow the requesting systems to access and

manipulate textual representations of Web resources by using a uniform and

predefined set of stateless operations. Other kinds of Web services, such as SOAP

Web services, expose their own arbitrary sets of operations.[1]

Regional

Transmission

Organization

(RTO)

Controls or operates the transmission facilities of its transmission-owning members

used for the transmission of electricity in interstate commerce and provides

transmission service under the Tariff.

Supervisory

Control and Data

Acquisition

(SCADA)

A control system architecture comprising computers, networked data

communications and graphical user interfaces for high-level process supervisory

management..

Secure Sockets

Layer (SSL)

A protocol standard used to establish a secure, encrypted, connection between a

given client and server. The MUI uses TLS, which is an updated, more secure, version

of SSL.

Transmission

Control Protocol

(TCP)

A standard that defines how to establish and maintain a network conversation

through which application programs can exchange data. TCP works with the

Internet Protocol (IP), which defines how computers send packets of data to each

other.

Transport Layer

Security (TLS)

An updated, more secure version of Secure Sockets Layer (SSL). It is used to provide

HTTPS encrypted communication between the server and the client.

Uniform

Resource

Identifier (URI)

A similar construct to URL. URL is a kind of URI. The URI is used to name internet

resources that are not necessarily internet locations. More information on URI can

be found in RFC 3986.

Uniform

Resource Locator

(URL)

URL (which is also a URI) is the standard method for specifying network addresses

and network resources used by internet protocols. The URL defines the protocol,

network host address, optional port number, resource path and fragments. URLs are

used to specify MISO’s server addresses that receive messages sent by the

participants. The URL is also referred to as the endpoint for a REST API. URL/URI

are defined by RFC 3986.

Valid

As used in this context, valid is the measurement of a JSON document that is

correctly formatted according to its schema. In the case of the MUI this schema is

described by an OpenAPI Specification. The RTO accepts only valid JSON

documents in messages received from participants. All valid JSON documents are

implicitly also well-formed.

Well-formed Well-formed measures a JSON document that is formatted according to the syntax

rules set forth by JSON standards. A well-formed document can be correctly parsed

by a JSON parser. A document that is not well-formed may fail to parse completely.

See RFC 8259 for more details regarding the JavaScript Object Notation (JSON)

data interchange format.

MISO MUI 2.0 API User Guide

Recent Change Summary

Revision Date Comments

1.12 7/23/2021 JSON Date and Time in the MUI interface: corrected that 5-minute real-

time intervals are interval ending and which twelve 5-minute increments

make up a given hour.

1.13 8/12/2021 Session Management: clarified applications may have to periodically

reestablish their session

1.14 9/14/2021

HTTP Headers: updated section to include the User-Agent header must

not emulate a browser and needs to be explicitly overwritten.

1.15 9/20/2021 Rate Limits: corrected table listing rate limited endpoints.

1.16 10/1/2021 Rate Limits: clarified how rate limits are enforced on only GET calls and

enforced for a given client certificate (user) and the acting asset owner used

in the GET call.

Notifications – Case Event Notification: new section providing details on

the new “case-event” notification

Updated server IP address that sends CCE Notifications. The new IP

address is 148.142.64.15.

1.17 12/6/2021

Cookie:

When using a browser-based API tool such as Chrome Talend, a

“Cookie” header with a null/blank value is required on POST transactions to

overwrite the XSRF session token value. If it is not included, the response

will be a 403 Forbidden.

MUI 2.0 Consumer Notifications.yaml: removed references to obsolete file

1.18 2/15/2022 Updated Rate Limits

1.19 6/17/2022 Updated links, removed Case Event Notification section 2.9.1

MISO MUI 2.0 API User Guide

Revision Date Comments

1.20 7/12/2022 Updated endpoints in section 2.5.1

1.21 5/23/2023 Corrected endpoint in section 2.5.1

1.22 1/18/2024 Updated related documents links