Het boekhoudkantoor wordt altijd afgeleid uit de ID-token.
U geeft het nooit mee als parameter: een gebruiker ziet altijd alleen de gegevens van zijn eigen kantoor.
Gebruikersaccounts en bereik van de token
De inloggegevens die u naarPOST /token stuurt, zijn die van een Codaclean-gebruikersaccount.
Het boekhoudkantoor maakt die accounts zelf aan en beheert ze in zijn MyCodaclean-platform. Het bepaalt per gebruiker het toegangsniveau en tot welke klanten die gebruiker toegang heeft.
Een ID-token heeft dus hetzelfde bereik als zijn gebruiker:
- Meestal het hele boekhoudkantoor. De token geeft toegang tot alle klanten van het kantoor die de gebruiker kan zien.
- Of alleen een of meer vennootschappen. Het boekhoudkantoor kan een gebruiker beperken tot bepaalde klanten. De API geeft dan alleen die klanten terug, met hun mandaten en bestanden.
Een ID-token ophalen
RoepPOST /token aan met de inloggegevens van de gebruiker:
Het antwoord bevat:
De ID-token vernieuwen
De ID-token is 1 uur geldig. Zodra hij verlopen is, geven uw aanroepen401 terug.
Roep POST /token dan opnieuw aan, met alleen de refreshtoken:
Het antwoord bevat een nieuwe
idToken, maar geen nieuwe refreshToken: gebruik de refreshtoken die u al hebt gewoon verder.
De refreshtoken is 30 dagen geldig. Is hij verlopen, meld u dan opnieuw aan met gebruikersnaam en wachtwoord.
Tokenfouten
Op dit endpoint wijst een
500 doorgaans op foute inloggegevens of een ongeldige refreshtoken, niet op een serverstoring.Wie kan de API gebruiken?
- Gebruikers met het toegangsniveau Enkel portaal kunnen de API niet gebruiken: hun aanroepen geven
401terug. - Gebruikers die geen Beheerder zijn, zien geen vertrouwelijke klanten.
- De scopes bepalen wat uw API-sleutel mag doen.

