Een lid opvragen
Eén persoon, zijn rol en zijn adressen, op account-id.
Voert de echte aanroep uit op je workspace, met je eigen sleutel.
GET /members/{userId}
Eén persoon, zijn rol en zijn adressen, op account-id.
Voorbeeld
Vereist members:read. Op USER-ID: de userId uit de lijst, niet het e-mailadres.
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"}Er is hier geen opzoeken op e-mailadres. POST /members is de enige aanroep die er een accepteert, want het is de enige aanroep waarvan de aanroeper werkelijk nog geen user-id heeft.
Een user-id dat niet bij deze workspace hoort is gewoon een 404. Het is het ene geval in deze resource dat ondubbelzinnig "deze resource bestaat niet" betekent. Dezelfde situatie, opgeworpen door een schrijfactie die niet teruggelezen kon worden, wordt een 422, wat daar juist is en hier verkeerd.
Bewust afgelezen van de volledige ledenlijst in plaats van via een query op één rij: een lid is de VERENIGING van een rolrij en een verzameling adrestoekenningen, die elk zonder de ander kunnen bestaan, en die vereniging wordt op precies één plek berekend. Een query op één rij zou daarvan een tweede implementatie zijn, en de groep die hij stilletjes zou missen zijn de houders van oude toekenningen, die vandaag het grootste deel van de tabel vormen.