Kalo te dokumentacioni
API

Listoni anëtarët

Të gjithë në hapësirën e punës, roli që mban secili dhe adresat që iu dhanë secilit.

GETapi.openemail.uk/members

Ekzekuton thirrjen reale kundrejt hapësirës suaj të punës, me çelësin tuaj.

GET /members

Të gjithë në hapësirën e punës, roli që mban secili dhe adresat që iu dhanë secilit.

Një anëtar është dy të drejta, jo një

shell
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"

role është çfarë mund të BËJË: një rresht, një rol, i njëjti objekt që përshkruan /roles. addresses është MBI ÇFARË mund ta bëjë: një zë për secilën adresë, secili me access-in e vet. Një klient nuk duhet t’i ngjeshë të dyja: një rol që mban emails:send me një varg addresses bosh është dikush që mund të dërgojë nga asgjë, dhe një varg addresses i plotë nën një rol viewer është po ashtu dikush që mund të dërgojë nga asgjë. Rruga e dërgimit i kontrollon të dyja, dhe një ekran që tregon vetëm njërën do ta shpjegojë me plot bindje refuzimin e gabuar.

Rreshtat e adresave e quajnë access atë që kolona e ruajtur e quan role, dhe riemërtimi është vetë qëllimi e jo një rregullim kozmetik: ky objekt ka tashmë një fushë role që do të thotë diçka krejt tjetër, dhe dy role një nivel larg njëri-tjetrit me vlera nga dy fjalorë të ndryshëm janë një defekt që pret personin e parë që i lexon me nxitim. access është member, që e lexon adresën dhe dërgon si ajo, ose viewer, që vetëm e lexon.

implied: true do të thotë se KËTË ROL NUK E ZGJODHI ASKUSH. Ndarja u lançua shumë përpara roleve, ndaj shumica e njerëzve me qasje te një kuti postare mbajnë të drejta mbi adresa dhe asnjë rresht anëtari; në vend që t’u mohohej posta derisa të ketë kaluar një rimbushje e të dhënave, shërbimi nxjerr një rol të brendshëm nga e drejta më e gjerë që ata mbajnë dhe e raporton me role.id null. Tregojeni këtë si «i nënkuptuar nga qasja» e jo si një rol që e zgjodhi dikush. Derisa një PATCH ta kthejë nxjerrjen në vendim, zgjerimi i qasjes së tyre mbi adresat e zgjeron në heshtje edhe atë që mund të bëjnë.

PRONARI është rreshti i PARË, i shënuar me isOwner: true, me role.builtin owner. Ai është llogaria mbi të cilën mbahet hapësira e punës, i mban të gjitha lejet sipas përkufizimit, dhe POST, PATCH e DELETE e refuzojnë të gjitha me member_is_owner. Prandaj një hapësirë pune e pandarë raporton një anëtar e jo asnjë. Numërojini vendet duke përjashtuar isOwner.

Shembull

Kërkon members:read. Pronari vjen i pari, pastaj të gjithë të tjerët sipas emailit e jo sipas kohës kur u bashkuan, sepse kjo listë lexohet për të gjetur një person e jo për të parë se çfarë ndryshoi.

curl
curl "$OE/members" -H "$AUTH"
Përgjigje
{  "object": "list",  "data": [    {      "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"        },        {          "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8",          "address": "[email protected]",          "access": "viewer"        }      ],      "createdAt": "2026-08-12T14:20:00.000Z"    },    {      "object": "member",      "userId": "7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a",      "email": "[email protected]",      "name": null,      "image": null,      "role": { "id": null, "name": "Viewer", "builtin": "viewer" },      "implied": true,      "permissions": [        "emails:read",        "drafts:read",        "threads:read",        "labels:read",        "contacts:read",        "calendar:read",        "templates:read",        "rules:read",        "connections:read",        "settings:read"      ],      "addresses": [        {          "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8",          "address": "[email protected]",          "access": "viewer"        }      ],      "createdAt": null    }  ],  "hasMore": false,  "nextCursor": null}

Dy popullata në një listë të vetme, dhe kështu duhet të jetë: dikush mund të mbajë një rol dhe asnjë adresë, dhe dikush mund të mbajë një adresë dhe asnjë rresht roli. Listimi vetëm i mbivendosjes do t’i fshihte të dyja, dhe në shumicën e hapësirave të punës grupi i dytë është më i madhi.

createdAt është null për dikë që ka të drejta, por që nuk ka pasur kurrë një rresht anëtari të shkruar — të njëjtët njerëz për të cilët implied është true. Ai është koha kur atij iu dha një ROL, jo kur iu nda për herë të parë një adresë.

permissions është lista e sheshtë e zgjidhur e jo një bashkësi vlerash boolean. Një klient që pyet «a e përmban kjo templates:write» nuk mund të mbetet pas fjalorit; një klient të cilit i jepet { canEditTemplates: true } mbetet pas në heshtje.

Pa cursor, me zarfin standard. Anëtarësia e një hapësire pune kufizohet nga sa njerëzve ua ka ndarë vërtet pronari i saj, dhe faqosja e saj do të ishte ceremoni përpara diçkaje që një klient e merr një herë dhe e renderon të tërë.