Accorder et révoquer une adresse
Le second axe : quelles adresses une personne peut atteindre, et à quel niveau.
Exécute n'importe lequel des 2 appels de cette page sur votre espace de travail, avec votre propre clé.
POST /members/{userId}/addresses
Le second axe : quelles adresses une personne peut atteindre, et à quel niveau.
Un octroi n'est pas un rôle
access est l'ancien vocabulaire par adresse et ne recoupe délibérément pas les noms de permissions : member lit l'adresse et envoie en son nom, viewer se contente de la lire. Il ne dit rien sur le fait que la personne ait le droit d'envoyer, ce qui relève de son rôle, et les deux doivent autoriser un envoi pour qu'il ait lieu.
| Son rôle | Son octroi sur billing@ | Peut-il envoyer en tant que billing@ |
|---|---|---|
| détient `emails:send` | member | Oui. |
| détient `emails:send` | viewer | Non, l'octroi le refuse. |
| pas de `emails:send` | member | Non, le rôle le refuse. |
| détient `emails:send` | aucun octroi | Non, l'adresse n'entre jamais dans la liste sur laquelle un envoi est vérifié. |
Donner un rôle à quelqu'un ne lui donne aucune adresse. Un membre doté d'un rôle et d'aucun octroi ouvre une boîte aux lettres VIDE plutôt que celle de tout le monde, ce qui est le bon échec à avoir tant que vous décidez encore de ce qu'il doit voir.
Accorder une adresse
Nécessite members:write. POST /members/{userId}/addresses avec { addressId, access } ; access vaut member par défaut. Renvoie le membre entier dans son état actuel.
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 sur la sous-collection plutôt qu'un PUT sur la paire, parce qu'il s'agit de toute façon d'un upsert et que l'identifiant de ligne n'est jamais nommé par un appelant. Reposter avec un access différent est la façon dont un viewer devient member : il y a une ligne par (adresse, personne), si bien qu'un second appel change le niveau plutôt que d'ajouter un second octroi. C'est aussi ce qui en fait le rare POST que l'on peut répéter sans risque.
Conditionné à members:write plutôt qu'à la possession de l'adresse, ce qui fait la différence avec l'ancien chemin d'octroi du routeur des domaines. La possession est la bonne condition pour la personne qui a ajouté le domaine et la mauvaise pour un administrateur qui ne possède rien et gère les accès de l'espace de travail pour le compte du propriétaire. Les deux écrivent la même ligne.
C'est le membre entier qui est renvoyé plutôt que le seul octroi, afin que la ligne à l'écran puisse être réaffichée sans seconde requête, et afin que la réponse se lise de la même façon que l'octroi soit nouveau ou modifié.
Une adresse qui n'appartient pas à cet espace de travail donne member_not_found, un 422, portant param: "addressId". Une clé ne peut distribuer que des adresses appartenant à l'espace de travail pour lequel elle a été émise.
Un octroi au PROPRIÉTAIRE de l'espace de travail donne member_is_owner, un 422. Il possède déjà toutes les adresses : l'appel n'aurait donc rien à ajouter.
Révoquer une adresse
Nécessite members:write. DELETE /members/{userId}/addresses/{addressId}. Renvoie le membre, moins cette adresse.
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 révocation étroite, celle à utiliser quand quelqu'un change d'équipe : il conserve son rôle et ses autres adresses et cesse de voir celle-ci.
Une adresse qui n'appartient pas à cet espace de travail est refusée plutôt qu'ignorée en silence. Une faute de frappe dans l'identifiant signalerait sinon une révocation réussie qui n'a jamais eu lieu, et c'est l'échec que ce point de terminaison existe pour éviter.
C'est le membre qui est renvoyé plutôt qu'une pierre tombale, parce que la réponse intéressante est ce qu'il peut encore atteindre. Un { deleted: true } ici laisserait un client le déduire par soustraction.
Pour tout reprendre d'un coup, DELETE /members/{userId} retire le rôle et tous les octrois ensemble et indique combien ont disparu.