MISO Market User Interface (MUI 2.0)

MISO Market User Interface (MUI 2.0)

API User Guide February 15, 2022

Revision 1.18

MISO MUI 2.0 API User Guide

1

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 .......................................................................................................................................................................................... 10 Historical Data Availability ........................................................................................................................................................... 11 Using JSON ......................................................................................................................................................................................... 11 Notifications....................................................................................................................................................................................... 11

Notifications – Case Event Notification .............................................................................................13

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

3. Common Principles ............................................................................................................................................. 14 Participant Registration ................................................................................................................................................................ 15 OpenAPI Specification Schema................................................................................................................................................... 15


2

HTTP Methods .................................................................................................................................................................................. 16 HTTP Headers ................................................................................................................................................................................... 16 Delete Behavior ................................................................................................................................................................................ 17 Pnode Based GET Endpoint Behavior ...................................................................................................................................... 17 POST Endpoints Supporting Multiple Locations or Pnodes ............................................................................................. 19 Retrieving Bulk Real-Time Prices ............................................................................................................................................... 20 Confirming Financial Schedules and Contracts .................................................................................................................... 20

Optional JSON Elements ............................................................................................................................................................ 21 API and Error Responses ............................................................................................................................................................ 21

HTTP Status Codes .............................................................................................................................22

Transaction Semantics and Transaction Identifier .........................................................................23

Transaction Log ..................................................................................................................................23

JSON Data Type and Specification Semantics .................................................................................................................... 23 JSON Date and Time in the MUI interface. ......................................................................................23

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

Notification Dispatch Messages sent to MP ....................................................................................25

4. Testing in the Customer Connectivity Environment (CCE) .................................................................. 25 CCE URL .............................................................................................................................................................................................. 25 Historical Data in CCE .................................................................................................................................................................... 25 Rate Limits in CCE ............................................................................................................................................................................ 26 Notification Testing in CCE .......................................................................................................................................................... 26

5. Terms and Acronyms .......................................................................................................................................... 27 Recent Change Summary ..................................................................................................................................................................... 30


3

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.


4

Related Documents Document Name Description

MUI 2.0 API Specification.yaml 1 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

MUI 2.0 API Mapping to Legacy API Maps new MUI 2.0 API to the legacy API

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.

1 Should be reviewed using Swagger Editor

https://cdn.misoenergy.org/MUI%202.0%20API%20Specification382971.yaml

https://cdn.misoenergy.org/Local%20Security%20Administrator%20Policy102808.pdf

https://cdn.misoenergy.org/Self-Service%20LSA%20User%20Guide102815.pdf

https://www.misoenergy.org/markets-and-operations/market-participation/

https://cdn.misoenergy.org/MUI%202.0%20API%20Mapping%20to%20Legacy%20API462842.pdf



5

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


6

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

2 Should be viewed using the Swagger Editor



7

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.

https://editor.swagger.io/


8

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.


9

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

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.

https://www.misoenergy.org/markets-and-operations/market-participation/






10

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://cce.midwestiso.org/dart2/markets/day-ahead/2019-07-22/reports/lmp-exante?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).

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

https://cce.midwestiso.org/dart2/markets/day-ahead/2019-07-22/reports/lmp-exante?X

https://cdn.misoenergy.org/Market%20Portal%20Certificates70886.zip


11

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

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

https://cdn.misoenergy.org/External%20Systems%20Acceptable%20Use%20Policy70894.pdf

https://www.misoenergy.org/


12

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.

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.


13

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 – Case Event Notification

MUI 2.0 introduces a new notification “case-event”. This notification is sent when certain market events occur. At this time there are four events described in the table below

Event Description

Real-Time ex-ante prices available

studyModeShortName = RTUDS

Approximately every 5 minutes when the ex-ante MW and prices are available.

Real-Time ex-post prices available

studyModeShortName = RTLMP

Ex-post price is calculated and available shortly after Real-Time ex-ante are available.

Note ex-post price is approved 1-3 days later. This event type will get sent both when ex-post prices are available and when ex-post prices are approved.

The eventType field distinguishes these two events:

eventType = CaseSolved = unapproved prices

eventType = CaseApproved = 1-3 days later, approved prices

Day-Ahead case approved and ex-ante prices available

studyModeShortName = DayAhead

Sent when Day-Ahead ex-ante data is available (usually at 1:30p EPT).

Day-Ahead ex-post prices available

studyModeShortName = DALMP

Sent when Day-Ahead ex-post data is available (usually at 1:30p EPT). While often ex-ante and ex-post data is available at the same time, it is possible for ex-post to get posted after ex-ante.

The elements of a “case-event” are described in the MUI 2.0 Consumer Notifications.yaml. Below is some additional detail.

Element Description

day For Real-Time, the operating day for the interval. For Day-Ahead, the operating day is the next day.

interval Only applies to Real-Time. The 5-minute interval for the approved case.

eventType This will be “CaseSolved” for unapproved RTLMP ex-post events. Otherwise it will be “CaseApproved”.

eventTime When the case-event is generated

studyModeShortName DayAhead – DayAhead ex-ante data is available

https://cdn.misoenergy.org/MUI%202.0%20Consumer%20Notifications503399.yaml


14

DALMP – DayAhead ex-post data is available

RTUDS – Real-Time ex-ante prices are available

RTLMP – Real-Time ex-post prices are available

market day-ahead or real-time

priceType ExAnti – applies to DayAhead and RTUDS

ExPost – applies to DALMP and RTLMP

Note: Currently the Day-Ahead event is sent at case approval, but the data is not available until 12:30p EPT or later if Day-Ahead is delayed. MISO intends to change this so that the event is generated with the data is available.

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.


15

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:

• A unique username that is defined within the digital certificate4

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


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"

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


https://editor.swagger.io/

https://cce.midwestiso.org/dart2

https://markets.midwestiso.org/dart2


16

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

https://markets.midwestiso.org/dart2/markets/day-ahead/2020-08-15/reports/lmp-exante?portfolio=%22ALL


17

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


18

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-


19

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


20

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


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

Is equivalent to:


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


21

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


22

"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 1) 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.



23

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.

http://www.swagger.io/


24

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.


25

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.


26

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


27

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


28


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.

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]

https://swagger.io/specification/

https://en.wikipedia.org/wiki/Software_architecture

https://en.wikipedia.org/wiki/Architectural_style

https://en.wikipedia.org/wiki/Web_service

https://en.wikipedia.org/wiki/Internet

https://en.wikipedia.org/wiki/Web_resource

https://en.wikipedia.org/wiki/Stateless_protocol

https://en.wikipedia.org/wiki/SOAP

https://en.wikipedia.org/wiki/Representational_state_transfer#cite_note-1


29


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.

https://en.wikipedia.org/wiki/Control_system

https://en.wikipedia.org/wiki/Computer

https://en.wikipedia.org/wiki/High-level


30

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


31

Revision Date Comments

MISO Market User Interface (MUI 2.0)

Documents

Transcript of MISO Market User Interface (MUI 2.0)