NODES API Swagger Specification (2026)

Reference: OpenAPI 3.0.1 specification for the NODES trading platform, version 2.3.1296.0. Machine-readable API contract (271 endpoints, ~400 schema definitions), not a narrative document — the raw file is a 2.7 MB JSON export.

Raw file: raw/nodes-swagger.json. Related earlier NODES source: raw/fpm_s2-no2-seng_nodes.pdf (extracted to raw/fpm-s2-no2-nodes-extracted.txt) — the FPM presentation already cited as Source - NODES FPM Presentation (2026).

Extraction method: given the file’s size and structure, content was queried programmatically (endpoint groupings, schema field lists, and description strings) rather than read as narrative text — the equivalent of “reading fully” for a machine-readable API contract. No endpoint was actually called; this documents the platform’s data model and workflow design, not observed runtime behaviour.

Summary

Closes the wiki’s previously open data gap on NODES’s API and data-standard specifications (see NODES › Data gaps, pre-2026-09-04). The specification reveals a substantially richer resource model than the FPM presentation’s conceptual description covered, organized around roughly a dozen domains: grid topology (GridAreas/GridNodes/GridGroups), assets and portfolios, the three product families’ tender/contract/activation objects, orders and trades (the underlying auction/matching engine), settlement and invoicing, pre-qualification, and organization/market administration.

Grid topology — a three-tier hierarchy

• GridArea: “a geographical area that is divided into grid nodes… typically operated by a DSO or a TSO” — has an optional map polygon and a visibility setting (isPubliclyVisible, gridNodePolygonVisibility) for whether the area shows on a public portal.
• GridNode: “a physical part of the electrical grid… connected to a grid area and a price area, and forms a hierarchy. DSO will create/manage grid nodes in his grid.” All orders and trades attach to a grid node. Notable field: portfoliosBlocked (a node can be closed to new asset-portfolio assignment). Nodes carry an optional mpid “to map grid nodes across several systems” — an explicit cross-platform interoperability hook.
• GridGroup: “a collection of grid nodes that are connected together for a specific purpose, such as a microgrid or a virtual power plant. The grid group does not necessarily reflect the physical grid.” — a deliberately non-physical, purpose-built grouping distinct from GridArea.

Order routing through the hierarchy: an Order can carry excludeGridNodeIds (explicitly blocking specific nodes, which also stops the order propagating up/down the grid-node hierarchy to or from that node) and ownerSubscriptionTypes, described as data “used by the matching service to match on visibility (DSO/TSO) for longflex orders.” This is the concrete matching-engine mechanism behind what NODES › Congestion area linking describes qualitatively from the FPM presentation — worth noting that “congestion area” (the product-facing term) is not confirmed to map one-to-one onto “GridArea” (the API term); the two describe the same conceptual layer but the identity isn’t verified from this source alone.

Product families — technical detail

LongFlex arming (LongflexArming): “Represents a flexible schedule for a long-term contract. Used for armable contracts… The contract owner (buyer) can arm selected periods within the contract period,” with system-calculated totalEnergy and totalPrice per arming. This is the technical implementation of the Armering overlay product already documented qualitatively at NODES › Geographic reach — confirms it is a first-class contract-schedule object (armings reference a contractId/tenderId and a periodFrom/periodTo), not an ad hoc manual process.

MaxUsage runs on bilateral signature, not automated matching. MaxUsageContract carries signedByBuyer/signedBySeller booleans, separate signedByBuyerUserId/signedBySellerUserId and signature-date fields, and a rejectionComments field for when a tender response is declined. Usage limits are tracked at multiple granularities simultaneously: dailyMaxValue, dailyAverageValue, contractPeriodMaxValue, contractPeriodAverageValue. limitType allows the cap to be expressed as either a percentage or an absolute power unit. Both MaxUsageTender and MaxUsageContract schedule activity via an exposed crontab expression (standard 5-field cron syntax, documented inline in the schema) — a detail not previously in the wiki, and notable because it means MaxUsage’s characteristic peak-hour targeting (e.g. Effekthandel Väst’s morning EV-charging cap) is configured as a literal cron schedule rather than a bespoke rule engine.

FlexibleDispatchTenders/Contracts — a fourth tender/contract pairing distinct from ShortFlex, LongFlex, and MaxUsage, carrying tenderType, regulationType, and quantityType; the tender object additionally carries an enaCommonParameters field (not present on the resulting contract object). That last field is the connection to the UK finding below: EnaCommonParameters is the ENA Open Networks standard product-taxonomy object, so FlexibleDispatch reads as the NODES product built specifically to carry the ENA standard’s flexibility-service definition — plausibly the UK-market product, rather than a fourth Nordic product family. Not matched to any named Swedish or Norwegian product in the wiki’s existing coverage.

A previously undocumented UK deployment signal

The schema EnaAssetPqq is described in its own definition as: “ENA (Energy Networks Association) Asset Pre-qualification Questionnaire (PQQ) data. Contains properties for flexibility service pre-qualification based on the ENA ON Flexibility Service Pre-qualification Standard Template for Assets.”

ENA (Energy Networks Association) and its Open Networks programme are the UK’s cross-DSO flexibility-market standardization body — the UK counterpart to what Sweco’s Rec 8 (cited on the NODES page) recommends Sweden move toward. The schema’s fields are unambiguously UK-specific: MPAN (Meter Point Administration Number, the UK’s metering-point identifier, both import and export variants), UK-format connection-voltage tiers (0.23–132 kV), UK date format (DD/MM/YY), and UK asset/technology taxonomies (e.g. “Air source heat pump,” “EV Charger DSR” under demand technology type).

A companion object, EnaCommonParameters, models what reads as the ENA Open Networks standard flexibility-product taxonomy itself: paymentStructure, priceSetAt (price determination timing), availabilityRequestMechanism, availabilityAcceptanceTiming, minimumAggregateUnitSize, partialAvailabilityAcceptanceAllowed, timeVariableAvailabilityAllowed, maximumResponseTimeInSeconds, minimumUtilisationTimeInSeconds — a structured, standards-driven product-definition schema distinct from (and more elaborate than) how ShortFlex/LongFlex/MaxUsage tenders are defined.

Follow-up (2026-09-04): web research confirmed this reflects a real historical UK deployment — IntraFlex, a 2019–2021 trial by Western Power Distribution (now National Grid Electricity Distribution) that procured >50 MW across 241 trades on NODES’ ShortFlex market. No evidence was found of NODES operating a live UK market since; the major UK DNOs now run other platforms (Localflex/EPEX SPOT, Piclo, Electron/ElectronConnect). See Source - NODES IntraFlex UK Trial (WPD-NGED, 2019-2021) and NODES › UK — IntraFlex (2019–2022), and why the platform doesn’t run there today for the full picture.

Order/trade matching mechanics — block orders

The Order schema exposes a real auction mechanism not previously documented anywhere in the wiki: orders can be split into blockSizeInSeconds-sized blocks, with minBlocks/maxBlocks constraining how many blocks must match simultaneously for the order to be considered tradable, and minAdjacentBlocks/maxAdjacentBlocks further constraining those blocks to be consecutive. An orderGroupId links multiple orders that share block restrictions. This is materially more sophisticated than a simple single-period bid — it supports, for example, a resource that can only usefully deliver flexibility across several consecutive matched hours, refusing to be split into isolated hours.

Trades are generated automatically whenever a buy and sell order match (Trade schema: “Generated automatically by the system whenever two orders… matches”), each trade carrying its own gridNodeId and counterpartGridNodeId (the two grid nodes on either side of the trade — relevant when a trade crosses the grid-node hierarchy described above).

A documented trade-cancellation workflow

TradeCancellationRequest: “Represents a cancellation request for a ShortFlex trade. Either the buyer or seller can request cancellation, which must be approved or rejected by the counterparty. NODES operators can override pending requests by cancelling the trade directly.” States: Pending (awaiting response) → Active (approved) or Rejected, with Deleted reserved for an operator override. Fields capture an optional free-text reason from the initiator and a responseMessage from the counterparty, plus who responded and when. This is the first documentation in the wiki of what happens when a matched trade needs to be unwound — previously undocumented.

Settlement is configurable per market, per product

MarketSettlementConfig sets, independently for each market: shortFlexResolutionInMinutes, longFlexResolutionInMinutes, maxUsageResolutionInMinutes, and a separate calculation-rule reference per product (shortFlexPaymentFactorRule, longFlexCalculationRule, maxUsageCalculationRule). This means the granularity at which delivery is measured and paid for is a per-market configuration choice, not a platform-wide constant — relevant context for comparing settlement practice across NODES deployments (e.g. Effekthandel Väst vs Euroflex vs a hypothetical UK market).

Pre-qualification — document-based, not automated

PreQualificationRequirement (owned by an organization, presumably the buying DSO/TSO) carries a title/description/link and an uploadable attachment; PreQualificationSubmission references the requirement, carries its own uploadable attachment, and an accepted boolean set by the requirement owner. This confirms Sweco’s characterization (cited on NODES) of pre-qualification as a manual, per-market document exchange rather than a standardized automated check — consistent with why an FSP bidding on both NODES and SWITCH markets must prequalify twice.

Relevance to wiki