Source - SWITCH API Swagger v3.13 (2026)

SWITCH API OpenAPI specification, version 3.13.0.0. Published at the staging server qa-api.switchmarket.se. The Swagger JSON defines 25 endpoints across 7 tag groups. This is the authoritative machine-readable specification of SWITCH‘s external REST API — covering FSP bid submission, DSO order management, meter data, settlement, and resource configuration.

Document

• File: raw/switch-api-swagger.json
• Spec version: OpenAPI 3.0.4
• API version: 3.13.0.0
• Server: https://qa-api.switchmarket.se (staging)
• Endpoints: 25 paths, 7 tags (Identity, Meter, Product, Reading, Resource, User, Zone)

Feature tiers

SWITCH is gated by both a permission system and a feature system. Permissions control read/write access per resource type; features control which platform modules are licensed. Five feature flags appear in the spec:

This reveals that SWITCH is sold (or licensed to other DSOs) in modular tiers — a DSO needs only Grid to operate a market; an FSP/aggregator needs ResourceManagement.

Product type mapping

The API’s ProductType enum maps internal names to the standardized Swedish LFM product names:

Villkorade avtal is managed through the same API as the market products — they share the resource and meter data infrastructure, confirming E.ON’s model of villkorade avtal as a backstop to market-based procurement within a unified platform. (Villkorade Avtal, SWITCH › Villkorade avtal integration)

Resource model

The Resource object is the central FSP asset representation. Key fields:

Points of Delivery (PODs)

Aggregated resources are composed of PODs, each with a podId, name, maxQuantity, and a podType:

This is the granular asset taxonomy for NC DR alignment — BeFlexible D5.2 noted that SWITCH’s resource qualification was being updated to include sub-resource categorization matching NC DR requirements. The POD type enum is the implementation of that.

Seasonal availability schedule (LFM-p)

The AvailabilityScheduleOrder object (the DSO’s LFM-p order) has fields that reveal the full LFM-p product design:

The excludedPeriods field is operationally important: it allows an FSP to pre-declare windows where the resource is unavailable (e.g., FCR-D commitment, scheduled maintenance), preventing rejected offers due to cooldown/endurance conflicts.

The cleared schedule offer (GetClearedAvailabilityScheduleOffers) includes endurance and cooldown as per-offer fields — confirming that each FSP’s winning bid specifies its individual endurance commitment, which determines the stepped availability remuneration.

Forecasted demands

GET /api/product/resource/{resourceId}/forecasted-demands returns the DSO’s demand forecast for a specific resource, with DemandDetectionType:

This is how SWITCH communicates upcoming grid needs to FSPs ahead of activation — enabling automated bid submission strategies. An aggregator polling this endpoint can determine whether to pre-stage a resource for activation, or simply confirm availability commitment.

Baseline algorithms

BaselineAlgorithmType reveals three implemented baseline methods (not two, as previously documented):

The presence of HighXofY is new — not mentioned in the SWITCH user documentation previously ingested. This is a more sophisticated baseline method used by British DSOs (Mean X-in-Y) and cited in Sassone et al. (2025) as the standard UK approach. Its presence in SWITCH suggests the platform has more baseline flexibility than the user docs reveal.

Settlement structure

Two settlement endpoints confirm the two-component remuneration model:

Regular settlement (/api/product/settlement/specification):

• availabilityRemuneration + activationRemuneration per resource per period
• hasNonValidatedData flag — indicates settlement is pending meter data completion
• revalidationPossible — whether corrected meter data can trigger a re-run

Schedule settlement (/api/product/settlement/schedule/specification):

• remuneration + remunerationPenalty — the penalty structure for LFM-p missed activations
• ordersBelowThreshold — count of activations where delivery fell below the threshold
• activationCount and validationCount per resource

The remunerationPenalty and ordersBelowThreshold fields are the API implementation of the LFM-p endurance penalty mechanism: FSPs bidding lower endurance receive less availability remuneration, but each failed activation below the delivery threshold also generates a penalty entry.

Delivery validation status

FlexibilityDeliveryValidationStatus (10 states) reveals the full settlement validation pipeline:

States 3–6 and 8 represent incomplete meter data — the most operationally common failure. These map directly to the onboarding friction documented in BeFlexible: the most common reason FSPs fail to get paid is missing meter register configuration or missing data uploads. The RevalidateResourceTransactions endpoint (PUT /api/grid/resource/{resourceId}/transactions/revalidate) exists specifically to re-run validation once data is corrected.

Offer rejection also has granular reasons (AvailabilityOfferClearingStatus):

RejectedDueToCooldownOrEndurance (3) is the market mechanism that enforces the endurance constraint — a resource that has already been activated and is in its cooldown period will have subsequent offers rejected automatically.

Market zone configuration

GET /api/grid/zone reveals per-zone configuration fields that determine market rules:

The allowFlexibilityTransactionReferenceReadings per-zone toggle explains why the “Egen referensplan” (FSP-uploaded baseline) may be enabled in some markets but not others — the DSO configures this per zone.

DSO decision support: cross-organization impact view

GET /api/product/transaction/flexibility/affecting/substation/{substationId} (feature: DecisionSupport) returns all flexibility transactions affecting a specific substation regardless of which FSP organization they belong to, including quantityAfterImpact and impact (impact factor) per transaction. This endpoint enables the flex tool operator view — the DSO sees the net effect of all cleared trades at the constrained point, not just their own organization’s procurement.

GetFlexibilityTransactions (feature: Grid) returns the caller’s own transactions plus otherFlexibilityTransactionsWithImpact — other organizations’ transactions that affect the same substation. Both views are confirmed in the API.

Authentication and access control

Client credentials (OAuth2 client_id + secret) via POST /api/identity/client. Two audience types (ClientApplicationAudience enum: 0, 1 — likely FSP vs DSO). Roles are organization-scoped: an aggregator managing resources in a DSO’s market zone is granted Order.Organization.Read/ReadWrite within the DSO’s organization context, plus ResourceManagement feature access.

Relevance to wiki topics