Deel-integratie

A1Connection architecture

The connection uses OAuth 2.0 against the vendor's own consent screen. The authorisation request names the minimum scopes the features need — the exact scope list is shown in the security-flow panel below, pulled from the same provider registry the application uses. The code-for-token exchange happens entirely server-side (HTTP Basic-clientauthenticatie, per the vendor's token endpoint contract); tokens are stored encrypted at rest and are never rendered back to any screen — connection pages show presence, not values.

De levenscyclus van tokens wordt beheerd via één centraal controlepunt: verval triggert een automatische vernieuwing, geroteerde vernieuwingstokens worden bewaard, en een vernieuwing die door de leverancier wordt geweigerd, wordt getoond als een duidelijke melding om opnieuw te koppelen — nooit als stilletjes falende functionaliteiten. Intrekking werkt aan beide kanten: verbreek de verbinding hier, of trek deze in via de eigen beveiligingsinstellingen van de leverancier.

A2Schrijfsemantiek en gegevensstroom

Elke gegevensverplaatsing is een expliciete actie met een gelogd resultaat. Schrijfacties vinden plaats op uw klik — of uitsluitend automatisch wanneer u een regel hebt ingeschakeld (automatisch doorsturen bij aanname staat standaard uitgeschakeld per provider). Leesacties — het importeren van personen, accounts of bestanden — worden uitgevoerd wanneer u op Importeren klikt, ontdubbelen op basis van wat u al hebt (klanten op naam, personen op e-mailadres), slaan over in plaats van te overschrijven, en rapporteren eerlijk over aangemaakte versus overgeslagen items, waardoor het opnieuw uitvoeren van een import inherent veilig is.

Elke actie schrijft een regel naar het app-activiteitenlogboek (ats_app_activity): wat er is uitgevoerd, wanneer, voor welk record en het resultaat — inclusief de letterlijke fouttekst van de leverancier wanneer er iets misgaat. Gebruiksrapportages binnen het ATS aggregeren ditzelfde logboek, zodat integratierapportages en de werkelijkheid van de integratie nooit uit elkaar kunnen lopen.

Alles wat het verzoekpad verlaat — notificatieverspreiding, webhook-aflevering, activiteitenregistratie, e-mail — draait in 'fire-and-forget'-achtergrondthreads. Een traag extern eindpunt kan de interface nooit laten vastlopen en een mislukt neveneffect wordt gelogd in plaats van stilzwijgend opnieuw te worden geprobeerd tot er inconsistentie ontstaat.

A3Operationele overwegingen

Koppelingen zijn op organisatieniveau en voorbehouden aan de rollen eigenaar en beheerder; recruiters gebruiken de functionaliteiten die door een koppeling worden aangedreven, maar kunnen deze niet koppelen, ontkoppelen of opnieuw configureren. Bij het ontkoppelen worden opgeslagen inloggegevens onmiddellijk verwijderd en worden de afhankelijke functies zichtbaar stopgezet, niet geruisloos. Reeds geïmporteerde gegevens blijven van u en bewerkbaar.

Geïmporteerde personen komen binnen als gemarkeerd als geïmporteerd met voorzichtige privacy-standaardinstellingen — er wordt geen toestemming verondersteld voor personen die uw sollicitatieformulier nooit hebben ingevuld, en standaard bewaartermijnen zijn van toepassing. Alles wat is vastgelegd, is van u: CSV-exports en de Data Export-app dekken dezelfde gegevensbronnen die het product zelf uitleest. De uitgang is even open als de ingang — bewust zo ontworpen, geen concessie.

A4Plaatsing in de integratietopologie

Deze integratie is vandaag beschikbaar in het overzicht. One connection per provider unlocks every feature it powers, and the topology grid below shows the neighbouring connectors in the same capability area — statuses come from the same registry that drives the in-app hub, so this page can never claim more than the product does. For anything the catalogue does not cover, Webhooks and Zapier are the generic, documented escape hatch.