Concedeix i revoca una adreça
El segon eix: a quines adreces pot arribar una persona, i a quin nivell.
Executa qualsevol de les 2 crides d'aquesta pàgina contra el teu espai de treball, amb la teva pròpia clau.
POST /members/{userId}/addresses
El segon eix: a quines adreces pot arribar una persona, i a quin nivell.
Una concessió no és un rol
access és el vocabulari antic per adreça i deliberadament no se superposa amb els noms dels permisos: member llegeix l'adreça i hi envia com a tal, viewer només la llegeix. No diu res sobre si la persona pot enviar o no, cosa que depèn del seu rol, i tots dos han de permetre un enviament perquè se'n produeixi cap.
| El seu rol | La seva concessió sobre billing@ | Pot enviar com a billing@? |
|---|---|---|
| té `emails:send` | member | Sí. |
| té `emails:send` | viewer | No, la concessió ho rebutja. |
| sense `emails:send` | member | No, el rol ho rebutja. |
| té `emails:send` | cap concessió | No, l'adreça no entra mai a la llista amb què es comprova un enviament. |
Donar un rol a algú no li dona cap adreça. Un membre amb un rol i sense concessions obre una bústia BUIDA en comptes de la de tothom, que és l'error correcte mentre encara estàs decidint què ha de veure.
Concedeix una adreça
Necessita members:write. POST /members/{userId}/addresses amb { addressId, access }; access té el valor predeterminat member. Retorna el membre sencer tal com queda ara.
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 sobre la subcol·lecció en comptes d'un PUT sobre la parella, perquè de tota manera és un upsert i l'id de la fila no és una cosa que qui fa la crida anomeni mai. Tornar a fer POST amb un access diferent és com un viewer esdevé member: hi ha una fila per parella (adreça, persona), de manera que una segona crida canvia el nivell en comptes d'afegir una segona concessió. Això també fa que aquest sigui el rar POST que és segur repetir.
Es controla amb members:write i no amb la propietat de l'adreça, que és la diferència entre això i el camí de concessió antic del router de dominis. La propietat és el control correcte per a la persona que va afegir el domini i el control equivocat per a un administrador que no posseeix res i que gestiona els accessos de l'espai de treball en nom del propietari. Tots dos escriuen la mateixa fila.
Torna el membre sencer i no només la concessió, de manera que la fila de la pantalla es pot tornar a renderitzar sense una segona petició, i la resposta es llegeix igual tant si la concessió era nova com si era una modificació.
Una adreça que no és en aquest espai de treball dona member_not_found, un 422, amb param: "addressId". Una clau només pot repartir adreces que pertanyin a l'espai de treball per al qual es va emetre.
Fer una concessió al PROPIETARI de l'espai de treball dona member_is_owner, un 422. Ja té totes les adreces que hi ha, de manera que la crida no hi podria afegir res.
Revoca una adreça
Necessita members:write. DELETE /members/{userId}/addresses/{addressId}. Retorna el membre, sense aquesta adreça.
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" }La revocació estreta, i la que cal fer servir quan algú canvia d'equip: conserva el seu rol i la resta d'adreces i deixa de veure aquesta.
Una adreça que no és en aquest espai de treball es rebutja en comptes d'ignorar-se en silenci. Altrament, una errada tipogràfica a l'id informaria d'una revocació correcta que no ha passat mai, que és precisament l'error que aquest endpoint existeix per evitar.
Torna el membre i no una làpida, perquè la resposta interessant és a què pot arribar encara. Un { deleted: true } aquí obligaria el client a deduir-ho per resta.
Per recuperar-ho tot de cop, DELETE /members/{userId} elimina el rol i totes les concessions alhora i informa de quantes n'han caigut.