API-käyttöehtosopimus Suomi

API-käyttöehtosopimus Suomessa on oikeustoimilain (228/1929) mukainen kirjallinen sopimus, jolla ohjelmistorajapinnan (Application Programming Interface, API) omistaja myöntää toiselle osapuolelle oikeuden käyttää rajapintaa tiettyjen ehtojen mukaisesti. API on ohjelmointirajapinta, jonka avulla eri sovellukset voivat vaihtaa tietoja keskenään standardoitujen kutsujen kautta. Suomessa API-käyttöehtosopimuksen oikeudellinen perusta muodostuu tekijänoikeuslaista (404/1961), oikeustoimilaista (228/1929), tietosuojalaista (1050/2018) ja laista sähköisen viestinnän palveluista (917/2014).

API-käyttöehtosopimus eroaa perinteisestä ohjelmistolisensointisopimuksesta siinä, että API ei ole itsenäinen ohjelmistotuote, jonka käyttäjä asentaa omalle laitteelleen, vaan etäpalvelu, johon kehittäjä lähettää HTTP-kutsuja. Tekijänoikeuslain (404/1961) mukaan API:n taustalla oleva ohjelmistokoodi ja sen dokumentaatio ovat suojattuja teoksia. API-rajapinta voi myös olla suojattu tietokantalain nojalla (direktiivi 96/9/EY, implementoitu tekijänoikeuslakiin). Palveluntarjoaja myöntää käyttöoikeuden ei-yksinomaisena, siirtokelvottomana lisenssikäyttöoikeutena.

APIen luokittelu oikeudellisesti on keskeistä. Julkiset avoimet API:t (open API) voivat olla vapaasti käytettävissä ilman sopimusta, mutta kaupallisissa API:ssa ja erityisesti maksullisissa API:ssa kirjallinen sopimus on välttämätön. Suomessa fintech-sektorilla Euroopan unionin maksupalveludirektiivi (PSD2, EU 2015/2366) velvoittaa pankkeja avaamaan maksurajapintansa kolmansille palveluntarjoajille (TPP). PSD2 edellyttää kirjallista sopimusta ja Finanssivalvonnan rekisteröintiä.

API-käyttöehtosopimuksen olennaisin elementti on käyttötarkoituksen määrittely. Kehittäjä saa oikeuden käyttää rajapintaa ainoastaan sopimuksessa mainittuihin tarkoituksiin. Luvattomat käyttötapaukset, kuten kilpailevan tuotteen rakentaminen Palveluntarjoajan API:n päälle tai API-datan scraping-toiminta, ovat sopimuksen rikkomuksia. Immateriaalioikeus pysyy Palveluntarjoajalla; Kehittäjä saa vain rajoitetun käyttöoikeuden.

Pyyntörajat (rate limits) ovat API-sopimusten tekninen ydinkysymys. Rajoitukset estävät API:n ylikuormittumisen ja takaavat tasapuolisen palvelun kaikille asiakkaille. Tavallisimpia rajoitusmalleja ovat kutsumäärä aikayksikköä kohti (esimerkiksi 1 000 kutsua/tunti), päivittäinen enimmäismäärä tai datan siirtovolyymin raja. Pyyntörajan ylitys johtaa tyypillisesti HTTP 429 (Too Many Requests) -vastaukseen. Sopimuksessa on sovittava selkeästi ylityksen seuraamuksista: automaattinen lisämaksu, palvelun keskeytys vai pelkkä rajoitus.

API-sopimusten tietosuojanäkökulma on korostunut GDPR:n myötä (EU 2016/679, implementoitu tietosuojalakiin 1050/2018). Jos API:n kautta välitetään henkilötietoja, tietosuojalaki ja GDPR tulevat sovellettaviksi. API-toimittaja voi olla joko rekisterinpitäjä tai henkilötietojen käsittelijä, riippuen siitä, kenen lukuun henkilötietoja käsitellään. Yleensä API-toimittaja on käsittelijä ja asiakasyritys rekisterinpitäjä; tällöin GDPR 28 artiklan mukainen tietojenkäsittelysopimus (DPA) on pakollinen liite API-sopimukseen. Tietosuojavaltuutetun toimisto Suomessa valvoo GDPR:n noudattamista.

API-sopimuksen versiointiehto on teknisesti tärkeä. Ohjelmistorajapinnat kehittyvät, ja versiopäivitykset voivat rikkoa kehittäjän olemassa olevat integraatiot (breaking changes). Hyvä sopimus velvoittaa Palveluntarjoajan antamaan ennakkoilmoituksen merkittävistä versiomuutoksista (major version, esimerkiksi v1→v2) vähintään 90 päivää etukäteen ja pitämään vanhan version toiminnassa siirtymäajan. Pienempiä yhteensopivia muutoksia (minor version tai patch) voidaan tehdä lyhyemmällä varoitusajalla.

Kaupallinen hinnoittelumalli API:lle vaihtelee: freemium (rajoitettu ilmainen käyttö + maksulliset paketit), käyttöpohjainen (per API-kutsu tai per GB), kuukausitilaus (kiinteä käyttöraja) tai yrityskohtainen sopimus (enterprise, räätälöity hinta ja rajat). ALV 25,5 % lisätään sopimushintaan arvonlisäverolain (1501/1993) mukaan. Korkolaki (633/1982) määrittelee viivästyskoron maksun myöhästyessä.

API-käyttöehtosopimus Suomessa tarvitaan aina, kun yritys tai kehittäjä käyttää kaupallista ohjelmistorajapintaa tuotannossa tai integroi ulkopuolisen API:n omaan sovellukseensa liiketoimintatarkoituksessa. Seuraavat tilanteet edellyttävät kirjallisen API-sopimuksen laadintaa.

Maksurajapinta (Payment API). Verkkokauppa tai sovellus integroituu maksupalveluntarjoajan API:in (Stripe, PayPal, Checkout Finland, Nets tai Bambora). Sopimus kattaa maksudatan tietosuojan, PSD2-vaatimustenmukaisuuden, pyyntörajat ja vastuunjaon maksutapahtumien virhetilanteissa.

Kartta- ja paikkatietopalvelu. Sovellus käyttää Google Maps API:ia, HERE-palvelua tai Maanmittauslaitoksen avointa paikkatietopalvelua. Vaikka avoimet paikkatietoaineistot ovat lisensoituja Creative Commons -lisenssillä, kaupalliset karttapalvelut edellyttävät sopimussuhdetta.

Pilvipalvelun ohjausrajapinta (Management API). Yritys automatisoi pilvi-infrastruktuuriaan käyttämällä AWS API:ta, Azure REST API:ta tai Google Cloud API:ta. Näissä sopimukset ovat pilvipalveluntarjoajan yleisten sopimusehtojen liitteitä, mutta erilliset sopimusehdot voivat tarkentaa ehtoja.

Fintech- ja pankkiintegraatiot. Taloushallintojärjestelmä (Procountor, Netvisor, Fennoa) integroituu verohallinnon API:in (Tulorekisteri, OmaVero) tai pankin tilitietorajapintaan (Open Banking, PSD2). Kirjallinen sopimus on edellytys.

Tekoäly- ja analytiikkapalvelu. Sovellus käyttää kolmannen osapuolen tekoälyrajapintaa (esimerkiksi OpenAI API, Google Vertex AI tai Hugging Face Inference API). Sopimus kattaa generoidun sisällön immateriaalioikeuden, datan käyttörajoitukset ja mallin käyttöehtojen siirtymisen kehittäjälle.

CRM ja markkinointiautomaatio. Sovellus integroi asiakastietoja Salesforce API:n tai HubSpot API:n kautta. GDPR-velvoitteet tulevat sovellettaviksi, kun asiakkaiden henkilötietoja välitetään rajapinnan kautta.

Sähköposti- ja viestintärajapinta. Sovellus lähettää sähköposteja SendGrid API:n tai Mailgun API:n kautta tai tekstiviestejä Twilio API:n avulla. Laki sähköisen viestinnän palveluista (917/2014) soveltuu sähköiseen viestintään.

Logistiikka- ja toimitusjärjestelmät. Verkkokauppa hakee toimitusstatuksen Postin, DHL:n tai FedExin API:sta. Sopimus kattaa datan käyttöoikeudet, pyyntörajat ja vastuunraon viivästymistapauksissa.

API-käyttöehtosopimus Suomessa sisältää seuraavat oikeudelliset elementit, jotka varmistavat selkeän käyttöoikeuden, tekijänoikeussuojan, pyyntörajat ja tietosuojavelvoitteiden täyttymisen.

Osapuolten yksilöinti. Palveluntarjoajan ja Kehittäjän täydellinen toiminimi, kotipaikka ja Y-tunnus PRH:n kaupparekisteristä. Nimenkirjoitusoikeudelliset edustajat osakeyhtiölain (624/2006) mukaan. Tekninen yhteyshenkilö API-avainhallinnalle ja tietoturvayhteyshenkilö.

Käyttöoikeuden laajuus ja rajoitukset. Ei-yksinomainen, siirtokelvottoman käyttöoikeus tietyn API-version ja tiettyyn käyttötarkoitukseen. Kielletyt toimet: jälleenmyynti, alilisensiointi, kilpailevan palvelun rakentaminen API:n päälle, reverse engineering, data scraping yli sallittujen rajojen. Viittaus tekijänoikeuslakiin (404/1961).

Pyyntörajat ja palvelutaso. Sovittu pyyntöraja (esimerkiksi 1 000 kutsua/tunti, 10 000 kutsua/päivä), ylityksen seuraukset (HTTP 429, automaattinen lisämaksu tai palvelun keskeytys), vasteaikatavoitteet (esimerkiksi p95-latenssitavoite) ja käytettävyyslupaus (uptime SLA). Huoltoikkunat ja niiden ennakkoilmoitusvelvollisuus.

API-avaimen hallinta. Kehittäjä vastaa API-avaimen turvallisesta säilytyksestä, käytön rajoittamisesta omille palvelimille (IP-whitelist) ja välittömästä ilmoituksesta Palveluntarjoajalle avaimen paljastumisesta. API-avain on luottamuksellinen tieto; sen luovuttaminen kolmannelle on sopimuksen olennainen rikkominen.

Versionhallinta ja muutokset. Merkittävistä versiomuutoksista (breaking changes, major version) vähintään 90 päivän ennakkoilmoitus; pienemmistä muutoksista (minor version) 30 päivää. Vanhan version elinkaari (EOL-politiikka) sopimuksen liitteenä. Versionumerointi semanttisen versioinnin (SemVer) mukaisesti.

Hinnoittelu ja laskutus. Perusmaksu ja/tai käyttöpohjainen hinnoittelu ilman arvonlisäveroa; vakio-ALV 25,5 % arvonlisäverolain (1501/1993) mukaan. Laskutusjakso (kuukausittain tai kvartaaleittain), maksuaika (14 päivää netto) ja viivästyskorko korkolain (633/1982) mukaan. Hinnanmuutokset 30 päivää etukäteen. Forms-legal.com suosittelee kirjaamaan sopimukseen käyttöpohjaisen hinnoittelun enimmäislaskutusmäärän (cap) yllättävien kustannusylitysten välttämiseksi.

Tietosuoja. GDPR 28 artiklan mukainen tietojenkäsittelysopimus (DPA) pakollisena liitteenä, jos API:n kautta välitetään henkilötietoja. Tietoturvaloukkauksen ilmoitusvelvollisuus 72 h tietosuojavaltuutetulle (GDPR 33 artikla). Sähköisen viestinnän palveluista annetun lain (917/2014) 307-311 §:n mukainen viestinnän luottamuksellisuus.

Immateriaalioikeudet. API:n tekijänoikeus kuuluu Palveluntarjoajalle (tekijänoikeuslaki 404/1961). Kehittäjän oma sovellus pysyy Kehittäjän omaisuutena. Integraatiokoodi on Kehittäjän tekijänoikeudella suojattu teos. Kolmansien osapuolten kirjastojen lisenssit on huomioitava.

Vastuunrajoitus. Palveluntarjoajan kokonaisvastuu enintään 12 kuukauden käyttömaksuja vastaavaan määrään. Välilliset vahingot poissuljettuja. Kehittäjä vastaa oman sovelluksensa aiheuttamista vahingoista loppukäyttäjille.

Sopimuksen päättyminen. Irtisanomisaika, API-avaimen välitön mitätöinti, data-portabiliteetti ja siirtymäaika.

API-käyttöehtosopimus Suomessa laaditaan seuraavien vaiheiden mukaisesti, jotka varmistavat oikeudellisesti pätevän sopimuksen tekijänoikeuslain (404/1961) ja tietosuojalain (1050/2018) puitteissa.

Vaihe 1 — Tunnista API:n oikeudellinen luonne. Selvitä ennen sopimuksen laadintaa: onko API avoin (open), rekisteröity (key-based) vai kaupallinen; välitetäänkö API:n kautta henkilötietoja (GDPR-velvoite DPA-liitteestä); soveltuuko PSD2 (maksupalveludirektiivi), AI Act tai muu erityislainsäädäntö; onko kyseessä B2B- vai B2C-sopimus (kuluttajansuojalaki 38/1978 soveltuu kuluttajasopimuksiin).

Vaihe 2 — Yksilöi osapuolet. Kirjaa Palveluntarjoajan ja Kehittäjän täydellinen toiminimi, kotipaikka ja Y-tunnus PRH:n kaupparekisteristä. Kirjaa nimenkirjoitusoikeudelliset edustajat. Nimeä tekninen yhteyshenkilö API-avainhallinnolle ja laskutusyhteyshenkilö.

Vaihe 3 — Määrittele käyttöoikeus täsmällisesti. Kirjaa sallittu käyttötarkoitus konkreettisesti (esimerkiksi: „Kehittäjä saa käyttää Maksupalvelu API:ta loppukäyttäjien tilausmaksujen käsittelyyn omalla verkkokauppa-alustallaan”). Listaa kielletyt käyttötapaukset: kilpaileva palvelu, data scraping, API-datan uudelleenmyynti, reverse engineering.

Vaihe 4 — Sovi pyyntörajoista. Kirjaa sovitut pyyntörajat (kutsu/aikayksikkö) ja ylityksen seuraukset. Määrittele, miten käyttömäärää seurataan (Palveluntarjoajan dashboard vai API-lokit) ja miten ylityksistä ilmoitetaan. Sovi enimmäislaskutusmäärästä (billing cap) yllättävien kustannusten välttämiseksi.

Vaihe 5 — Laadi tietojenkäsittelysopimus tarvittaessa. Jos API välittää henkilötietoja, laadi GDPR 28 artiklan mukainen tietojenkäsittelysopimus (DPA) liitteeksi. DPA:ssa on kuvattava käsittelyn tarkoitus, henkilötietotyypit, tekniset ja organisatoriset turvatoimet, alihenkilötietojenkäsittelijöiden lista ja ilmoitusvelvollisuus tietoturvaloukkauksen yhteydessä.

Vaihe 6 — Sovi hinnoittelusta ja laskutuksesta. Kirjaa käyttömaksu ilman arvonlisäveroa (vakio-ALV 25,5 % lisätään). Sovi laskutusjaksosta (kuukausittain tai kvartaaleittain) ja maksuajasta (14 päivää netto). Kirjaa viivästyskorko korkolain (633/1982) mukaan. Sovi mahdollisesta käyttöpohjaisen lisälaskutuksen enimmäismäärästä.

Vaihe 7 — Sovi versioinnista ja muutoksista. Kirjaa Palveluntarjoajan velvollisuus ilmoittaa merkittävistä API-versiomuutoksista vähintään 90 päivää etukäteen ja ylläpitää vanhan version toimintaa siirtymäajan. Sähköpostipohjainen muutosilmoitus on riittävä; lisäksi muutokset kirjataan changelog-dokumenttiin.

Vaihe 8 — Tarkista immateriaalioikeuslausekkeet. Varmista, että sopimus vahvistaa selkeästi: (a) API-tekijänoikeus kuuluu Palveluntarjoajalle; (b) Kehittäjän oma sovellus kuuluu Kehittäjälle; (c) kolmansien avoimen lähdekoodin lisenssit (MIT, Apache 2.0, LGPL) huomioidaan.

Vaihe 9 — Allekirjoita sopimus. Molemmat osapuolet allekirjoittavat sopimuksen kahtena samansisältöisenä kappaleena. Sähköinen allekirjoitus on pätevä oikeustoimilain (228/1929) mukaan. Säilytä sopimukset kirjanpitolain (1336/1997) mukaisten säilytysaikavaatimusten mukaisesti.

API-käyttöehtosopimus Suomessa kuuluu useaan oikeudelliseen viitekehykseen, joista keskeisimmät ovat sopimusoikeus, immateriaalioikeus, tietosuoja ja sähköinen viestintä.

Oikeustoimilaki (228/1929). Sopimusvapaus API-sopimuksen perustana; kohtuuttomat ehdot sovitellaan 36 §:n nojalla. Kuluttajasopimusten osalta kuluttajansuojalaki (38/1978) on pakottavaa oikeutta.

Tekijänoikeuslaki (404/1961). API:n taustalla oleva ohjelmistokoodi on tekijänoikeudella suojattu teos (tekijänoikeuslaki 1 §). Ohjelmiston tekijänoikeudellinen suoja ei edellytä rekisteröintiä; suoja syntyy automaattisesti teoksen luomisesta. API-dokumentaatio voi olla suojattu sekä tekijänoikeudella (kirjallinen teos) että tietokantalain nojalla (sui generis -tietokantasuoja). Tekijänoikeuslaki 25 j § säätelee ohjelmiston kääntämisestä ja yhteentoimivuudesta; käänteinen suunnittelu on sallittua vain yhteentoimivuuden varmistamiseksi.

Tietosuojalaki (1050/2018) ja GDPR (EU 2016/679). Jos API välittää henkilötietoja, GDPR 28 artiklan mukainen DPA on pakollinen. GDPR 32 artiklan tekniset turvatoimet: kuljetuskerroksen salaus (TLS 1.2 tai uudempi), pääsynhallinta (OAuth 2.0, API-avain tai mTLS). GDPR 33-34 artiklojen tietoturvaloukkausilmoitus 72 tunnissa. Tietosuojavaltuutetun toimisto Suomessa käsittelee GDPR-loukkauksia.

Laki sähköisen viestinnän palveluista (917/2014). 307-311 § viestinnän luottamuksellisuus: viestien sisältöä ei saa käsitellä luvattomasti. 316 § tietoturvan varmistamisvelvollisuus sähköisten viestintäpalveluiden tarjoajille. 319 § tietoturvaloukkauksen ilmoittaminen Liikenne- ja viestintävirasto Trafficomille.

Laki vahvasta sähköisestä tunnistamisesta ja sähköisistä luottamuspalveluista (617/2009). Soveltuu, jos API:ta käytetään vahvaan sähköiseen tunnistamiseen. eIDAS-asetus (EU 910/2014) harmonisoi sähköisiä luottamuspalveluja EU-tasolla.

Maksupalveludirektiivi (PSD2, EU 2015/2366, kansallinen täytäntöönpano maksupalvelulaissa 290/2010). Pankkisovellusrajapinnat (AISP/PISP-palvelut) edellyttävät Finanssivalvonnan toimilupaa ja sopimuksia PSD2-vaatimusten mukaisesti.

EU:n tekoälyasetus (AI Act, 2024/1689). Jos API tarjoaa korkean riskin tekoälyjärjestelmää (HRAIS), tekoälyasetuksen vaatimukset liittyvät riskiarvioinnista, läpinäkyvyydestä ja ihmisvalvonnasta ja ne on huomioitava sopimuksessa.

API-käyttöehtosopimus Suomessa epäonnistuu seuraavista yleisimmistä virheistä, jotka aiheuttavat oikeudellisia ongelmia, tietosuojarikkomuksia tai teknisiä häiriöitä.

Virhe 1 — DPA-liitteen puuttuminen. Kehittäjä integroi API:n, joka välittää henkilötietoja, ilman GDPR 28 artiklan mukaista tietojenkäsittelysopimusta. Tietosuojavaltuutettu voi määrätä seuraamusmaksun. Suositus: tarkista ennen sopimuksen allekirjoittamista, sisältääkö Palveluntarjoaja DPA-liitteen tai erillinen DPA.

Virhe 2 — Epämääräinen käyttötarkoitus. Sopimuksessa ei määritellä sallittua käyttötarkoitusta, jolloin kiista käyttötarkoituksesta on mahdollinen. Palveluntarjoaja voi irtisanoa sopimuksen vetoamalla käyttöehtojen rikkomiseen. Suositus: kirjaa sallittu käyttötarkoitus konkreettisesti ja listaa kielletyt käyttötapaukset.

Virhe 3 — API-avaimen väärinkäyttö. Kehittäjä tallentaa API-avaimen avoimeen lähdekoodiin (GitHub-repositorioon) tai jakaa sen alihankkijoille ilman sopimusta. Palveluntarjoaja voi laskuttaa kaikesta luvattomasta käytöstä. Suositus: käytä ympäristömuuttujia (environment variables), secrets management -ratkaisuja ja IP-whitelistiä.

Virhe 4 — Pyyntörajan ylityksen yllätys. Sovellus lähetää API-kutsuja kontrolloimattomasti (esimerkiksi päätteettömässä silmukassa) ja ylittää pyyntörajan, jolloin lasku nousee odottamattomasti. Suositus: kirjaa sopimukseen enimmäislaskutusmäärä (billing cap) ja aseta sovellukseen automaattiset hälytykset pyyntörajoja lähestyttäessä.

Virhe 5 — Versiomuutosten huomiotta jättäminen. Palveluntarjoaja päivittää API:n uuteen versioon, minkä seurauksena kehittäjän integraatio hajoaa. Suositus: varmista, että sopimuksessa on ennakkoilmoitusvelvollisuus merkittävistä versiomuutoksista ja siirtymäaika vanhan version tuelle.

Virhe 6 — Vastuunrajoituslausekkeen puuttuminen. Sopimuksessa ei rajoiteta Palveluntarjoajan vastuuta API-katkoksista aiheutuvista liiketoimintavahingoista. Suositus: kirjaa vastuunrajoituslauseke, joka rajaa vastuun maksettuihin käyttömaksuihin ja poissulkee välilliset vahingot.

Virhe 7 — Kolmannen osapuolen avoimen lähdekoodin lisenssiehtojen laiminlyönti. API-integraatiokirjasto tai SDK sisältää GPL-lisenssin alaista koodia, joka edellyttää integroivan sovelluksen julkaisemista GPL-lisenssillä. Suositus: tarkista käytettyjen kirjastojen (SDK, client library) lisenssit ennen käyttöönottoa.