This article assumes some familiarity with HTTP in general and RESTful APIs in particular (background). It also follows very similar patterns to the concepts for forecast ratings, so the examples on forecast ratings may be helpful for background.

Simplified Example: Transmission Owner Sends Ratings with curl

If a Transmission Owner is their own Ratings Provider, they must regularly send real-time ratings to their Transmission Provider. TROLIE provides the postRealTimeProposal operation for this purpose.

Assume the Transmission Owner creates a file called input.json containing their ratings measurements. An example of the required format for the file is given below.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

{
  "proposal-header" : {
    "source": {
      "last-updated": "2025-10-31T15:05:43.044267100-07:00",
      "provider": "UTILITY-A",
      "origin-id": "5aeacb25-9b65-4738-8a00-ac10afa63640"
    },
    "default-emergency-durations": [
      {
        "name": "lte",
        "duration-minutes": 240
      },
      {
        "name": "ste",
        "duration-minutes": 30
      },
      {
        "name": "dal",
        "duration-minutes": 15
      }
    ],
    "power-system-resources": [
      { "resource-id": "8badf00d",
        "alternate-identifiers": [
          {"name": "segmentX", "authority": "TO-NERC-ID"},
          {"name": "LINE1 SEG-X", "authority": "RC-NERC-ID", "mrid": "8badf00d"}
        ]
      }
    ]
  },
  "ratings": [
    {
      "resource-id": "8badf00d",
      "continuous-operating-limit": {
        "mva": 160
      },
      "emergency-operating-limits": [
        {
          "duration-name": "lte",
          "limit": {
            "mva": 165
          }
        },
        {
          "duration-name": "ste",
          "limit": {
            "mva": 170
          }
        },
        {
          "duration-name": "dal",
          "limit": {
            "mva": 170
          }
        }
      ]
    }
  ]
}

The format is one of TROLIE’s supported media types named application/vnd.trolie.rating-realtime-proposal.v1+json.

Pushing input.json to TROLIE with curl

Given the above input.json, run the following command to send it to the TROLIE server:

1
2
3
4
5
6

curl -d @input.json \
-X POST \
-H "Content-Type: application/vnd.rating-realtime-proposal.v1+json" \
-H "Accept: application/vnd.trolie.rating-realtime-proposal-status.v1+json"
-o output.json \
"https://trolie.example.com/rating-proposals/real-time"

If this submission is successful, output.json will contain the contents of the response from TROLIE. The format of the response is defined by another TROLIE media type: application/vnd.trolie.rating-realtime-proposal-status.v1+json. An example of this response format is given below:

1
2
3
4
5
6
7
8
9
10
11
12

{
  "ratings-provider": {
    "provider": "UTILITY-A",
    "last-updated": "2023-07-12T15:05:43.044267100-07:00",
    "origin-id": "5aeacb25-9b65-4738-8a00-ac10afa63640"
  },
  "incomplete-obligation-count": 0,
  "incomplete-obligations": [],
  "invalid-proposal-count": 0,
  "proposal-validation-errors": []
}

Invalid Ratings for Individual Resources Should be Tolerated

The TROLIE spec supports allowing some individual ratings to be invalid without rejecting the entire proposal, much like with forecasts.
The pattern for incomplete and invalid proposals is similar to the one described for forecasts illustrated in Forecast Submittal.

incomplete-obligation-count as a Monitoring Function

The use of the proposal status in realtime will differ somewhat from the usage with forecast ratings. The forecast obligation always applies to a particular window. Real-Time ratings, in contrast, are always simply updated against the current time. The real-time Clearinghouse may run more frequently than once an hour, and rating proposals may be run even more, or less frequently than the Clearinghouse.

In addition to flagging data that is missing, the incomplete-obligation-count also flags data that is considered too “stale” to use. The definition of what is considered stale is ultimately up to the Clearinghouse implementation. If supported by the Clearinghouse, incomplete-obligation-count may also consider obligations for resources that would normally not have their ratings submitted as TROLIE proposals, but rather through other means, such as ICCP.

Therefore, clients should rely more on asynchronous use of getRealTimeProposalStatus as a way to monitor whether the Clearinghouse considers their ongoing data stream healthy.

Jointly-Owned Facilities

In a jointly-owned facility there may be one or more Ratings Providers for a given facility. This is expected to be fairly typical on seams. The pattern is nearly identical to the way this works for forecasts, with the exception that the Clearinghouse may run much more frequently. From a submittal perspective, this is inconsequential: Each Ratings Provider simply submits their own Ratings Proposal for their Ratings Obligation using the appropriate resource-id. As with all resource-id uses, the TROLIE spec is agnostic as to which kind of Power System Resource is nominated by the identifier, but it will typically be a Segment in the case of a Jointly-Owned Facility with multiple Ratings Providers.