Application Programming Interface (API)

API staat voor Application Programming Interface. Een API is een standaardkoppeling tussen computersystemen zodat ze eenvoudig gegevens kunnen uitwisselen en samenwerken. Zoals mensen onderling dezelfde taal moeten spreken om elkaar te kunnen begrijpen, zorgt een API dat de basiscommunicatie tussen computersystemen goed geregeld is. Dankzij API’s kunnen we snel nieuwe functies toevoegen aan systemen en ook nieuwe systemen koppelen.

In deze ‘API voor dummies’ gaan we eerst in op de vraag ‘wat is een API koppeling?’ en vertellen we iets meer over hoe zo’n API is opgebouwd en wordt gebruikt. Vervolgens geven we wat voorbeelden van hoe API’s de digitalisering binnen verschillende branches helpen. We beschrijven ook de verschillende type API’s en hun karakteristieken. We leggen tenslotte uit welke voordelen een API biedt en we tonen hoe API’s worden gebruikt om ons HelloID platform flexibel aan te sluiten op verschillende bron- en doelsystemen van klanten.

Wat is een API?

Vandaag de dag regelen we steeds meer dingen online. Via je smartphone of laptop heb je met één klik toegang tot het nieuws, kun je je social media bekijken of bijvoorbeeld een vliegreis boeken. Als we even bij dat laatste voorbeeld blijven, zo’n reisapp of website kan niet stand-alone werken. Via zo’n app geef je aan waar je naartoe wilt, met hoeveel mensen je wil reizen en wanneer. Vervolgens moet de app toegang krijgen tot verschillende luchtvaartmaatschappijen om geschikte vluchten te vinden en die te tonen aan de klant.

Nu zijn er vandaag de dag talloze luchtvaartmaatschappijen en reisapplicaties. Het laatste wat we willen is dat we voor iedere individuele koppeling tussen een luchtvaartmaatschappij en reisapplicatie eerst dikke specificaties moeten gaan schrijven. Daarom zijn er API’s ontwikkeld waarmee reisapplicaties op een afgesproken manier informatie kunnen opvragen uit zulke reserveringssystemen. En op vergelijkbare manier hebben sites als Booking.com API’s om individuele huizenverhuurders op te nemen in hun platform. Een ander voorbeeld zie je bij de zorgverzekeraars die API’s gebruiken om zorginstellingen eenvoudig aan te sluiten. En banken maken het met een API mogelijk voor klanten om de persoonlijke rekening te koppelen aan hun online boekhoudpakket. API’s zijn de standaardkoppelingen die zorgen dat we in de huidige online wereld computersystemen snel, veilig en betrouwbaar met elkaar kunnen verbinden en laten samenwerken. Maar hoe werkt zo’n API?

Hoe werkt API in de praktijk?

Allereerst moet je in zo’n API koppeling een aantal technische en praktische zaken afspreken om sowieso de communicatie tussen systemen mogelijk te maken. We spreken bijvoorbeeld af dat we alle informatie met behulp van het HTTP protocol over internet versturen. En dat we voor de gegevens een bepaald formaat gebruiken, zoals XML of JSON. Er zijn een aantal technische standaard API formaten (zoals de REST API) waarin zulke algemene afspraken al zijn vastgelegd. Daaraan hoef je dus bij het ontwerpen van een API weinig tijd te besteden, het is vooral een kwestie van de juiste keuze. Later in deze blog zullen we een aantal van zulke technische API formaten (de REST, SOAP, RPC en GraphQL API’s) verder toelichten.

Wat iedere API vervolgens uniek maakt, zijn de gegevens en instructies die systemen via een API naar elkaar kunnen sturen. En daar horen ook afspraken bij over wat het ontvangende systeem met die gegevens gaat doen. Je kunt met zo’n API dus feitelijk op afstand een ander systeem opdrachten geven. Vandaar ook de term Application Programming Interface: Je kunt een applicatie als het ware op afstand programmeren met behulp van instructies die je via een interface naar dat systeem stuurt.

Je kunt zo’n API ook het beste vergelijken met de ober in een restaurant. Jij bestelt bij de ober een kop soep. De ober loopt vervolgens naar de keuken en geeft de opdracht door aan de kok. Je hoeft niet zelf naar de kok te lopen en je hoeft hem ook niet uit te leggen hoe hij soep moet klaarmaken.

Hoe werkt dat bij de koppeling tussen het reserveringssysteem en de reisapp? Allereerst kan men daar afspreken dat een REST API wordt gebruikt. En over die API kunnen bijvoorbeeld de volgende zaken worden uitgewisseld:

• De reisapp verstuurt de reisgegevens (bestemming, datum, aantal kinderen/volwassen) naar meerdere reserveringssystemen via de API.
• De systemen zoeken op basis van de ontvangen gegevens naar relevante vluchten, checkt of er plek is en wat de prijzen zijn. Deze gegevens worden teruggestuurd.
• De reisapp presenteert alle beschikbare vluchten aan de klant.
• Als de klant een vlucht heeft gekozen, verstuurt de reisapp een boekingsverzoek naar het betreffende reserveringssysteem. Het systeem verwerkt dat verzoek en boekt de vlucht.
• Het reserveringssysteem stuurt een bevestiging en geeft ook instructies voor de betaling. Etc. etc.

Met behulp van deze API weten we hoe de reisapp en de reserveringssystemen technisch samenwerken. En het handige is dat als luchtvaartmaatschappijen nieuwe koppelingsverzoeken krijgen van andere reisapps, men dezelfde API kan gebruiken. Alle details zijn al vastgelegd in de API en het is bijna plug en play.

Voorbeeld van een API

Vergelijkbaar met het bovenstaande voorbeeld in de luchtvaart vind je talloze API’s in alle sectoren. Soms zijn het API’s die sectorbreed worden gebruikt om applicaties te koppelen. Maar er zijn ook universelere API’s die veel breder worden ingezet. Als jij bijvoorbeeld gebruik wil maken van Google Maps op een website of in een applicatie, kun je dit doen met de vastgestelde Google API. Hieronder geven we wat voorbeelden van API’s die in de verschillende sectoren worden gebruikt.

API in de zorg

De zorg digitaliseert razendsnel. Zorginstellingen gebruiken tal van systemen, variërend van reguliere kantoorautomatisering tot specifieke zorgapplicaties en medische systemen. Vaak betreft het standaard software die in verschillende organisaties wordt gebruikt en op allerlei manieren gekoppeld moeten kunnen worden aan andere systemen. Nedap Ons is een voorbeeld. Nedap Ons is een uitgebreide softwareoplossing voor het stroomlijnen van administratieve taken in zorgorganisaties. Het bevat functies voor het beheer van informatie over zowel medewerkers als cliënten, planning en autorisatie. Om Ons te kunnen koppelen aan andere systemen biedt Nedap een REST API aan die andere systemen toegang geeft tot services en data in het Nedap Ons platform.

API voor de overheid

Gemeenten zijn ingewikkelde organisaties met een veelheid aan systemen. Veel van de werkzaamheden betreft langer lopende zaken zoals een vergunningsaanvraag, een subsidieverzoek of een paspoortverlenging. Deze zaken worden beheerd met een zogenaamd zaaksysteem waarin alle relevante gegevens over zo’n zaak worden opgeslagen. Een zaaksysteem heeft veel interfaces nodig. Bijvoorbeeld met het KCC (Klant Contact Centrum) zodat men vragen van burgers snel en adequaat kan beantwoorden. Ook andere gemeentelijke ICT-systemen raadplegen informatie uit zo’n zaaksysteem. Daarom is het nu voorgeschreven dat zaaksystemen de zogenaamde ‘API’s voor Zaakgericht werken’ gebruiken. Gemeenten hoeven gegevens dan niet meer te kopiëren tussen systemen; men kan gegevens altijd rechtstreeks raadplegen in het bronsysteem. Het is een voorbeeld van een gemeentelijke API om de digitalisering van gemeenten te versnellen.

API voor de zakelijke markt

Human Resources (HR) krijgt gaandeweg een steeds belangrijkere rol in bedrijven. Voorheen was het vooral de administratieve ‘personeelsafdeling’. Maar nu ligt de rol veel meer op het zoeken en behouden van talent. Ook wordt in steeds meer processen, van de salarisadministratie tot de uitgifte van gebruikersaccounts het HR systeem als leidend bronsysteem gebruikt. Daarom beschikken moderne HR systemen zoals AFAS en Visma over API’s om de HR gegevens te ontsluiten naar andere systemen. Visma Raet bijvoorbeeld is gericht op overheidsorganisaties, zorg- en onderwijsinstellingen. Het systeem biedt onder andere de Visma.net HRM & Payroll API voor koppelingen met door de organisatie zelfontwikkelde systemen en applicaties van derden.

Het verschil tussen API’s en Webservices

Soms worden de termen API en webservices door elkaar heen gebruikt. Goed dus om ook die term even toe te lichten. Met een webservice kun je applicaties via internet toegankelijk maken voor externe systemen. Een webshop bijvoorbeeld hoeft zelf geen betaalfuncties in te bouwen. Hij kan eenvoudig met behulp van een webservice worden gekoppeld aan een betaalprovider die de betalingen regelt.

’Een webservice fungeert dus als een API tussen de betaalprovider en de aangesloten webshops. Maar het is wel een heel specifiek type API. Zo’n webservice is puur bedoeld voor communicatie via het internet, het gebruik is vastgelegd in een specifiek formaat (Web Service Definition Language, WSDL) en er wordt altijd gebruik gemaakt van bepaalde standaarden zoals SOAP, HTTP en XML.

Een webservice is dus een van de verschillende soorten API’s die vandaag de dag worden gebruikt. Er zijn ook volop API’s die anders werken. Ze maken bijvoorbeeld gebruik van andere type netwerken, andere standaarden of andere gegevensformaten. Sterker nog, er zijn ook API’s die helemaal geen netwerk gebruiken en worden gebruikt om systemen rechtstreeks te koppelen. En tenslotte zijn er ook API’s die verschillende applicaties binnen één systeem laten samenwerken. Zo beschikt een besturingssysteem als Windows over talloze API’s om allerlei applicaties, randapparaten etc. te laten samenwerken op jouw computer. Een webservice is dus een API, maar niet iedere API is een webservice.

Verschillende soorten API’s en voordelen

Wat is een REST (JSON, XML, HTML) API?

REST staat voor Representational state transfer. De REST API – of voluit: RESTful API – is ontwikkeld in 2000 en populair vanwege de flexibiliteit. De informatie kan over verschillende protocollen verstuurd al wordt – zeker in web omgevingen – meestal het HTTP protocol gebruikt waardoor er verder geen extra API software nodig is om deze te gebruiken. Standaard HTTP-methoden zoals GET, POST, PUT en DELETE kunnen worden gebruikt en omdat korte berichten worden gebruikt zijn REST API’s relatief snel. Een REST API is ook stateless; er wordt geen sessie informatie opgeslagen zodat iedere aanvraag naar een systeem alle noodzakelijke informatie moet bevatten.

REST API’s ondersteunen verschillende dataformaten. Niet alleen JSON (JavaScript Object Notation) dat met zijn relatieve lichte, eenvoudige structuur populair is in web-omgevingen. Ook het meer gestructureerde XML (eXtensible Markup Language) formaat dat vooral wordt gebruikt voor complexere gegevens. Daarnaast is HTML (HyperText Markup Language), de opmaaktaal voor webpagina’s een optie. REST API’s zijn bij uitstek geschikt voor ‘lichtgewicht’ API’s en worden gebruikt bij tal van online diensten, van X tot Spotify.

Wat is een SOAP (XML) API?

Simple Object Access Protocol (SOAP) is al een veteraan onder de protocollen; SOAP bestaat inmiddels 25 jaar. SOAP API’s worden veelal gebruikt voor webservices en maken gebruik van het HTTP protocol. Overigens zijn er ook nog legacy SOAP koppelingen die de informatie over SMTP (Simple Mail Transfer Protocol) transporteren.

SOAP maakt gebruik van XML. Zoals hierboven al geschetst is dat een meer gestructureerd informatie formaat, wat berichten langer maakt en gegevensuitwisseling trager. SOAP is wat ‘zwaar’ voor eenvoudige web toepassingen maar erg geschikt voor het ondersteunen van complexe gegevensuitwisseling en processen in Enterprise omgevingen. Ook biedt SOAP meer geavanceerde security maatregelen. Met deze eigenschappen wordt SOAP veel gebruikt in bijvoorbeeld payment services en communicatie tussen banken en andere grootzakelijke omgevingen.

Wat is een RPC (TCP, UDP) API?

RPC staat voor Remote Procedure Call. Dit is een al wat langer bestaande aanpak en je kunt er over twisten of het echt een API is. We vergeleken eerder een API met de ober in het restaurant, een soort ‘man-in-the-middle’. Als je die vergelijking doortrekt, kun je RPC beter vergelijken met een restaurantbezoeker die zelf hard naar de kok schreeuwt dat hij soep wil. Bij RPC kan een applicatie namelijk rechtstreeks een functies aanroepen binnen het ontvangende systeem. Dat heeft voordelen – het is direct, snel en krachtig – maar de communicatie is niet standaard beveiligd en ook niet erg flexibel. Als je het systeem iets anders wil laten doen, moet je de interface weer aanpassen. De communicatie gaat via TCP (Transmission Control Protocol) of UDP (Datagram Protocol).

Wat is een GraphQL (HTTP) API?

GraphQL is ontwikkeld door Facebook en interessant vanwege de uitgebreide filtermogelijkheden en je kunt bovendien opdrachten tegelijk naar verschillende systemen sturen. Feitelijk kun je in een query naar het systeem al exact filteren welke informatie je zoekt, en alleen die data worden vervolgens teruggestuurd. De complexiteit van meerdere gekoppelde systemen wordt van je afgeschermd en je krijgt de samenhangende resultaten van je query teruggestuurd.

Overzichtstabel

	REST API	SOAP API	RPC API	GraphQL API
Algemeen	Gebaseerd op standaard HTTP-methoden (GET, POST, PUT etc.)	Gebruikt XML, normaliter via HTTP	Eenvoudige procedure-oproepen via directe functieaanroepen	Querytaal naar distributed systemen
Data formaten	JSON, XML of HTML. Andere opties mogelijk	XML	XML, JSON. Andere opties mogelijk	Vaak JSON, maar kan andere formaten ondersteunen
Protocollen	Normaliter HTTP-protocollen, andere opties mogelijk	Kan verschillende protocollen gebruiken, zoals HTTP, SMTP, enz.	Meestal TCP of UDP	Maakt gebruik van HTTP, onderliggend protocol kan variëren
Stateful of stateless	Altijd stateless	Stateless en Stateful	Stateless en Stateful	Normaal stateless, maar evt stateful
Flexibiliteit	Meer flexibiliteit in endpoint-URL's en gegevensformaten	Minder flexibel, vereist expliciete definitie van gegevensstructuren en acties	Minder flexibel, omdat we rechtstreeks methoden oproepen	Biedt hoge mate van flexibiliteit en laat de client de benodigde gegevens specificeren
Snelheid	Over het algemeen sneller vanwege minder overhead	Kan meer overhead hebben, waardoor het trager kan zijn	Kan snel zijn vanwege de directe oproepen naar de doelapplicatie	Efficiënt omdat alleen de benodigde gegevens worden opgehaald
Veiligheid	Ondersteund maar let op implementatie van authenticatie en autorisatie	Kan complexe beveiligingsopties bieden (bijv. WS-Security)	Vereist aanvullende beveiligingsmaatregelen	Biedt beveiliging op veldniveau

Voordelen van het gebruik van een API

Met behulp van API’s kunnen we eenvoudig functies uit verschillende systemen combineren om nieuwe toepassingen te maken. Je hergebruikt zoveel mogelijk bestaande applicaties en functies zodat je jezelf kan focussen op de nieuwe zaken. In het voorbeeld van de reisapp kan de eigenaar zich helemaal richten op de ontwikkeling van de app terwijl we voor de vluchtgegevens uit reserveringssystemen zoveel mogelijk de bestaande functionaliteit en standaard API koppelingen gebruiken. Zo kunnen we ons concentreren op wat je echt nieuw wilt ontwikkelen, terwijl de implementatie van de oplossing als geheel beheersbaar, veilig en flexibel is. Dat leggen we hieronder wat verder uit.

Gevoel van controle

Digitale innovatie valt of staat dus met de mogelijkheid om verschillende systemen eenvoudig te laten samenwerken. Zo kun je probleemloos bestaande functionaliteit hergebruiken, of gegevens uit andere systemen eenvoudig raadplegen. Tegelijkertijd moet dat wel gecontroleerd gebeuren. Als we ad hoc verbindingen gaan maken tussen allerlei systemen en rechtstreeks inprikken op elkaars software en data, eindigen we in no-time met een ‘spaghetti-architectuur’; een architectuur waarin de minste of geringste aanpassing ervoor zorgt dat de functionaliteit, de betrouwbaarheid of de beveiliging begint te rammelen.

Een goede architectuur met goed ontwikkelde en gedocumenteerde API’s geeft systemen op een gecontroleerde manier toegang tot elkaars functionaliteit en gegevens. De systeemeigenaar blijft altijd in control over hoe die zaken gebruikt kunnen worden en andere systemen krijgen ook nooit rechtstreeks toegang tot de code. Ook systeemaanpassingen vormen geen enkel probleem. Via de bestaande API’s blijven bestaande functies en gegevens gewoon toegankelijk, terwijl nieuwe functionaliteit naar behoefte via een update van zo’n API ook weer toegankelijk kunnen worden gemaakt. Het systeem als geheel is ‘onder controle’.

Veiligheid API

Belangrijk is dat moderne API’s een integraal onderdeel vormen van je informatiebeveiliging. Voordat we collectief remote en hybride gingen werken, werden bedrijfsnetwerken vaak nog beveiligd als een kasteel. Bij zo’n kasteel vormen de muren en de poort de beveiliging maar daarachter is er weinig meer om indringers tegen te houden. Op vergelijkbare manier richtten IT managers zich volledig op de toegangsbeveiliging tot hun bedrijfsnetwerk. Eenmaal binnen dat netwerk was er weinig controle meer op het gebruikersgedrag en ook de koppelingen tussen systemen stonden vaak simpelweg volledig ‘open’. Nu we met z’n allen remote en in de cloud werken is deze traditionele toegangsbeveiliging niet langer houdbaar.

Zero-trust principe

IT applicaties kunnen remote door gebruikers worden benaderd en systemen hebben via internet ook contact met systemen buiten de eigen organisatie. Daarom moeten moderne IT netwerken gebaseerd zijn op het zero-trust principe, waarin we iets of iemand nooit blindelings vertrouwen. Bij iedere gebruikerssessie – en dus ook bij informatie uitwisseling tussen systemen – moet de vraag zijn wie er toegang vraagt, wat diens rol is en welke toegangsrechten het systeem heeft. Moderne web API’s maken dit mogelijk. Hoe je een API veilig toepast, leggen we hierna uit.

Flexibiliteit

Organisaties moeten als geheel steeds sneller kunnen inspelen op nieuwe maatschappelijke ontwikkelingen, markttrends en technologische innovaties. Ook de IT moet steeds wendbaarder zijn. Men moet applicaties snel kunnen koppelen of juist afschakelen. Met de moderne API’s ondersteunen we dit. Het koppelen van systemen vereist nog zelden een langdurig systeemintegratie project; meestal kan een API snel worden geconfigureerd en geactiveerd.

Een voorbeeld zijn moderne HR systemen. Die zijn met API’s gekoppeld aan de overige bedrijfssystemen. Vaak wordt na een aantal jaren opnieuw een HR pakket geselecteerd. Kiest men een ander pakket, dan kan zo’n migratie dankzij de beschikbare API’s snel worden uitgevoerd. Je kunt niet alleen snel de nieuwe applicatie aansluiten via een API, ook het overzetten van de data naar het nieuwe systeem kan via API’s efficiënt worden geregeld.

Hoe zet je een API veilig in?

Zoals hiervoor uitgelegd moeten moderne API’s volgens het zero trust concept werken. We mogen dus bij een interface tussen twee systemen er nooit blind van uitgaan dat ze te vertrouwen zijn. Net als gebruikers moeten ook applicaties zich authentiseren (met wie heb ik te maken?) als ze toegang vragen tot een andere applicatie. En ook een aangesloten systeem moet de juiste autorisatie (wat mag iemand doen?) hebben om opdrachten te kunnen geven aan dat andere systeem. Het is steeds belangrijker dat we mensen en systemen alleen toegang geven tot functies en data die ook echt nodig zijn. Vooral omdat er steeds meer persoonsgegevens worden verstuurd tussen systemen.

AVG regels

De AVG stelt hier strikte regels voor. Systemen mogen alleen persoonlijke gegevens verwerken voor duidelijk en gerechtvaardigde doeleinden. Dat noemen ze doelbinding en in een goede API kun je de dataselectie zo instellen dat alleen die gegevens kunnen worden gedeeld die de ontvangende applicatie nodig heeft. Koppel je bijvoorbeeld een HR systeem aan een opleidingstool, dan heeft zo’n systeem geen verzuimgegevens nodig. Die gegevens moeten dus afgesloten zijn voor deze applicatie.

Tip: Test je API
Voor de autorisatie wordt vaak gebruik gemaakt van de OAuth 2.0 standaard. En juist omdat de aandacht van nature is gericht op de authenticatie en autorisatie van menselijke gebruikers, is het extra belangrijk om ook de beveiliging van API’s te testen.

Efficiënte API koppelingen voor Identity and Access Management

Hoe maken we binnen een Identity & Access Management (IAM) platform gebruik van API’s en welke IAM API’s zijn er? Dat leggen we uit aan de hand van ons cloud-based HelloID platform. Als IAM platform hebben we koppelingen met zogenaamde bronsystemen en doelsystemen.

• Bronsystemen zijn veelal HR systemen, zoals AFAS en Visma Raet. Zij voeden het IAM platform met informatie over nieuwe medewerkers, functieveranderingen en mensen die uit dienst gaan. Aan de hand van deze informatie maken we nieuwe accounts aan, beheren we toegangsrechten en breken we uiteindelijk ook weer accounts af.
• Doelsystemen zijn de systemen waar we vervolgens informatie naar toe sturen. Als we in HelloID een gebruikersaccount hebben geregistreerd en de bijbehorende toegangsrechten bepaald, maken we ook de accounts aan in bijvoorbeeld de Active Directory of Entra ID. Ook naar bedrijfsapplicaties zoals Nedap Ons – een veelgebruikt zorgsysteem – en service managementsystemen zoals TOPdesk versturen we accountgegevens en instellingen.

Overigens, veel bronsystemen zoals AFAS zijn tegelijkertijd óók een doelsysteem. HelloID maakt voor nieuwe medewerkers namelijk een self-service account aan op het HR systeem om de eigen persoonlijke gegevens te beheren en loonstroken te bekijken.

200 software koppelingen

IAM fungeert dus als een spin in het web tussen alle systemen. Voor het aansluiten van systemen bieden we inmiddels ruim 200 connectoren naar bestaande systemen. Een fundamenteel aspect van deze connectoren is hun vermogen om te integreren met een breed scala aan API’s, elk met hun eigen specifieke kenmerken en formaten. Zoals eerder in het artikel uitgelegd, varieert de aard van deze API’s aanzienlijk – sommige systemen gebruiken REST, anderen SOAP of GraphQL. Bovendien, de manier waarop gegevens worden uitgewisseld en de vereisten voor het opvragen van data kunnen sterk verschillen per API. Bijvoorbeeld, het ene HR-systeem kan direct alle personeelsgegevens verstrekken, terwijl een ander systeem vereist dat eerst een lijst van alle medewerkers wordt opgevraagd, gevolgd door individuele gegevensopvragingen (API calls) per medewerker.

De belangrijkste functie van een connector binnen dit complexe landschap is het standaardiseren van deze uiteenlopende gegevensstromen. Ongeacht de diversiteit van API’s en de formaten waarin zij gegevens leveren, transformeert de connector deze naar een uniform formaat. Dit zorgt ervoor dat de data-uitwisseling via verschillende systemen consistent en gestroomlijnd verloopt. Naast het omzetten van data kan een connector echter ook aanvullende logica en controles bevatten die bijdragen aan een efficiënte en betrouwbare integratie. Middels de connectoren is HelloID in staat om persoons- en contractgegevens uit te lezen, en accounts en toegangsrechten in te stellen. Onze benadering met HelloID zorgt ervoor dat er maximale flexibiliteit is en dat aanpassingen aan de aangesloten systemen normaal gesproken niet nodig zijn. De connector vormt dus de brug tussen de diversiteit van API’s en de gestandaardiseerde behoeften van ons IAM-platform.

API aanpassingen verwerken

Verandert een leverancier van een aangesloten systeem iets aan hun API? Dan passen wij de connector aan. Dat kan ook nodig zijn als een systeem-API meer mogelijkheden krijgt. Bij sommige doelsystemen kan HelloID door limitaties van de API nu alleen een basisaccount aanmaken of verwijderen. Specifieke toegangsrechten moet men dan nog via het systeem zelf beheren. Bijvoorbeeld bij een zorgsysteem waarin men in het systeem zelf moet instellen wie toegang krijgt tot welke patiëntgegevens. Zodra zo’n API wordt uitgebreid door de leverancier, kunnen we onze connector aanpassen en voortaan ook deze gedetailleerde instellingen vanuit HelloID beheren.