API-användaravtal Sverige

API-användaravtalet i Sverige är ett juridiskt bindande kontrakt som reglerar hur ett företag eller en utvecklare (Användaren) erhåller, nyttjar och hanterar åtkomst till ett programmeringsgränssnitt (Application Programming Interface, API) som tillhandahålls av en leverantör. Avtalet tillämpas i samspel med upphovsrättslagen (1960:729) kap. 1 § 1 — som skyddar API:ets källkod och tekniska arkitektur som upphovsrättsliga verk — avtalslagen (1915:218), dataskyddsförordningen (GDPR, EU 2016/679), och lagen (2022:482) om elektronisk kommunikation.

Ett API (Application Programming Interface) är ett tekniskt gränssnitt som gör det möjligt för externa program och system att kommunicera med och hämta data eller funktioner från en annan tjänst utan att ha tillgång till tjänstens källkod. API:er delas in i tre huvudtyper relevanta för det svenska affärslivet: REST API:er (Representational State Transfer) som kommunicerar via HTTP-protokollet med JSON eller XML som dataformat och är standard vid moderna webbtjänster och mobilappar; SOAP API:er (Simple Object Access Protocol) som används vid äldre enterprise-system och banksystem enligt standarder från SWIFT och Finansinspektionen; GraphQL-API:er som tillåter klienten att specificera exakt vilka data som behövs och är vanliga i moderna e-handelslösningar hos aktörer som Klarna och IKEA.

Den upphovsrättsliga skyddsgrunden för API:er i Sverige fastslogs av EU-domstolen i Oracle v. Google (C-360/13) och SAS Institute v. World Programming Ltd (C-406/10). Avgöranden bekräftade att API-specifikationer och dokumentation kan skyddas av upphovsrätt, men att ren funktionalitet och programmeringsgränssnitt som sådana inte är upphovsrättsskyddade. Svenska domstolar tillämpar upphovsrättslagen (1960:729) kap. 1 § 1 för källkod och kap. 5 § 2 för databaser och sammanställningar. Patent- och marknadsdomstolen (PMD) hanterar upphovsrättstvister rörande programvara i Sverige.

API-användaravtalet Sverige definierar fyra centrala tekniska och juridiska dimensioner: för det första API-nyckelhantering (autentisering via Bearer Token, OAuth 2.0 eller API-nyckel; ansvar för säker lagring; rapporteringsskyldighet vid komprometterad nyckel); för det andra rate limiting (anropsbegränsningar per sekund, minut och dygn; automatisk throttling vid överskridande; möjlighet till uppgradering av anropsvolym mot tilläggsavgift); för det tredje databehandling (GDPR-compliance om API:et returnerar personuppgifter; DPA-krav per GDPR art. 28; IMY:s tillsyn via dataskyddslagen 2018:218); för det fjärde immaterialrättslig licens (nyttjanderätt till API:et och dess data; förbud mot vidareförsäljning; tillåten derivatanvändning och OEM-integration).

EU Data Act (Europaparlamentets och rådets förordning 2023/2854 om rättvisa regler för tillgång till och användning av data) träder i tillämpning etappsvis från 2025 och 2026. Data Act ålägger tillverkare av uppkopplade produkter (IoT) och leverantörer av relaterade tjänster att på begäran göra data tillgänglig för slutanvändare och tredje parter via standardiserade API:er. Svenska leverantörer av IoT-plattformar, fordonsdataplattformar och industriella styr-API:er berörs direkt. API-användaravtal upprättade efter 2025 bör inkludera Data Act-klausul om FAIR-data-skyldighet (Findable, Accessible, Interoperable, Reusable) och portabilitetsrätten per Data Act art. 4-5.

API-användaravtal Sverige aktualiseras i alla situationer där en part licensierar åtkomst till ett programmeringsgränssnitt mot ersättning eller som del av en affärsrelation. Nedan följer sex typiska scenarier.

Betalnings- och fintech-API:er. Banker (Swedbank, SEB, Nordea, Handelsbanken), betaltjänstleverantörer (Klarna, Swish, iZettle/Zettle) och fintech-bolag exponerar betalnings-API:er för externa handlare, applikationsutvecklare och partners. PSD2-direktivet (EU 2015/2366), implementerat i Sverige via betaltjänstlagen (2010:751), kräver att kontoförande betaltjänstleverantörer (ASPSPs) tillhandahåller öppna API:er till tredjepartsbetalningsinitieringstjänster (PISPs) och kontoinformationstjänster (AISPs). Finansinspektionens föreskrifter (FFFS) reglerar säkerhetskraven för API-åtkomst i betalsektorn. API-användaravtal med finansiella aktörer kräver: PSD2-SCA-compliance (Strong Customer Authentication), Finansinspektionens godkännande av tredjepartsleverantören, och incidentrapportering per DORA (EU 2022/2554).

Kartografi- och geospatial-API:er. Lantmäteriet, Trafikverket och kommuner tillhandahåller geodata-API:er till privata aktörer. Kommersiella geodataleverantörer (HERE Technologies, Google Maps Platform, Mapbox) licensierar kartografi-API:er till svenska applikationsutvecklare, taxibolag (Taxi Stockholm, Bolt, Uber), och logistikaktörer (DHL, PostNord, Instabox). API-användaravtal för kartdata specificerar tillåten användning (intern produkt, extern tjänst, OEM-integration), cacheförbud (Google Maps API tillåter inte caching av karttiles), och attribution-krav ("Powered by Google", "© OpenStreetMap contributors").

Hälso- och sjukvårds-API:er. Inera AB (ägd av Sveriges regioner och kommuner) driver nationella hälso-API:er: National Patient Summary (NPS) API, Pascal (läkemedelsförteckning) API, och Journalen API (1177 Vårdguiden). Privata journalsystemleverantörer (Cambio Healthcare, TietoEVRY Healthcare, CGI) exponerar API:er mot regionernas vårdinformationsplattformar. API-användaravtal i hälsovård kräver: Socialstyrelsens och Inspektionen för vård och omsorg (IVO) regeltillstånd; GDPR art. 9-grund för känsliga hälsodata; auditloggning per patientdatalagen (2008:355) § 4 kap. 4; och Ineras certifieringsprocess för nationella system.

LoT- och industri-API:er. Tillverkningsföretag (ABB, Atlas Copco, Sandvik, SKF) och energibolag (Vattenfall, E.ON, Fortum) exponerar industriella IoT-API:er för konditionsövervakning, prediktivt underhåll och energioptimering. EU Data Act (2023/2854) kräver att IoT-produkttillverkare från 2025 tillhandahåller standardiserade API:er för dataportabilitet. API-användaravtal för industri-IoT specificerar dataformat (OPC UA, MQTT, REST/JSON), realtidskrav (latenskrav under 100ms för kritiska sensorer), och NIS 2-säkerhetskrav per cybersäkerhetslagen (2023).

E-handels- och marknadsplats-API:er. E-handelsplattformar (Shopify, WooCommerce, Magento, Centra) exponerar API:er till svenska webbyrå- och applikationsutvecklare. Marknadsplatser (Amazon Marketplace, Zalando Partner Program, Cdon API) kräver API-användaravtal för integrationspartners. EU:s e-handelsdirektiv och DSA (Digital Services Act, EU 2022/2065) reglerar API-baserade rekommendationssystem och annonsering på marknadsplatser. API-användaravtal specificerar tillåten produktkatalogintegrering, prissättningsautomation (repricers), och dataanvändning för maskinlärning.

Publika developer-API:er och open data. Myndigheter och offentliga bolag publicerar öppna API:er: Statistiska Centralbyrån (SCB) — statistik-API, Riksdagen — riksdagsdata-API, Naturvårdsverket — miljödata-API, Trafikverket — trafikdata-API (öppen trafik). Öppna API:er regleras ofta av Creative Commons-licenser (CC BY 4.0) eller PSI-direktivet (EU 2019/1024, implementerat i lagen 2022:818 om den offentliga sektorns tillgängliggörande av data). API-användaravtal för offentliga data specificerar attribution-krav, förbjuden kommersiell vidareutnyttning utan särskilt tillstånd, och tillgänglighetsgarantier (SLA).

Ett välformulerat API-användaravtal Sverige innehåller följande element för att säkerställa teknisk precision, juridisk rättssäkerhet och GDPR-compliance.

Exakt definition av API:et och tillåten användning. Produktnamn, version och versioneringspolicy (semver-standard: major.minor.patch; breaking changes kräver 90 dagars förvarning). Detaljerad endpoints-lista med HTTP-metoder (GET, POST, PUT, DELETE, PATCH) och dataformat (JSON, XML, Protocol Buffers). Tillåten användning (intern produktutveckling, kommersiell integration, OEM-integration, research) och förbjuden användning (vidareförsäljning av rådata, konkurrensprodukt, scraping). Upphovsrättslig äganderätt per upphovsrättslagen (1960:729): Leverantören äger API:ets källkod och arkitektur; Användaren får begränsad nyttjanderätt.

API-nyckelhantering och autentisering. Utfärdande av unik API-nyckel eller OAuth 2.0-token per Användare. Användarens skyldigheter: säker lagring (miljövariabler, vault, ej hårdkodad i källkod eller Github-repo), kryptering vid transport (TLS 1.3), RBAC för interna system som anropar API:et. Rapporteringsskyldighet vid misstänkt komprometterad nyckel med Leverantörens 2-timmars responstid för återkallning och ny nyckelutfärdning. Förbud mot delning av API-nyckel med tredje part. Automatisk nyckelrotation (valfritt, vid enterprise-avtal).

Rate limits och SLA. Specificerade anropsbegränsningar per sekund (burst rate), per minut (sustained rate) och per dygn (daily quota). Mechanismen för rate limiting: HTTP 429 Too Many Requests med Retry-After header; exponential backoff-krav för Användaren. Servicenivå: tillgänglighetsgaranti för API:et (uptime, t.ex. 99,9 % exkl. planerat underhåll). Servicekredit vid SLA-brott. Eskalationsmekanismer för enterprise-kunder som behöver ökad volym. Se även forms-legal.com för separata SaaS-avtal och molntjänsteavtalsmallar.

Dataskydd och GDPR-compliance. Klarläggande av om API:et returnerar personuppgifter (GDPR-tillämpning) eller enbart aggregerad/anonymiserad data. Vid personuppgifter: DPA-bilaga per GDPR art. 28 med databehandlingens ändamål, kategorier av personuppgifter, säkerhetsåtgärder och subprocessorer. Användarens ansvar för rättslig grund per GDPR art. 6 (samtycke, berättigat intresse, avtal) vid behandling av API-returnerade personuppgifter. Leverantörens säkerhetsåtgärder: TLS 1.3, AES-256, logglagring 12 månader, pseudonymisering i testmiljö. Incidentrapportering: Leverantörens 24-timmarsnotis till Användaren; Användarens 72-timmarsanmälan till IMY per GDPR art. 33.

NIS 2 och cybersäkerhetskrav. API-leverantörer som är väsentliga eller viktiga entiteter per cybersäkerhetslagen (2023) ska: registreras hos MSB; ha dokumenterat riskhanteringssystem per NIS 2 art. 21; rapportera signifikanta incidenter till MSB inom 24 timmar; och ha penetrationstestning minst 1 gång per år. API-Användare inom reglerade sektorer (bank, energi, transport, hälsovård) ansvarar för att deras integration med leverantörens API uppfyller NIS 2-krav på sin egen verksamhet.

Versionshantering och API-avveckling (deprecation). Leverantörens skyldigheter vid API-version lifecycle: migrationsvarning (minimum 90 dagar för breaking changes, 30 dagar för non-breaking deprecations), tillhandahållande av migrationsvägledning och changelog, stöd för föregående major version under minst 12 månader efter release av ny major version. Utan tydlig deprecation-policy kan API-avveckling orsaka oavsedda driftstörningar i Användarens produkter.

Ansvarsbegränsning och felaktig data. Leverantörens ansvar för API-avbrott, felaktiga data och driftstörningar begränsas till avgifter under de senaste 12 månaderna eller det belopp som ansvarsförsäkringen täcker. Ingen part ansvarar för indirekt skada. Undantag: GDPR-böter, personskada och grov vårdslöshet. Leverantörens garanti: API returnerar data i enlighet med specifikationen; avvikelser rapporteras via ärendehanteringssystem.

Avtalstid, uppsägning och följder. Avtalets löptid och uppsägningstid. Leverantörens rätt till omedelbar avstängning vid missbruk: kringgående av rate limits, förbjuden vidareförsäljning, intrång i Leverantörens infrastruktur, GDPR-brott. Åtgärder vid avtalets upphörande: omedelbar återkallning av API-nyckel; Användarens skyldighet att radera cachad API-data inom 30 dagar; bevarandeskyldighet för revisionsspår per dataskyddslagen (2018:218).

API-användaravtalet Sverige upprättas i följande steg för att säkerställa teknisk precision och juridisk rättssäkerhet.

Steg 1 — Identifiera parterna korrekt. Leverantören: firmanamn, organisationsnummer (XXXXXX-XXXX), adress och behörig firmatecknare med namn och befattning. Användaren: firmanamn och organisationsnummer. Kontrollera att Användarens organisation är en juridisk person (AB, HB, enskild firma) med rätt att ingå avtal; vid enskild firma gäller avtal personligen för innehavaren.

Steg 2 — Specificera API:et tekniskt. Ange exakt produktnamn, version (med semver-standard) och referens till teknisk dokumentation (URL eller bifogat dokument). Lista de endpoints som ingår i avtalet (ej enbart 'REST API' utan konkreta resurser som /users, /orders, /products). Ange dataformat (JSON, XML, Protocol Buffers) och autentiseringsmetod (API-nyckel, OAuth 2.0 Bearer Token, JWT). Beskriv tillåten användning konkret: vad Användaren får göra med API:et och vad som är otillåtet.

Steg 3 — Definiera rate limits och SLA. Ange anropsbegränsningar i tre nivåer: burst (per sekund), sustained (per minut) och daglig kvot (per dygn). Specificera HTTP-statuskoden vid överskridande (429 Too Many Requests) och Retry-After header. Ange SLA-nivå (t.ex. 99,9% uptime) och servicekredit vid brott. Inkludera eskalationsprocess för Användare som behöver tillfälligt ökad volym (exception request-process).

Steg 4 — Bedöm GDPR-skyldigheter. Avgör om API:et returnerar personuppgifter: om ja, ska DPA-bilaga per GDPR art. 28 upprättas med kategorier av personuppgifter, behandlingsändamål, lagringstider, subprocessorer, och säkerhetsåtgärder. Om nej (enbart aggregerad/anonymiserad data), ange detta uttryckligen i avtalet för att undvika tvivel. Kontrollera IMY:s vägledning för API-baserad personuppgiftsbehandling (publicerad 2023).

Steg 5 — Välj avgiftsmodell och betalningsvillkor. Välj bland: gratis (developer tier utan SLA-garanti), fast månadsavgift, förbrukningsbaserad (per 1 000 anrop) eller hybrid (basavgift + förbrukningsbaserad del). Ange konkreta belopp exkl. moms (25 % mervärdesskatt tillkommer). Specificera faktureringsperiod och fakturaformat. Vid förbrukningsbaserad prissättning: kräv att Leverantören tillhandahåller realtidsdashboard över förbrukning och utfärdar e-postavisering vid 80 % av avtalad kvot.

Steg 6 — Reglera API-nyckelhantering och säkerhet. Ange Leverantörens skyldighet att utfärda unik API-nyckel och Användarens skyldighet att förvara den säkert (miljövariabler, lösenordsvalv, ej i Github). Inkludera rapporteringsskyldighet vid misstänkt komprometterad nyckel och Leverantörens 2-timmars responstid. Specificera om nyckelrotation är obligatorisk (t.ex. varannan år) och hur ny nyckel distribueras säkert.

Steg 7 — Bestäm versioneringspolicy och deprecation-process. Specificera Leverantörens skyldigheter vid version lifecycle: 90 dagars varsel för breaking changes (ny major version), 30 dagars varsel för non-breaking deprecations, och stöd för föregående major version under minst 12 månader. Utan tydlig policy kan API-avveckling orsaka oväntade driftstörningar i Användarens produkter.

Steg 8 — Underteckna med behörig firmatecknare. Undertecknande i två likalydande exemplar (fysiska underskrifter eller kvalificerad elektronisk signatur per eIDAS-förordningen EU 910/2014). Kontrollera att behörig firmatecknare har rätt att underteckna avtal av detta slag; saknas firmateckningsrätt är avtalet inte bindande för bolaget. Spara det undertecknade avtalet digitalt med versionshistorik och lägg till påminnelse för avtalets förlängningsdatum.

API-användaravtal Sverige regleras av ett komplext samspel av upphovsrätt, dataskyddsrätt, tekniklagstiftning och allmän avtalsrätt.

Upphovsrättslagen (1960:729). API:ets källkod skyddas som ett upphovsrättsligt verk per upphovsrättslagen kap. 1 § 1 ('framställning av litterära och konstnärliga verk, dit hänföres... datorprogram'). EU-domstolens avgöranden i SAS Institute v. World Programming (C-406/10) och Oracle v. Google (C-360/13) klargjorde att ren API-funktionalitet och gränssnittsbeskrivningar inte är upphovsrättsskyddade, men att källkod, databaser och dokumentation är skyddade. Datorprogram skyddas under ett normalskydd på upphovsmannens livstid plus 70 år per upphovsrättslagen kap. 7 § 43; programmen erhöll europeisk harmonisering via direktiv 2009/24/EG om rättsligt skydd för datorprogram. Patent- och marknadsdomstolen (PMD) vid Stockholms tingsrätt är exklusiv forumdomstol för upphovsrättstvister rörande programvara i Sverige.

AVtalslagen (1915:218) och nyttjanderättsliga principer. API-licensen är en nyttjanderätt med begränsat omfång; avtal om nyttjanderätt av upphovsrättsliga verk tolkas restriktivt — rättigheter som inte uttryckligen överlåtits anses inte ingå (specialitetsprincipen per upphovsrättslagen kap. 3 § 29). Avtalets bindande verkan kräver partsbehörighet, uttrycklig accept (ej ensidig click-through för kommersiella B2B-avtal utan förhandling) och lagligt ändamål. Otillbörliga avtal om ansvarsbegränsning kan jämkas per avtalslagen § 36.

Dataskyddsförordningen (GDPR, EU 2016/679) och dataskyddslagen (2018:218). Vid API-behandling av personuppgifter: Leverantören är personuppgiftsansvarig för data i sin plattform; Användaren är personuppgiftsansvarig för behandling av API-returnerade data i sina egna system; vid instruktionsbaserad behandling av personuppgifter på Kundens vägnar gäller Leverantören som personuppgiftsbiträde per GDPR art. 4(8) — DPA krävs per art. 28. IMY har utfärdat vägledning 2022-2023 för molntjänst- och API-leverantörers GDPR-compliance. GDPR art. 35 (DPIA) är obligatorisk om API-behandling innebär 'hög risk' för registrerade (automatiserade beslut, känsliga uppgifter, storskalig behandling).

EU Data Act (Förordning 2023/2854). EU Data Act, som träder i kraft etappsvis 2025-2027, ger användare (konsumenter och företag) rätt att begära tillgång till data genererad av uppkopplade produkter via standardiserade API:er. Tillverkare av IoT-produkter och leverantörer av relaterade datatjänster är skyldiga att 'by design' möjliggöra dataportabilitet per API. Data Act kap. IV reglerar molntjänstbyte och portabilitet. Exklusiva dataavtal som förhindrar portabilitet kan vara ogiltiga per Data Act art. 6(2). Svenska leverantörer av IoT-plattformar, fordons-API:er, smarta hem-API:er och industrial IoT är direkt berörda.

Cybersäkerhetslagen (2023) och NIS 2-direktivet (EU 2022/2555). API-leverantörer som är väsentliga entiteter (energi, transport, bank, hälsovård, offentlig förvaltning) eller viktiga entiteter (digitala tjänster, molntjänster) per NIS 2-direktivet är skyldiga att registrera sig hos MSB och implementera riskhanteringssystem, incidentrapportering och tekniska säkerhetsåtgärder. API-säkerhetsstandarden OWASP API Security Top 10 (2023-version) är de facto-standard för API-säkerhetsriskhantering per NIS 2 art. 21 och rekommenderas av ENISA (Europeiska unionens cybersäkerhetsbyrå). MSB kan ålägga böter upp till 10 miljoner EUR för essentiella entiteter vid NIS 2-brott.

Lag (2022:482) om elektronisk kommunikation. API-kommunikation via elektroniska kommunikationsnät regleras av lagen (2022:482) om elektronisk kommunikation som implementerar EU:s elektroniska kommunikationskodex (EU 2018/1972). Leverantörer av API:er som tillhandahåller interpersonell kommunikation (messaging, voice, video via API) klassificeras som elektroniska kommunikationstjänster och regleras av PTS (Post- och telestyrelsen). API-avtal ska inkludera information om databehandling per lagen (2022:482) § 9 kap.

Betaltjänstlagen (2010:751) och PSD2. API-leverantörer som tillhandahåller betalnings-API:er (Payment Initiation Service, Account Information Service) regleras av betaltjänstlagen (2010:751) som implementerar PSD2 (EU 2015/2366). Finansinspektionen utövar tillsyn; tredjepartsleverantörer (PISPs/AISPs) kräver Finansinspektionens tillstånd per betaltjänstlagen kap. 2 § 1. DORA (EU 2022/2554) kräver från januari 2025 att finansiella aktörers API-leverantörsavtal inkluderar revisionsrätt och exitplan.

Följande misstag begås ofta vid upprättande av API-användaravtal i Sverige och kan leda till upphovsrättstvister, GDPR-sanktioner och driftstörningar.

Misstag 1 — API-nyckel hårdkodad i källkod. Vanligaste säkerhetsmisstaket är att Användaren hårdkodar API-nyckeln i applikationens källkod och laddar upp den till ett publikt Github-repository. Skanningsbottar identifierar exponerade nycklar inom minuter och kan missbruka dem för obehöriga anrop (kostnad för Användaren: faktura för tiotusentals anrop; GDPR-risk om API returnerar personuppgifter). Korrekt: lagring i miljövariabler (.env-fil utanför versionskontroll), lösenordsvalv (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), och automatisk skanning av Github-repos med GitHub Secret Scanning.

Misstag 2 — Otydlig tillåten användning leder till licensbrott. API-användaravtal som enbart anger att API:et får användas för 'produktutveckling' utan konkret definition av förbjuden användning (vidareförsäljning av rådata, scraping, konkurrenstjänst) skapar tolkningsutrymme som Användaren kan utnyttja. Korrekt: explicit definition av tillåten och förbjuden användning med konkreta exempel; inkludera förbud mot: (a) vidareförsäljning av API-data till tredje part, (b) användning för att bygga konkurrensprodukt, (c) kringgående av rate limits via proxy-servrar.

Misstag 3 — Ingen DPA-bilaga vid API:er som returnerar personuppgifter. API:er som returnerar personuppgifter (namn, e-postadresser, personnummer, IP-adresser, platsinformation) kräver DPA-bilaga per GDPR art. 28. Avtal utan DPA-bilaga exponerar båda parter för IMY-sanktioner; IMY har utdelat böter till svenska företag för avsaknad av DPA per GDPR art. 83(4) (max 10 miljoner EUR eller 2 % av global omsättning). Korrekt: utred om API-svaren inkluderar personuppgifter (kontrollera datakatalog och API-dokumentation); upprättas DPA-bilaga om ja.

Misstag 4 — Ingen versioneringspolicy och plötsliga breaking changes. Leverantörer som ändrar API:ets gränssnitt (breaking changes) utan tillräcklig varselperiod orsakar oavsedda driftstörningar i Användarens produkter. I värsta fall innebär avsaknad av varsel att Användaren inte hinner genomföra nödvändig migration och förlorar åtkomst helt. Korrekt: dokumentera versioneringspolicy i avtalet; minimum 90 dagars varsel för breaking changes (ny major version) och 30 dagars varsel för non-breaking deprecations; stöd för föregående major version under minst 12 månader.

Misstag 5 — Förbrukningsbaserad prissättning utan kostnadstak. API-avtal med förbrukningsbaserad prissättning (per anrop) utan avtalat kostnadstak och utan e-postavisering vid budgetöverskridande kan leda till 'API bill shock' — Användaren tar emot fakturor på tiotusentals SEK för oförutsett höga anropsvolymer (orsakade av buggar i Användarens kod, DDoS-attack, eller oavsiktlig loop). Korrekt: avtalat kostnadstak med Leverantörens skyldighet att begränsa anrop vid taket; e-postavisering vid 80 % av månadsbudgeten; krav på Leverantörens godkännande för fakturering utöver taket.

Misstag 6 — Brott mot EU Data Act vid IoT-API:er. Leverantörer av IoT-plattformar och uppkopplade produkter som från 2025 är skyldiga att tillhandahålla standardiserade dataportabilitets-API:er per EU Data Act (2023/2854) men underlåter att göra det riskerar EU-kommissionens tillsynsåtgärder och nationell tillsyn. Korrekt: kontrollera om produkten eller tjänsten faller under Data Acts tillämpningsområde (art. 2) och inkludera FAIR-dataportabilitetsklausul i API-användaravtalet.