v1
latestOpenAPI 3.1.02026-07-2694207444.7 KBIntraday Trades By Trade Time
Returns intraday contracts with trades, where trades have a trade time in between tradeTimeFrom - tradeTimeTo and at least one leg in the provided areas.
All trades have at least one leg belongs to Nord Pool. However, trades where both legs belong to other PXs are excluded from the response.
Data is available with a delay of approximately 20 minutes.
Note: The time difference between tradeTimeFrom and tradeTimeTo cannot exceed 12 hours. This limitation was introduced for performance reasons to restrict the response size. During periods of high load on the system, responses may take longer than expected. In such situations, it is recommended to query data in hourly intervals, for example tradeTimeFrom=2025-04-01T01:00:00Z and tradeTimeTo=2025-04-01T02:00:00Z.
Response field descriptions
contracts: a list of contracts to which these trades belong
Each contract contains:
-
contractId: identifier of the contract
-
contractName: a descriptive name for the contract (e.g., QH-20250331-09).
-
deliveryStart: the timestamp when the contract delivery starts
-
deliveryEnd: the timestamp when the contract delivery ends
-
trades: a list of trades that have an updated time between updated time from and updated time to
Each trade includes:
-
tradeId: identifier of the trade
-
tradeTime: the timestamp of trade creation
-
tradeUpdatedAt: the trade creation time (revisionNumber=1) or time of a trade modification (revisionNumber>1)
-
tradeState:
- Completed - the trade is completed
- Cancelled - the trade is cancelled
- Disputed - the trade is pending decision for cancellation
-
revisionNumber: revision number for trade modification request. Should be incremented with a subsequent trade modification request.
-
price: price in EUR/MWh or GBP/MWh
-
volume: quantity in MW
-
tradePhase: there's two matching modes:
- Continuous - the normal top of order book matching
- Auction - the matching mode, where basically the buy and sell orders are matched in a similar manner as auction orders. This only happens when capacity is added in between areas - basically, in that case, the order books can be overlapping with buys in one area being much higher than sells in another area. In order for the price to be fair for both the sellers and buyers, this auction matching mode is used.
- None - for old trades without this information
-
crossPx:
- false: both legs belong to the Nord Pool market
- true: one of the legs belongs to Other Power Exchanges (OPX). Then the trade contains "referenceOrderId" only for the side which is presented in Nord Pool, the other side doesn't have reference order id ("referenceOrderId": null).
-
legs: a list of trade legs
Each leg contains:
-
deliveryArea: delivery area that this order belongs to
-
referenceOrderId: identifier of the order involved in the trade. In transactions where one party is external to Nord Pool, the referenceOrderId will be null for the leg that belongs to OPX.
-
tradeSide: Buy or Sell
-
-
Query parameters
Comma-separated list of areas (e.g., NO1, NO2). Supported: KT(legacy),NO1,NO2,NO3,NO4,NO5,SE1,SE2,SE3,SE4,FI,DK1,DK2,EE,LT,LV,AT,BE,FR,50Hz,AMP,TTG,TBW,NL,PL,TEL,BG,UK
Trade date and time starts, referring to a UTC datetime. Trades at or later this time will be included in the response. Format yyyy-MM-ddThh:mm:ssZ, for example 2024-08-15T01:00:00Z
Trade date and time ends, referring to a UTC datetime. Trades earlier than this time will be included in the response. Format yyyy-MM-ddThh:mm:ssZ, for example 2024-08-15T01:15:00Z
Response
OK