Een adres toekennen en intrekken
De tweede as: welke adressen één persoon mag bereiken, en op welk niveau.
Voert elk van de 2 aanroepen op deze pagina uit op je workspace, met je eigen sleutel.
POST /members/{userId}/addresses
De tweede as: welke adressen één persoon mag bereiken, en op welk niveau.
Een toekenning is geen rol
access is het oudere vocabulaire per adres en overlapt bewust niet met de namen van de permissies: member leest het adres en verstuurt eruit, viewer leest het alleen. Het zegt niets over de vraag of de persoon überhaupt mag versturen, want dat is zijn rol, en beide moeten een verzending toestaan voordat er een plaatsvindt.
| Hun rol | Hun toekenning op billing@ | Mogen ze versturen als billing@ |
|---|---|---|
| heeft `emails:send` | member | Ja. |
| heeft `emails:send` | viewer | Nee, de toekenning weigert het. |
| geen `emails:send` | member | Nee, de rol weigert het. |
| heeft `emails:send` | helemaal geen toekenning | Nee, het adres komt nooit in de lijst waartegen een verzending wordt gecontroleerd. |
Iemand een rol geven geeft diegene geen adressen. Een lid met een rol en zonder toekenningen opent een LEGE mailbox in plaats van die van iedereen, en dat is de juiste fout zolang je nog beslist wat diegene mag zien.
Een adres toekennen
Vereist members:write. POST /members/{userId}/addresses met { addressId, access }; access is standaard member. Geeft het hele lid terug zoals het er nu voor staat.
curl -X POST "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t/addresses" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "access": "viewer" }'{ "object": "member", "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t", "email": "[email protected]", "name": "Sam Okonjo", "image": null, "role": { "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "builtin": null }, "implied": false, "permissions": ["emails:send", "emails:read", "threads:read", "threads:write"], "addresses": [ { "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44", "address": "[email protected]", "access": "member" }, { "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "address": "[email protected]", "access": "viewer" } ], "createdAt": "2026-08-12T14:20:00.000Z" }POST op de subcollectie in plaats van een PUT op het paar, want het is hoe dan ook een upsert en het rij-id is niets wat een aanroeper ooit noemt. Opnieuw posten met een andere access is hoe een viewer een member wordt: er is één rij per (adres, persoon), dus een tweede aanroep wijzigt het niveau in plaats van een tweede toekenning toe te voegen. Daarmee is dit ook de zeldzame POST die veilig herhaald kan worden.
Afgeschermd met members:write in plaats van met eigenaarschap van het adres, en dat is het verschil met het oudere toekenningspad op de domains-router. Eigenaarschap is de juiste drempel voor de persoon die het domein heeft ingebracht en de verkeerde voor een beheerder die niets bezit en het toegangsbeheer van de workspace namens de eigenaar uitvoert. Beide schrijven dezelfde rij.
Het hele lid komt terug in plaats van alleen de toekenning, zodat de rij op het scherm opnieuw gerenderd kan worden zonder tweede verzoek, en zodat het antwoord hetzelfde leest of de toekenning nu nieuw was of een wijziging.
Een adres dat niet bij deze workspace hoort levert member_not_found op, een 422, met param: "addressId". Een sleutel kan alleen adressen uitdelen die horen bij de workspace waarvoor hij is uitgegeven.
Toekennen aan de EIGENAAR van de workspace levert member_is_owner op, een 422. Die heeft al elk adres erop, dus er is niets wat de aanroep zou kunnen toevoegen.
Een adres intrekken
Vereist members:write. DELETE /members/{userId}/addresses/{addressId}. Geeft het lid terug, zonder dat adres.
curl -X DELETE \ "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t/addresses/c40a95f2-1cc6-4d31-82a8-9e075d31c2a8" \ -H "$AUTH"{ "object": "member", "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t", "email": "[email protected]", "name": "Sam Okonjo", "image": null, "role": { "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "builtin": null }, "implied": false, "permissions": ["emails:send", "emails:read", "threads:read", "threads:write"], "addresses": [ { "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44", "address": "[email protected]", "access": "member" } ], "createdAt": "2026-08-12T14:20:00.000Z" }De smalle intrekking, en degene om naar te grijpen wanneer iemand van team wisselt: diegene houdt zijn rol en zijn andere adressen en ziet dit adres niet meer.
Een adres dat niet bij deze workspace hoort wordt geweigerd in plaats van stilletjes genegeerd. Een typefout in het id zou anders een geslaagde intrekking melden die nooit heeft plaatsgevonden, precies de fout die dit endpoint moet voorkomen.
Het lid komt terug in plaats van een grafsteen, want het interessante antwoord is wat diegene nog kan bereiken. Een { deleted: true } zou een client dat hier door aftrekken laten uitzoeken.
Om alles in één keer terug te nemen: DELETE /members/{userId} verwijdert de rol en alle toekenningen samen en meldt hoeveel er zijn verdwenen.