De beste voorwaarden of terms and conditions voor een API

Het opstellen van goede voorwaarden oftewel terms and conditions voor een API is lastig. Als API-aanbieder wil je risico’s uitsluiten maar tegelijkertijd creativiteit niet inperken. In dit artikel leggen we uit hoe je dit het beste kan doen. (artikel laatst geactualiseerd aug 2023).

Voorbeelden van APIs

Een API oftewel een Application Programming Interface is een technische interface. Als een systeem een API heeft, dan kunnen andere programma’s (bijvoorbeeld apps of websites) makkelijk contact leggen met het systeem, de informatie raadplegen en mogelijk orders doorgeven. Twitter heeft een API zodat mensen twitter-apps kunnen ontwikkelen. Hetzelfde geldt voor instagram. De Nederlandse Spoorwegen heeft een API zodat andere websites en systemen ook treintijden laten zien. En partijen als bol.com hebben een API zodat andere de producten kunnen laten zien en helpen verkopen. Ook slimme thermostaten hebben een API, zie www.toonapi.com.

Het grote voordeel van APIs voor eindgebruikers is dat APIs het mogelijk maken om informatie te combineren. Er hoeft niet voor elke informatie een aparte app of website worden bezocht, maar men kan slimme apps maken die bijvoorbeeld afhankelijk van je reistijd (NS-API) en interesses (twitter API) passende boeken (bol.com API) aanbieden. Voor bedrijven heeft het aanbieden van een API het voordeel dat derde partijen meehelpen om apps te ontwikkelen: het is goedkoper om 1 API aan te bieden dan tientallen apps om alle gebruikers te bereiken.

De uitdaging van API voorwaarden

Het schrijven van voorwaarden voor een app is in theorie eenvoudig (voor meer informatie, zie bijvoorbeeld deze juridische tips voor appmakers). Een goede app is ontwikkeld voor een bepaalde doelgroep met een bepaald doel. Mensen mogen de app gebruiken voor dit doel en anderen niet tot last zijn. Bij een API is dit veel lastiger. De gebruiker van een API is een developer, die de API gebruikt om iets te maken dat gebruikt wordt door eindgebruikers. De developer weet niet precies wat de eindgebruikers gaan doen, en kan dit ook niet altijd beïnvloeden. In API-termen wordt wel een gesproken over B2D. De API wordt aangeboden aan developers. De developers zelf zijn echter niet de echte eindgebruikers. Dit zijn bedrijven en consumenten. Bij het bepalen van de prijs van gebruik van APIs is het belangrijk om hier rekening mee te houden, en bijvoorbeeld gratis test-accounts te hebben zodat developers niet direct hoeven te betalen.

Een ander probleem is dat sommige apps gebruik maken van meerdere APIs. Als APIs teveel voorwaarden hebben, wordt het lastig of zelfs onmogelijk om dit soort applicaties te ontwikkelen. De aanbieder van een gratis API, bijvoorbeeld voor weer-informatie, wil soms het vragen van geld verbieden. De developer gebruikt de API mogelijk in een grotere applicatie (die reizen verkoopt) en kan moeilijk de reizen gratis gaan weggeven. API-voorwaarden moeten daarom niet zozeer over de mogelijk app zelf gaan, maar specifiek over gebruik van de API.

Combinatie van voorwaarden en technische maatregelen

Het is niet mogelijk en niet wenselijk om alles in juridische voorwaarden vast te leggen. Bepaalde zaken zijn eenvoudiger technisch te regelen. Het is bijvoorbeeld belangrijk dat bepaalde apps niet teveel gebruik doen van een API. Veel APIs kunnen omvallen als men honderden calls per minuut doet. Het heeft echter geen zin een gebruikslimieten juridisch vast te leggen, omdat vaak niet bekend is wat de exacte limiet is en app-developers niet weten wat gebruikers gaan doen. Je kunt beter elke app en/of gebruiker een account met een limiet geven. De details regel je vervolgens technisch en deel je mee in de API-documentatie. In de voorwaarden spreek je vooral af dat men zich moet houden aan richtlijnen en de eigen account moet gebruiken. Voorbeelden van zaken die je in de API kunt regelen:

• Aantal calls dat een app of developer mag doen
• Aantal devices dat aangesloten kan worden
• De grootte van orders die gedaan mogen worden. Eventueel kan men extra verificatie inbouwen voor grote orders or orders van nieuwe accounts.
• De timing van antwoorden: het kan handig zijn om APIs bewust langzamer te maken om te intensief gebruik te ontmoedigen
• Identificatie: je kunt het gebruik van een geldig email-adres afdwingen
• Verbergen van privacy-gevoelige informatie. Stuur niet meer informatie dan gevraagd

Een goede API is ontworpen om eenvoudig bruikbaar te zijn en om privacy en security al in zich te hebben. De voorwaarden van een goede API kunnen vervolgens eenvoudig zijn. Voor API management wordt vaak een standaard-pakket gebruikt van leveranciers als WSO2 (open source, zie dit artikel voor voordelen en risico’s van open source), 3Scale, Mulesoft of Azure.

Wat leg je vast in de voorwaarden?

In de voorwaarden van APIs zie je vaak de volgende punten terug. Wij raden aan om deze onderwerpen op te nemen en andere zaken in de documentatie op te nemen.

Identificatie van gebruikers:

• Mensen moeten zich inschrijven met eigen naam
• Mensen mogen toegangsgegevens (API-keys) niet delen of verkopen

Merkenrecht:

• Toegang tot de API betekent niet dat je de naam of het logo van de aanbieder mag gebruiken

Gebruik van de API:

• De API mag niet gebruikt worden voor illegale activiteiten of zaken die andere gebruikers hinderen (zoals spam of malware)
• Men moet de API documentatie lezen en zich houden aan richtlijnen
• Als de API persoonsgegevens deelt, moeten gebruikers zich houden aan de wet bescherming persoonsgegevens. Bij zeer gevoelige gegevens kan het nodig zijn te eisen dat API-gebruikers in Europa zijn en de data in Europa blijft in verband met Safe-Harbor-problemen. Ook kan het nodig zijn dat de API-gebruiker een verwerkersovereenkomst tekent.
• API gebruikers zijn verplicht security-problemen te melden. Veel bedrijven hebben een responsible disclosure policy die vertelt hoe men kan melden.
• Voor sommige APIs is het belangrijk het bewaren of hamsteren van data te verbieden.

Monitoring:

• De API-aanbieder mag gebruik monitoren
• Bij vermoeden van misbruik mag de API-aanbieder een app of website auditen
• Bij breken van de regels of overlast mag een account ge-deactiveerd worden

Beperking garanties:

• Bij gratis aangeboden APIs is er vaak geen garantie dat de API werkt of blijft werken. De API wordt as-is aangeboden
• De gebruiker is verantwoordelijk voor zijn app en vrijwaardt de API-aanbieder van claims veroorzaakt door die app

Overig:

• Het Nederlandse recht geldt en geschillen moeten bij een Nederlandse rechter geregeld worden
• De voorwaarden mogen gewijzigd worden (waarbij developers een redelijke termijn krijgen om hun app aan te passen)
• In sommige gevallen zul je iets moeten vastleggen over intellectueel eigendom en auteursrecht.

Een gedeelte van deze voorwaarden is juridisch gezien overbodig: in principe zijn illegale activiteiten al verboden, en zijn merken al beschermd door merkenrecht. Als het goed is zijn de voorwaarden vooral een reminder aan developers wat normaal gedrag is.

Afbeelding: Microsoft Azure API management overview