Wat is een API? Een eenvoudige gids voor app-bouwers

Een API (application programming interface) is een vastgelegde manier waarop het ene stuk software een ander om data vraagt of het iets laat doen. Je app stuurt een verzoek in een afgesproken formaat — ‘geef me de boekingen van morgen’, ‘reken deze kaart €20 af’, ‘vat deze tekst samen’ — en het andere systeem stuurt een gestructureerd antwoord terug. API’s zijn hoe de onderdelen van een app met elkaar praten, en hoe je app gebruikmaakt van externe diensten zoals betalingen, e-mail, kaarten en AI.

Waarom API’s ertoe doen als je met AI bouwt

Bijna elke nuttige app bestaat uit onderdelen die via API’s communiceren:

• Binnen je app roepen de schermen in de browser de API van je eigen backend aan om data te laden en op te slaan.
• Buiten je app roept je backend de API’s van andere bedrijven aan: Stripe voor betalingen, een e-mailprovider voor bonnetjes, een AI-modelprovider voor het genereren van tekst.

Als je een AI-builder vraagt om ‘betalingen te verwerken’ of ‘een AI-samenvatting toe te voegen’, schrijft die in feite code die een API aanroept. Als je de basis kent, begrijp je wat de AI van jou nodig heeft (meestal een account bij die dienst en een API-sleutel), waar het mis kan gaan, en wat het gaat kosten.

Een alledaagse vergelijking

Denk aan een restaurant. Je loopt de keuken niet in om zelf te koken. Je leest het menu, vertelt de ober wat je wilt op een manier die de keuken begrijpt, en de ober brengt je eten terug — of zegt dat het gerecht op is.

• Het menu is de API-documentatie: een lijst van wat je kunt vragen en hoe.
• De ober is de API: de ene afgesproken manier waarop verzoeken binnenkomen en antwoorden naar buiten gaan.
• De keuken is het andere systeem: je hoeft niet te weten hoe het van binnen werkt.
• Je bestelling is het verzoek; het bord is het antwoord.

De keuken kan zijn ovens en personeel veranderen zonder dat het jou raakt, zolang het menu hetzelfde blijft. Dat is de echte waarde van een API: twee systemen kunnen samenwerken zonder dat een van beide hoeft te weten hoe de ander is gebouwd.

Hoe een web-API-verzoek werkt

De meeste API’s die je tegenkomt zijn web-API’s die via HTTP werken, hetzelfde protocol dat je browser gebruikt. Elk verzoek heeft een paar onderdelen:

En elk antwoord heeft:

JSON (JavaScript Object Notation) is een eenvoudig tekstformaat met namen en waarden tussen accolades. Het is de standaardmanier waarop web-API’s data uitwisselen.

REST: de meest gebruikte stijl

REST is een veelgebruikte conventie voor het ontwerpen van web-API’s. Elk soort ding krijgt een eigen URL, en standaardmethoden zeggen wat je ermee doet. Zo kan een REST-API voor een boekingsapp eruitzien:

PUT bestaat ook en vervangt conventioneel een heel record, terwijl PATCH alleen de velden wijzigt die je meestuurt.

De statuscodes die je het vaakst ziet:

Als je app kapot gaat, is de statuscode vaak de snelste aanwijzing. Een 401 van een betalingsprovider betekent meestal dat een API-sleutel ontbreekt of fout is; een 429 betekent dat je te vaak aanroept.

REST is niet de enige stijl — er bestaan ook GraphQL- en RPC-achtige API’s — maar REST is wat de meeste diensten en AI-gebouwde backends gebruiken.

Een uitgewerkt voorbeeld: een boekingsbevestiging

Als een klant een knipbeurt boekt in een salonapp, kunnen er binnen een à twee seconden meerdere API-aanroepen plaatsvinden:

1. De boekingspagina in de browser stuurt POST /api/bookings met de dienst, het tijdstip en de klantgegevens naar je backend.
2. Je backend controleert of het tijdslot vrij is, slaat de boeking op in de database en geeft 201 Created terug.
3. Je backend roept de API van een e-mailprovider aan met zijn geheime sleutel: ‘stuur deze bevestiging naar lena@example.com’.
4. Als er een aanbetaling nodig is, vraagt je backend de API van de betalingsprovider om een checkoutsessie te maken en stuurt de klant daarheen.
5. Later belt de betalingsprovider jouw app om te melden dat de betaling is geslaagd. Die omgekeerde aanroep is een webhook.

De eerste twee stappen zijn je eigen API tussen frontend en backend. Stappen 3 tot en met 5 zijn API’s van derden.

Veelgebruikte termen uitgelegd

Veelvoorkomende fouten en misverstanden

• Geheime sleutels in de frontend zetten. Alles in code die in de browser draait, kan door iedereen die de pagina bezoekt worden gezien. Geheime sleutels moeten op de server blijven, in omgevingsvariabelen of secrets.
• Sleutels in de chat plakken. Chatgeschiedenis kan worden opgeslagen. Gebruik in plaats daarvan de secrets-functie van je builder, en vervang elke sleutel die je hebt blootgesteld.
• Aannemen dat een API gratis is. Veel API’s rekenen per verzoek of per gebruikseenheid — AI-modelAPI’s rekenen per token. Controleer de prijzen en stel uitgavenlimieten in. Zie hoe je LLM-API’s gebruikt.
• Niet omgaan met fouten. Externe diensten vallen uit, lopen time-outs op en raken limieten. Vraag om zinvolle foutmeldingen en nieuwe pogingen.
• De browser vertrouwen. Je eigen API moet zelf de rechten controleren. Een verborgen knop stopt niemand die het endpoint rechtstreeks aanroept.
• Live-sleutels gebruiken tijdens het testen. Gebruik testmodus-sleutels tot je klaar bent om te lanceren.

Wat je aan je AI-builder kunt vragen

• “Welke externe API’s gebruikt deze app, en wat kost elk ervan?”
• “Roep de betaal-API alleen vanaf de server aan. Lees de sleutel uit een omgevingsvariabele.”
• “Geef een lijst van elk endpoint in onze API, wat het doet en wie het mag aanroepen.”
• “Controleer op de server dat de ingelogde gebruiker de boeking bezit voordat je hem bijwerkt of verwijdert.”
• “Als de e-mail-API faalt, sla de boeking dan toch op en log de fout.”
• “Gebruik voorlopig de testmodus van de provider.”

API’s in Mythex

Mythex kan je eigen API bouwen — als onderdeel van een webapp, of als aparte backend in Node, Python (FastAPI), C# of Java die naast je frontend draait — en de code schrijven die externe diensten aanroept. Je voegt hun sleutels toe als projectsecrets in plaats van in de chat, en ze zijn beschikbaar voor je app in de preview en zodra je publiceert. De documentatie heeft recepten voor elke API integreren en een REST-API-backend bouwen.

Veelgestelde vragen