# Workspace API's testen met Postman [[TOC]] Voordat je code schrijft, wil je een API begrijpen: welke velden komen terug, hoe ziet een fout eruit, wat doet een bepaalde parameter? Postman laat je dat verkennen zonder een regel code. Je doet echte calls, ziet echte responses en bouwt een herbruikbare collection op. Voor het leren en debuggen van Workspace-API's is het onmisbaar. In dit artikel zet je Postman stap voor stap op voor Google Workspace, van authenticatie tot een gedeelde collection. ## OAuth 2.0 instellen in Postman De grootste horde is authenticatie. Postman heeft ingebouwde OAuth 2.0-ondersteuning, dus je hoeft geen tokens handmatig te bouwen. :::howto title="OAuth 2.0 koppelen aan Google" 1. Maak in de **Google Cloud Console** OAuth-credentials aan (type Web application) en noteer de client-ID en client secret. 2. Voeg de juiste **callback-URL** van Postman toe als geautoriseerde redirect-URI. Voor de desktop-app is dat `https://oauth.pstmn.io/v1/callback`, voor de webversie `https://oauth.pstmn.io/v1/browser-callback`. 3. Ga in Postman naar het **Authorization**-tabblad en kies type **OAuth 2.0** met grant type **Authorization Code**. 4. Vul je client-ID, secret, de auth-URL (`https://accounts.google.com/o/oauth2/v2/auth`) en token-URL (`https://oauth2.googleapis.com/token`) van Google in. 5. Zet de gewenste **scopes** en klik op **Get New Access Token**. 6. Doorloop de Google-login en kies **Use Token** om het token aan je requests te koppelen. ::: :::info title="Postman zet de header voor je" Zodra je een token hebt, voegt Postman automatisch de `Authorization: Bearer ...`-header toe aan je requests. Die header hoef je dus niet handmatig te zetten. Let op: de scopes die je opgeeft moeten exact overeenkomen met wat je in het Google Cloud-project hebt geautoriseerd, anders krijg je een 403. ::: ## Je eerste call doen Met een geldig token doe je een GET naar een endpoint. Een goede eerste test is de lijst van gebruikers via de Directory API. ``` GET https://admin.googleapis.com/admin/directory/v1/users?customer=my_customer ``` De alias `my_customer` staat voor de customer-ID van je eigen Workspace-account, handig zodat je je echte ID niet hoeft op te zoeken. Postman toont de JSON-response netjes opgemaakt, inclusief statuscode en headers, zodat je precies ziet wat de API teruggeeft. :::tip title="Werk met environment-variabelen" Gebruik environment-variabelen voor waarden die je vaak hergebruikt, zoals je access token, customer-ID of een test-e-mailadres. Verwijs ernaar met dubbele accolades, bijvoorbeeld `{{base_url}}`. Zo wissel je makkelijk tussen een test- en productieomgeving zonder elke request aan te passen. ::: ## Een collection opbouwen Bewaar je requests in een collection zodat je ze hergebruikt en deelt met je team. Een logische structuur maakt het verschil tussen een rommelige hoop calls en een bruikbare API-bibliotheek. - Groepeer gerelateerde requests in een collection, bijvoorbeeld een per API (Directory, Gmail, Drive). - Gebruik mappen binnen de collection om lees-, schrijf- en verwijderacties te scheiden. - Documenteer elke request met een korte beschrijving van wat hij doet en welke parameters hij verwacht. - Deel de collection met je team via een gedeelde Postman-workspace. - Exporteer hem eventueel als JSON, zodat hij in je repository mee kan. ## Veilig omgaan met secrets Postman-collections worden vaak gedeeld, en daar schuilt een reeel risico. :::danger title="Lek nooit je credentials" Sla nooit je client secret, access tokens of refresh tokens hardcoded op in een gedeelde collection. Gebruik environment-variabelen die als **secret** zijn gemarkeerd, en deel die niet mee bij export. Een gelekte Postman-export met credentials geeft anderen directe toegang tot je Workspace-data. Roteer een gelekt secret meteen in de Google Cloud Console. ::: ## Van Postman naar code Een handige laatste stap: via de **Code**-knop zet Postman een werkende request om naar code in vrijwel elke taal, van cURL tot Python of Node.js. Zo gebruik je je geteste call als startpunt voor je echte integratie, met de zekerheid dat de request klopt. ## Veelgestelde vragen :::faq ### Kan ik service account-authenticatie gebruiken in Postman? Dat kan, maar het vereist dat je handmatig een JWT ondertekent, wat omslachtig is. Voor service accounts is een klein script vaak praktischer. Gebruik Postman vooral voor OAuth-flows met een gebruikersaccount. ### Mijn token verloopt steeds, wat nu? Google access tokens verlopen na ongeveer een uur. Klik op **Get New Access Token** om te verversen, of laat Postman dit automatisch doen door een refresh token te configureren in de OAuth 2.0-instellingen. ### Hoe test ik schrijfacties veilig? Test POST-, PUT- en DELETE-requests altijd eerst in een aparte testomgeving of met testaccounts, niet in productie. Een verkeerde DELETE is zo gedaan en vaak onomkeerbaar. ### Kan ik responses automatisch valideren? Ja. Op het **Tests**-tabblad schrijf je JavaScript-assertions die de response controleren, bijvoorbeeld op statuscode of velden. Dat is handig voor regressietests van je API-integraties. ### Waarom krijg ik een 403 ondanks een geldig token? Meestal mist de scope. De scopes die je bij het token opgaf moeten precies de rechten dekken die het endpoint vraagt, en je Cloud-project moet de bijbehorende API ingeschakeld hebben. ::: Met Postman verken en debug je Workspace-API's snel en veilig, een ideale opstap naar betrouwbare code.