SWITCH API Swagger v3.14 Full (2026)

Reference: OpenAPI 3.0.4 specification for the SWITCH platform, version 3.14.0.0 — the full platform API: 157 paths, 288 schemas, 27 tag groups.

Access: openly reachable at the development/staging host dev-api.switchmarket.se but not linked from the official SWITCH documentation. No authentication was used and no endpoint was called; this documents the published contract only.

Relationship to the earlier source: Source - SWITCH API Swagger v3.13 (2026) covers the FSP-facing subset — 25 endpoints across seven tag groups (Identity, Meter, Product, Reading, Resource, User, Zone). This spec is the same platform’s complete surface, roughly 6× larger. The v3.13 page remains valid; it is already unusually thorough: the product-type LFM mapping, excludedPeriods as an FCR-conflict tool, endurance/cooldown ranges, the HighXofY baseline, per-zone hourly/quarterly resolution, the clearing-rejection taxonomy, CancelledByCounterpart, the cross-organization substation impact view and the modular feature tiers are all documented there, not here. This page covers only what the full surface adds.

Why it matters: the platform’s full data model — administration, automation, and grid/impact structures — is documented nowhere else in the wiki.

Tag groups

Alarm · Application · AuditEvent · AutomatedTrading · Baselining · Cache · Dashboard · Entitlements · Identity · Impact · Kpi · Market · Me · Meter · Organization · Product (44 ops) · Qliksense · Reading · Reports · Resource · Role · Subscription · Substation · Support · User · Vtn · Zone

Findings new to this source

Everything below is absent from the v3.13 page and from SWITCH’s user-facing documentation.

Automated trading — an uncredited capability

A full tag group (10 endpoints) for DSO-side automation, configurable per market:

• Automated purchasing options: triggerType (Daily/Hourly), trigger time/minute, timezone, automatedPurchasingType (IntraDay / DayAhead / IntraDayAndDayAhead / RollingWindow), rolling-window start/end offsets in minutes, and per-substation order-recommendation options.
• Automated availability order creation options: the same pattern for availability orders.
• KPI tracking of automated events — per substation, per time slot, per reading, including forecast and actual overruns.

OrderRecommendationSubstationOptionsRequest.remainingDemandPenalty encodes a willingness-to-pay ceiling: “The cost for remaining (unsatisfied) demand. Flexibility will not be bought when it is cheaper to keep the demand.”

This is significant against the EC/academic finding that manual activation is one of the top five European LFM barriers. No comparable automation surface appears in the NODES spec.

Resource qualification is a five-state workflow

ResourceQualificationStatus: New → Amended → Approved / Rejected / ChangesRequested, with dedicated ApproveResourceQualificationRequest, RejectResourceQualificationRequest and RequestChangesForResourceQualificationRequest operations plus a qualification message thread (ResourceQualificationMessageResponse).

The qualification record carries endurance, cooldown, isAggregate, type (Consuming/Producing), regulationType (Up/Down), referenceType (None / OperationsPlan / ZeroReference / MBMA), allowedProducts, pods, and both organizationId and managedByOrganizationId — i.e. an organization can manage another organization’s resource, the aggregator-delegation pattern.

This is more expressive than NODES’ requirement/submission pair with a boolean accepted flag.

Multi-tenancy is administered, not just modelled

The v3.13 page documented per-zone configuration fields. What is new here is the CRUD surface around them: create/update/delete for markets (/api/trading/market), market zones (/api/grid/zone) and substations (/api/grid/substation), plus MarketZoneParticipationResponse.managerOrganizationIds, organization roles with role templates, per-organization feature flags, settings bags and announcements, and a system-wide entitlements/snapshot.

The distinction matters for the multi-DSO question: zone-level configuration fields show the platform can express different market rules; administrative CRUD plus manager-organization lists show it is built to have those markets provisioned and operated by different organizations.

Baseline definitions are configurable objects with scheduled generation

POST /api/baselining creates a baseline definition binding a source register to a target register with a BaselineType (Default / HighXofY / MBMA), a timezone and a time-of-day trigger for value generation. The v3.13 page established that HighXofY exists as an algorithm; this shows baselines are configurable, schedulable objects with their own lifecycle, not a per-resource flag.

Baseline methodology is a named NC DR national T&C domain.

Settlement outputs, but not settlement configuration

Delivery thresholds and penalties appear only as computed outputs — deliveryPercentage, ordersBelowThreshold, remunerationPenalty on transaction and settlement responses. No configurable threshold, penalty curve or remuneration formula is exposed. The 75%-threshold-then-linear rule and the ME availability formula are platform logic.

SettlementSpecificationResponse is a report (organization, period, isFinalizedPeriod, bought/sold counterparts) rather than a configuration object.

Grid model: zone → substation, plus a cross-substation impact model

• Substation with subscriptions (SubstationSubscriptionType: Annual / Temporary, with value and period) and operation deviations (PlannedMaintenance / Other).
• Impact as a first-class entity: /api/grid/impact with sourceResourceId → targetSubstationId and a value array; retrievable per resource and per market zone. The impact-factor (PTDF) treatment documented on SWITCH › 1. Market tool is configurable data, not a constant.
• GET /api/product/transaction/flexibility/affecting/substation/{substationId} — transactions affecting a given substation, i.e. cross-substation effect tracking.
• Substation breaches and breach detection suspensions (creatable, cancellable).

Cancellation reason codes

Cancellation operations span availability orders, availability schedule orders and flexibility transactions, each with typed reasons: OrderManualCancellationType = ClearingCancelledDueToChangedNeed / ClearingCancelledDueToTechnicalError, and OrderClearingStatus distinguishing NotCleared / Cleared / ClearingCancelled / …DueToMissingOffers / …DueToPrice.

Relevance to wiki

Data gaps

• How LfmA/LfmD/LfmP map to Ei’s approved LFM-h/p/e, and whether the internal migration preserved the compensation-model semantics (Model A/B)