API
REST-API utan nyckel, fritt för privat bruk (kommersiell användning kräver avtal, se villkoren). De flesta endpoints är GET och cachebara; egen driftdata laddas upp/raderas via POST respektive DELETE. Anrop som rör en sparad anläggning autentiseras med Authorization: Bearer <profile_token> – lägg aldrig token i URL:en, den hamnar i loggar och webbläsarhistorik. Maskinläsbar OpenAPI-specifikation finns på /api/v1/openapi.json, med scheman, felkoder och exempel per endpoint (engelsk version). Prissvaren innehåller ettsource-fält med attribution.
| Endpoint | Beskrivning |
|---|---|
GET /api/v1/prices/now?zone= | Pris nu + idag + imorgon för en zon. |
GET /api/v1/prices?zone=&from=&to=&resolution=15m|1h|1d|1mo&unit=ore|eur&vat= | Historiska priser, valfri upplösning och enhet. |
GET /api/v1/stats/compare?zone=&a_from=&a_to=&b_from=&b_to= | Jämför två perioder. |
GET /api/v1/stats/records?zone= | Rekord: dyraste/billigaste timmar och dygn. |
GET /api/v1/simulate/household?zone=&mode=decision|history&pv_kwp=&load_annual=&has_battery=&kwh=&kw=&capex_battery=&capex_solar=&purchase_date=&future_price_factor=&profile_token= | Hushållsekonomi: IRR, payback och värdedekomponering för sol + batteri. future_price_factor skalar projektionens framtida elprisnivå (Låg/Mellan/Hög-scenario). Varm cache → 200 direkt; kall → 202 (status: processing, warm.config_key) → polla /warm/by-config och hämta om. |
GET /api/v1/ancillary/{market}?zone=&from=&to= | Stödtjänstdata (market = afrr | mfrr | fcr). |
GET /api/v1/quality | Källfördelning och senaste ingest-körningarna. |
POST /api/v1/grade | Ladda upp batteridrift (CSV, minst 7 dygn) → köar optimeringsbetyget och svarar 202 med profile_token; en bakgrundsworker räknar och resultatet hämtas via GET /warm/{token}. 7-29 dygn ger ett PRELIMINÄRT betyg (payload-flaggan preliminary: true - kort fönster, kan svänga; bidrar inte till peer-korpusen och öppnar ingen ekonomi förrän 30 dygn). Tar även anläggning (pv_kwp, styrsystem) och ekonomi (inköp, inkl. split sol/batteri). Ett anonymt betyg (siffra + elområde, ej identifierbart) sparas alltid för jämförelsen; share_profile delar full profil (opt-in) och ger en raderingsbar token. sensor_ids + dedup matchar en befintlig anläggning; att ERSÄTTA den kräver innehavsbevis (dedup_token = radens egen profil-token, eller en inloggad session som äger den) - utan bevis skapas en ny rad, eftersom fingeravtrycket härleds ur klientens egna sensornamn och därför inte bevisar ägarskap. Samma bevisregel gäller identisk data: en uppladdning med samma data_fingerprint som en befintlig rad uppdaterar den bara med bevis, annars ny rad. Integrationsanläggningar (Sonnen/Reduxi/HA-strömmade) ersätts aldrig via uppladdning. Accepterar även profile_token (sparad profil) i stället för fil – då räknas betyget på den lagrade datan utan ny uppladdning. Valideringsfel ges synkront (422). |
GET /api/v1/warm | Status för en köad betygsberäkning (status: pending|running|done|error, step, steps_done/steps_total). När steg 1 är klart ingår betyg-objektet (samma form som tidigare grade-svar, utan stored/delete_token/warnings). |
GET /api/v1/warm/by-config/{config_key} | Status för en köad fristående beräkning (hushållssim/sizing utan token). Pollas tills done, varefter ursprungsanropet hämtas om (200). |
POST /api/v1/sizing | Optimal batteristorlek mot egen driftprofil: NPV, IRR och payback per storlek – både nytt batteri och marginell utökning från nuvarande. Tar fil eller profile_token (sparad profil). Kall väg svarar 202 (status: processing, warm.config_key) → polla /warm/by-config och posta om när varm. |
GET /api/v1/calibration/summary | Aggregat över uppladdade anläggningar: prisstyrd-faktor (median, p25/p75) samt ett betyg-block (median + max över optimeringsbetyget, holistic_score) för peer-jämförelse. total_plants är antalet anläggningar med accepterad data (dedupat, även de utan betyg) - talet som svarar på hur många som är med. Samtliga n-fält är däremot EFFEKTIV stickprovsstorlek (Kish, (Σw)²/Σw²) på den VIKTADE korpusen, inte ett radantal: en partnerflotta viktas ned som helhet, så n kan vara långt lägre än antalet anläggningar bakom siffran. Segmenten (by_zone, by_control_system) utelämnas helt när deras effektiva n understiger 5. |
POST /api/v1/grade/check-plant | Finns redan en sparad profil för anläggningen (saltat fingeravtryck av valda sensorer + zon)? Svarar {match, can_update}. can_update säger om ANROPAREN får ersätta raden (innehavsbevis: dedup_token i bodyn, eller inloggad session som äger den) - matchningen i sig ger ingen skrivrätt, och en integrationsanläggning är aldrig uppdaterbar via uppladdning (can_update: false även med bevis). POST just för att beviset aldrig ska hamna i en query-sträng. |
POST /api/v1/profile | Skapa en anläggning för löpande uppladdning. Obligatoriskt: zone, battery_kwh, battery_kw (båda måste vara > 0 – vägen kräver batteri). Valfritt: eff (default 0,9), has_solar (default false), pris/datum, egen tariff, reservgolv. Svarar 201 med profile_token (plus account_linked). Token:et är nyckeln till anläggningen: skicka det som Authorization: Bearer på anropen nedan. Samma väg som Home Assistant-integrationen använder. |
PUT /api/v1/profile/data | Fyll på driftdata löpande: {rows: [...]}. Varje rad kräver ts (tidsstämpel MED tidszon – naiv tidsstämpel ger 422 för hela batchen), batt_charged_kwh och batt_discharged_kwh. solar_kwh, grid_import_kwh och grid_export_kwh är valfria men DEFAULTAR TILL 0 – utelämnar du nätflödena lagras nollor utan felmeddelande och betyget räknas på ett hus som aldrig importerar el. Alla energivärden måste vara 0–500 per rad; en enda rad utanför spannet ger 422 för hela anropet. Batteriflöden fysik-valideras dessutom per klocktimme MOT LAGRAT tillstånd: överstiger timmens summerade laddning eller urladdning batteriets effekt (max av uppmätt och märkeffekt, ×1,5 marginal) nollas timmens batterifält i stället för att batchen nekas – typiskt ett sensorhopp (kumulativ mätare som nollställts). En korrigerad omsändning skriver in riktiga värden igen. Svaret ekar antalet nollade lagrade rader i repaired_battery_rows så klienten kan larma på > 0. UPSERT sker på exakt tidsstämpel (submission_id, ts_utc): att skicka om samma rader är riskfritt, men byter du upplösning (timme → 15-min) eller flyttar tidsstämplarna ligger de gamla raderna kvar och dygnet dubbelräknas – radera profilen och börja om i stället. Max 40 000 rader per anrop (fler ger 422) och 80 000 rader per anläggning totalt (413 över taket, ca 2,3 år 15-min-data). |
POST /api/v1/profile/recompute | Begär omräkning av betyg och ekonomi efter ny data. Svarar 202; en bakgrundsworker räknar. Cooldown 24 h (429 med Retry-After om den redan körts) – en parameterändring via PATCH nollar cooldownen. |
GET /api/v1/profile/results | Hämta senaste resultatet: optimeringsbetyg (inkl. komponentuppdelning och applied_tariff), ekonomi och jobbstatus. Returnerar det som finns cachat. Att decision/history är null betyder inte alltid "inte klart än": ekonomin är SE-only (övriga elområden får betyg men aldrig decision/history) och kräver minst 30 dygns data. Polla alltså inte i väntan på ekonomi utanför SE eller på ett kortare fönster – status kan vara done ändå. |
GET /api/v1/profile | Anläggningsparametrarna för en sparad profil (zon, batteri, sol, styrsystem, inköp inkl. ev. split sol/batteri, egen tariff och reservgolv) plus optimeringsbetyget (holistic_score) – förifyller hub-vyerna i token-läge och Home Assistant-integrationens inställningsformulär. Ingen timdata, ingen PII utöver det användaren själv angav. |
PATCH /api/v1/profile | Uppdatera en sparad profil utan ny uppladdning: ekonomi (inköp), egen tariff (null rensar till landets schablon) och reservgolv är billiga patchar; anläggningsändring (batteri/sol) räknar om betyget på den lagrade driftdatan. Elområdet får rättas om det blev fel vid skapandet, men bara inom samma valuta – beloppen är angivna i zonens valuta och räknas inte om. Ett byte över valutagränsen ger 422 (radera och skapa om anläggningen i stället). En rättelse räknar om betyg och ekonomi mot den nya prisserien. |
POST /api/v1/calibration/compute | Ladda upp egen driftdata (CSV) → personlig prisstyrd-faktor + profil-token. |
DELETE /api/v1/calibration | Radera en uppladdad/delad profil (token från compute eller grade share_profile). |
Enheter: priser lagras i EUR (källans enhet); öre/kWh och moms beräknas vid läsning. Cache-Control: aktuella priser 5 min, historik/simulering 1 dygn. Underlag för analys, inte för drift- eller köpbeslut. Semetodik och villkor. · Interaktiv referens (Scalar) →
Partner-API
Kopplar du batterier åt kunder – som aggregator, installatör eller styrsystemsleverantör – finns ett eget API för hela flottor: mata in timdata löpande och läs tillbaka optimeringsbetyg per anläggning. Registrera dig själv och testa gratis med 10 anläggningar.
Om partner-API:t · Dokumentation
Verktyg
Wolta för Home Assistant (HACS)– integration som laddar upp driftdata och räknar om optimeringsbetyget automatiskt, med betyg och ekonomi som sensorer i HA. Öppen källkod.
export_energy_csv.py– exporterar din Home Assistant-driftdata till uppladdningsformatet som används påoptimeringsbetyget.