E-signature API voor digitale platforms

Werkbaar verdict: Signhost, Signicat en DocuSign API zijn pas vergelijkbaar nadat de eigen applicatie fouten rond callbacks, tenants en bewijs kan opvangen. Een nette API-referentie of geslaagde standaardaanroep is onvoldoende. Voor een platform weegt voorspelbaar herstel zwaarder dan het aantal beschikbare endpoints.

De contractstatus hoort in uw domeinmodel

Een verzoek start in de eigen applicatie, maar identificatie en ondertekening verlopen bij een externe dienst. Daardoor ontstaan minstens twee waarheden: de status bij de leverancier en de status van het eigen dossier. Leg vooraf vast welke gebeurtenis een dossier werkelijk afrondt, hoe een ingetrokken verzoek wordt herkend en welk bestand als bewijs wordt bewaard.

De Europese Commissie beschrijft het kader rond elektronische identificatie en vertrouwensdiensten op de officiële eIDAS-pagina. Gebruik die bron voor het regelkader; laat de leverancier afzonderlijk bevestigen welke route en vertrouwensdienst in uw beoogde configuratie worden gebruikt.

Ontwerp eerst de chaosproef

Voer in een sandbox een proef uit die nog niet als geslaagd mag worden beschouwd voordat alle foutpaden zijn beoordeeld:

1. start één verzoek voor een fictieve tenant;
2. lever dezelfde callback twee keer en daarna vertraagd aan;
3. laat de sessie verlopen terwijl de gebruiker nog een oud scherm open heeft;
4. trek het verzoek in en start een gecorrigeerde versie;
5. laat een beheerder document, status en bewijs aan het juiste dossier koppelen.

Doe dit voor Signhost, Signicat en DocuSign met dezelfde payload en dezelfde herstelregels. Controleer idempotentie, retry, handmatige correctie en de mogelijkheid om na een storing opnieuw te reconciliëren. Een testresultaat is pas bruikbaar als log, invoer en verwachte uitkomst zijn vastgelegd.

Criteria die niet mogen middelen

Een fout op tenantisolatie, definitief bewijs of intrekking is een afwijzing en mag niet worden gecompenseerd door betere documentatie. Daarna volgen operationele criteria: duidelijkheid van callbacks, beheer van time-outs, monitoring en de hoeveelheid leveranciersspecifieke logica. Kosten worden pas vergeleken op dezelfde volumescenario's en op basis van een actuele offerte; deze pagina noemt geen bedragen.

Beperk bovendien persoonsgegevens in payloads en logs. De Autoriteit Persoonsgegevens vat de AVG-beginselen samen. Leg vast welke partij welke gegevens verwerkt en voorkom dat technische support standaard volledige identiteitsgegevens ziet.

Voeg aan de scorekaart een vertrekproef toe. Vraag hoe het platform alle nog openstaande verzoeken inventariseert, hoe bewijsbestanden opnieuw kunnen worden opgehaald en welke leveranciersspecifieke identifiers in de eigen database moeten blijven bestaan. Laat een ontwikkelaar daarna met alleen de API-documentatie en het runbook een vastgelopen dossier herstellen. Zo wordt duidelijk hoeveel impliciete kennis in de eerste integratie is ontstaan. Een technisch werkende callback is niet voldoende wanneer alleen de oorspronkelijke bouwer de betekenis ervan kan reconstrueren.

Wanneer een API juist niet nodig is

Een tegengeval is een klein team dat incidenteel via een webportaal verstuurt en geen eigen dossierstatus of identiteitsorkestratie heeft. Daar kan een technische integratie extra storings- en beheerrisico toevoegen zonder het werk te verbeteren.

De keuze blijft beperkt: selecteer alleen een API-aanbieder die de chaosproef herstelbaar maakt én een bewijsbestand oplevert dat buiten de providercontext te begrijpen is. Als geen kandidaat de harde foutpaden haalt, moet eerst het eigen procesontwerp worden aangepast.