Een zakelijke internetverbinding bestellen klinkt eenvoudig, maar valt in de praktijk toch tegen. Op het ene adres is de beste glasvezel van Delta, op het andere adres van Eurofiber. De mobiele back-up hiervoor kan eigenlijk het beste van KPN komen. Daar komt nog bij dat elk netwerk zijn eigen manier van bestellen heeft: een moderne REST-API, XML-berichten, een portaal, of alleen een e-mailadres. Wanneer de juiste order dan eindelijk geplaatst is, komen de updates via net zoveel verschillende kanalen binnen, waardoor ze makkelijk gemist worden.
Partners van Nextpertise merken niets van deze complexiteit. Zij bestellen en beheren verbindingen van meer dan 50 verschillende netwerken op één manier, in één platform: InControl. De motor achter InControl is de Nextpertise API, waar niet alleen InControl, maar ook onze partners direct tegenaan bouwen. Deze API is gebouwd met FastAPI, net als alle services eromheen. Als sponsor van FastAPI Conf '26 laten we zien hoe wij FastAPI gebruiken om eenvoudig snelle en stabiele applicaties te bouwen.
Eén framework voor drie soorten projecten
Met FastAPI is het vooral heel makkelijk om snel een nieuwe API online te krijgen. FastAPI vereist geen zee aan configuratiebestanden, dwingt geen specifiek ORM af, en is razendsnel (opnieuw) opgestart. Dit maakt ontwikkelen met FastAPI erg fijn. Daarnaast zorgt FastAPI ervoor dat al onze request- en responseschema’s gedocumenteerd en gevalideerd worden, maar laat het ons verder vrij om te focussen op waardevolle nieuwe features.
Binnen Nextpertise gebruiken we deze eigenschappen op verschillende manieren. Bij grote projecten, zoals de Nextpertise API achter InControl, is het vooral van belang dat dezelfde code makkelijk aangeroepen kan worden vanuit een HTTP-request, maar ook vanuit een AMQP-bericht, een CLI of een cronjob. Doordat FastAPI niet veel eisen stelt aan onze internals, voelt geen van deze routes als tweederangs. We houden de routers simpel: ze vertalen alleen een request naar het aanroepen van een interne servicefunctie. Voorbij de API-laag kunnen we zo de code indelen zoals het het beste past bij ons probleemdomein, niet zoals een framework vindt dat onze oplossing eruit moet zien.
Daarnaast hebben we specialistische services die vooral heel betrouwbaar moeten zijn. Een voorbeeld hiervan is B2BStream, de ingang van ons platform voor upstream-providers. Dit is de API die de verschillende soorten webhooks van bijvoorbeeld Delta en KPN ontvangt, opslaat, en buffert voor de rest van ons platform. Voor dit project was eigenlijk maar één eis: we mogen nooit inkomende data verliezen. Wij bereiken dit door deze services zo simpel mogelijk te houden. De API zelf heeft als enige doel het bericht zo snel mogelijk op te slaan in een database, waarna een van onze workers het bericht verder doorstuurt naar aangesloten systemen. Doordat we het bericht direct opslaan, weten we zeker dat we geen data verliezen. Tegelijkertijd betekent dit natuurlijk ook dat deze API nooit downtime mag hebben: we kunnen er niet altijd van uitgaan dat berichten opnieuw naar ons gestuurd worden. De combinatie van FastAPI binnen onze eigen Kubernetes-cluster, verspreid over meerdere fysieke locaties, heeft ons hierin nog nooit teleurgesteld.
Als laatste maken we gebruik van FastAPI op projecten waar snel itereren voorop staat: voor proof-of-concepts, maar ook bij ProviderHog. Dit is de interne service die de API’s waar wij mee integreren nabootst, waardoor partners in onze sandbox, en wij in onze testomgevingen, tegen zo echt mogelijke systemen aan kunnen praten. De eenvoudige en goed gedocumenteerde interface maakt FastAPI erg toegankelijk voor LLM’s. Binnen ProviderHog helpt dat ons met snel schakelen: we leggen de specificatie van de provider-API naast echte berichten van testverbindingen, en de LLM schrijft de implementatie voor ons. De sleutel hierbij zijn goede en volledige tests. Om zeker te zijn van de juiste implementatie gebruiken we VCR's: opnames van echte providerberichten. Met de TestClient van FastAPI spelen we die af tegen ProviderHog, en checken we of het resultaat exact overeenkomt. Zo schrijft een LLM de code, maar bepaalt de echte provider of het klopt!
Documentatie die vanzelf klopt
Een API kan nooit beter zijn dan zijn eigen documentatie. Als een functie of datastructuur niet gedocumenteerd is, kunnen partners er ook geen gebruik van maken. Zeker nu een LLM steeds vaker meeleest, is volledigheid extra waardevol. FastAPI helpt ons daarbij: uit onze code genereert het automatisch een OpenAPI-specificatie, die onze CI/CD-pipelines dan weer automatisch publiceren naar docs.nextpertise.nl. Uit dezelfde specificatie genereren we ook een MCP-server, zodat een AI-assistent rechtstreeks onze API kan begrijpen.
Dat dit allemaal automatisch gaat, is voor ons het belangrijkste. In Python beschrijven we de modellen en functies toch al en FastAPI zorgt er samen met Pydantic voor dat die beschrijvingen gestructureerd naar buiten gebracht kunnen worden. Dit betekent dat alles wat in de documentatie staat, ook echt in onze code bestaat. Wijzigingen aan de documentatie kunnen hierdoor in dezelfde reviews worden meegenomen als de wijziging zelf.
Op de plekken waar FastAPI niet alles weet, gaan we nog een stapje verder. Zo breiden we de documentatie bijvoorbeeld uit met tags en rechten per endpoint. Voor de rechten gebruiken we een eigen decorator, die niet alleen verplichte rechten meegeeft, maar ook bijhoudt welke optionele rollen de response veranderen. Zo kun je met de rol broadband-r zien welke producten er op een adres beschikbaar zijn, maar zie je de kosten alleen als je ook de rol pricing-r hebt. We hebben de OpenAPI-generatorfunctie van FastAPI uitgebreid, zodat ook deze informatie uit de decorator in de documentatie landt. Uiteindelijk komt het erop neer dat niemand de API-referentie met de hand hoeft te onderhouden, waardoor die altijd accuraat is.
Updates zonder te vragen
Aan zowel FastAPI als InControl wordt elke dag hard gewerkt. Soms vallen dingen daardoor heel mooi samen. In InControl zijn we bijvoorbeeld bezig met een SSE-stream (Server-Sent Events) om updates sneller bij partners te krijgen. In plaats van een systeem dat elke minuut moet pollen of een order (die weken kan duren) klaar is, krijgt het gekoppelde systeem een seintje als de order geüpdatet is. Een stuk efficiënter! Voor de eerste, interne versie hebben we een eigen event-streamingimplementatie gemaakt, maar sinds FastAPI 0.135.0 zit SSE in het framework zelf. Daardoor kon onze eigen versie weg, en werd de code veel eenvoudiger, en daarmee beter.
Waarom we FastAPI Conf '26 sponsoren
Een framework is een goede keuze als je er niet meer over nadenkt. FastAPI valideert alle data die naar onze systemen wordt gestuurd, genereert onze documentatie, streamt onze events, en is snel en stabiel genoeg dat wij ons op connectiviteit kunnen richten. Krijgt FastAPI er een feature bij, dan mogen wij meestal code weggooien. Dat is voor ons het steunen waard.
Ben je op FastAPI Conf '26? Spreek ons vooral aan. We praten graag over realtime updates op lastige orders die weken duren, de beste manieren om XML uit de vorige eeuw te parsen in een modern systeem, of hoe een LLM een provider kan nabouwen.
