API-beheer is het organiseren en uitvoeren van het onderhoud rond API’s en de koppelingen die ze gebruiken. Het omvat toegang, monitoring, wijzigingen en incidenten. Bij een bedrijfskoppeling betekent dat ook controleren of de gegevensstroom inhoudelijk is voltooid: een geslaagde HTTP-respons is niet hetzelfde als een correct verwerkte order of factuur.
Wat is het verschil tussen API-beheer en een koppeling bouwen?
Tijdens de bouw leg je vast hoe systemen gegevens uitwisselen. Bij beheer bewaak je of dat na oplevering blijft gebeuren volgens de afgesproken regels. Wie ontvangt de foutmelding? Wie mag toestemming vernieuwen? Wie beoordeelt een wijziging in een veld of endpoint? Zonder die afspraken kan een probleem blijven liggen, ook als de technische oplossing beschikbaar is.
De term API-management wordt ook gebruikt voor een platform dat API’s publiceert, beveiligt en verkeer begrenst. Een API-gateway kan daarvan een onderdeel zijn. Zo’n platform vervangt niet het operationele beheer van een volledige koppeling: de datamapping, verwerking in het doelsysteem en het herstel van een record blijven afzonderlijke verantwoordelijkheden.
Welke onderdelen horen bij API-beheer?
- Inventaris en eigenaarschap. Leg vast welke API’s, apps, administraties en gegevensstromen in gebruik zijn, met een technisch en een procesverantwoordelijke.
- Toegang. Bewaak credentials, tokens, gebruikersrechten en de procedure voor intrekken of opnieuw autoriseren.
- Monitoring. Meet fouten en verwerkingstijden, maar ook achterstanden en ontbrekende gegevens.
- Wijzigingsbeheer. Volg API-versies en wijzigingen in schema’s, mappings, workflows en bronpakketten.
- Incidentafhandeling. Zorg voor een meldroute, een veilige stop- of herstelprocedure en terugkoppeling aan gebruikers.
- Documentatie en overdracht. Bewaar de gegevensstroom, configuratie, testgevallen en beheerafspraken op een toegankelijke plek.
Toegang tot een API alleen is niet voldoende: controleer ook of een gebruiker de betreffende gegevens mag lezen of wijzigen. OWASP beschrijft dit onderscheid in zijn richtlijn voor autorisatie op objectniveau. Neem daarom administratie- en recordrechten mee in de test, niet alleen het slagen van de aanmelding.
Wat monitor je behalve uptime?
- Het tijdstip van de laatste volledig afgeronde verwerking.
- Het aantal onverwerkte records en de leeftijd van het oudste record.
- Verschillen tussen verwachte bronrecords en werkelijk verwerkte doelrecords.
- Foutsoorten, herhaalde retries en de uitkomst van herstelacties.
- Verbruik van API- of platformlimieten en relevante factureringsmeldingen.
Bepaal per gegevensstroom wat een acceptabele vertraging is. Een rapportage die dagelijks wordt bijgewerkt vraagt andere meldingen dan een proces dat een bestelling moet doorzetten. Leg ook vast wie de inhoudelijke uitkomst controleert: een technisch beheerder kan een koppeling herstellen, maar niet zonder afspraak beslissen hoe een onjuist bronrecord moet worden aangepast.
Hoe ziet een bruikbare incidentprocedure eruit?
- Bepaal de impact. Welke gegevensstroom, administratie en gebruikers zijn geraakt, en sinds wanneer?
- Begrens het probleem. Voorkom nieuwe dubbele of foutieve verwerking en bewaar onverwerkt werk.
- Classificeer de fout. Maak onderscheid tussen toegang, ongeldige gegevens, tijdelijke onbereikbaarheid en een limiet.
- Herstel gecontroleerd. Controleer welke acties al zijn uitgevoerd voordat je een batch opnieuw aanbiedt.
- Controleer en sluit af. Vergelijk bron en doel, informeer de eigenaar en registreer de oorzaak en wijziging.
Voor tijdelijk falende verzoeken kan een begrensd retrybeleid passen. Microsofts Retry pattern benadrukt dat herhaling bij niet-idempotente bewerkingen ongewenste dubbele acties kan veroorzaken. Een runbook moet dus ook aangeven wanneer niet opnieuw wordt geprobeerd en wie het record beoordeelt.
Wie is verantwoordelijk en welke afspraken heb je nodig?
Wijs een proceseigenaar aan voor gegevens en acceptatie, een technisch beheerder voor de koppeling en een contactpersoon bij de softwareleverancier. Leg vast welke ondersteuningstijden gelden, hoe een incident wordt gemeld en wanneer wordt opgeschaald. Beschrijf ook wat buiten het beheercontract valt, zoals een nieuwe gegevensstroom of omvangrijke wijziging in het bronpakket.
Bewaar loggegevens alleen zolang en zo uitgebreid als nodig voor het afgesproken doel. Plaats geen access tokens, secrets of complete persoonsgegevens in een foutmelding. Zorg dat alleen de juiste medewerkers logs en beheerinstellingen kunnen bekijken.
Een praktische start voor bestaande koppelingen
Begin met één kritieke gegevensstroom. Controleer of eigenaar, laatste geslaagde verwerking, foutmeldingen, toegang en herstelprocedure vindbaar zijn. Test een foutscenario voordat het zich in productie voordoet. Maak daarna dezelfde afspraken voor de andere koppelingen; een losse workflow zonder overdraagbaar beheer blijft afhankelijk van degene die hem heeft gebouwd.
Bij Exact Online staat de technische aanpak op hoe je een Exact Online API-koppeling maakt, met een aparte uitleg over API-limieten. Wil je het beheer in een nieuwe implementatie opnemen, benoem deze verantwoordelijkheden al bij het laten maken van een API-koppeling.
