Récupérer un membre
Une personne, son rôle et ses adresses, par identifiant de compte.
Exécute le véritable appel sur votre espace de travail, avec votre propre clé.
GET /members/{userId}
Une personne, son rôle et ses adresses, par identifiant de compte.
Exemple
Nécessite members:read. Par IDENTIFIANT UTILISATEUR : le userId issu de la liste, et non son adresse e-mail.
curl "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t" -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", "labels:read", "labels:write", "contacts:read" ], "addresses": [ { "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44", "address": "[email protected]", "access": "member" } ], "createdAt": "2026-08-12T14:20:00.000Z"}Il n'y a pas de recherche par e-mail ici. POST /members est le seul appel qui en accepte une, parce que c'est le seul appel dont l'appelant n'a véritablement pas encore d'identifiant utilisateur.
Un identifiant utilisateur qui n'appartient pas à cet espace de travail donne un simple 404. C'est le seul cas de cette ressource qui relève sans ambiguïté du « ressource inexistante ». La même condition levée par une écriture qui n'a pas pu être relue correspond à un 422, ce qui est juste là-bas et faux ici.
Lu à partir de la liste complète des membres plutôt que par une requête sur une seule ligne, et c'est délibéré : un membre est l'UNION d'une ligne de rôle et d'un ensemble d'octrois d'adresses, chacun pouvant exister sans l'autre, et cette union est calculée en un seul endroit. Une requête sur une seule ligne en serait une seconde implémentation, et la population qu'elle manquerait discrètement est celle des détenteurs d'octrois hérités, qui constituent aujourd'hui l'essentiel de la table.