Przejdź do dokumentacji
API

Lista członków

Wszyscy w przestrzeni roboczej, rola każdego z nich i adresy, które każdemu przyznano.

GETapi.openemail.uk/members

Uruchamia prawdziwe wywołanie na twojej przestrzeni roboczej, twoim własnym kluczem.

GET /members

Wszyscy w przestrzeni roboczej, rola każdego z nich i adresy, które każdemu przyznano.

Członek to dwa nadania, nie jedno

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

role mówi, co wolno im ROBIĆ: jeden wiersz, jedna rola, ten sam obiekt, który opisuje /roles. addresses mówi, NA CZYM mogą to robić: jeden wpis na adres, każdy z własnym access. Klient nie może ich zlewać: rola z emails:send i pustą tablicą addresses to ktoś, kto może wysyłać z niczego, a pełna tablica addresses pod rolą viewer to również ktoś, kto może wysyłać z niczego. Ścieżka wysyłki sprawdza oba, a ekran pokazujący tylko jedno z nich będzie z przekonaniem tłumaczył niewłaściwą odmowę.

Wiersze adresów mówią access tam, gdzie zapisana kolumna mówi role, i ta zmiana nazwy jest istotą rzeczy, a nie porządkami: ten obiekt ma już pole role znaczące coś zupełnie innego, a dwa role oddalone o jeden poziom zagnieżdżenia, niosące wartości z dwóch różnych słowników, to błąd czekający na pierwszą osobę, która przeczyta to szybko. access to member, który czyta adres i wysyła jako on, albo viewer, który tylko go czyta.

implied: true oznacza, że NIKT NIE WYBRAŁ TEJ ROLI. Udostępnianie pojawiło się na długo przed rolami, więc większość osób z dostępem do skrzynki ma uprawnienia do adresów i w ogóle nie ma wiersza członka; zamiast odmawiać im poczty do czasu wykonania backfillu, usługa wywodzi wbudowaną rolę z najszerszego uprawnienia, jakie mają, i raportuje ją z role.id równym null. Pokazuj to jako „wynika z dostępu”, a nie jako rolę, którą ktoś wybrał. Dopóki PATCH nie zamieni wnioskowania w decyzję, poszerzenie ich dostępu do adresów po cichu poszerza to, co wolno im robić.

WŁAŚCICIEL jest PIERWSZYM wierszem, oznaczonym isOwner: true, z role.builtin równym owner. To konto, na które zarejestrowana jest przestrzeń robocza, z definicji ma każde uprawnienie, a POST, PATCH i DELETE odrzucają je z member_is_owner. Dlatego nieudostępniona przestrzeń robocza raportuje jednego członka, a nie zero. Licz stanowiska, wykluczając isOwner.

Przykład

Wymaga members:read. Najpierw właściciel, potem wszyscy pozostali według adresu e-mail, a nie według daty dołączenia, ponieważ tę listę czyta się po to, by znaleźć jedną osobę, a nie po to, by zobaczyć, co się zmieniło.

curl
curl "$OE/members" -H "$AUTH"
Odpowiedź
{  "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}

Dwie populacje na jednej liście, i tak musi być: ktoś może mieć rolę i żadnego adresu, a ktoś może mieć adres i żadnego wiersza roli. Wypisanie samej części wspólnej ukryłoby obie, a w większości przestrzeni roboczych ta druga grupa jest liczniejsza.

createdAt jest null dla kogoś, kto ma uprawnienia, ale nigdy nie miał zapisanego wiersza członka — dla tych samych osób, dla których implied jest true. To moment, w którym nadano im ROLĘ, a nie moment, w którym po raz pierwszy udostępniono im adres.

permissions to płaska, rozwiązana lista, a nie zestaw wartości logicznych. Klient pytający „czy zawiera templates:write” nie może zostać w tyle za słownikiem; klient, któremu wręczono { canEditTemplates: true }, po cichu może.

Bez kursora, ze standardową kopertą. Liczba członków przestrzeni roboczej jest ograniczona tym, ilu osobom jej właściciel ją faktycznie udostępnił, a stronicowanie tego byłoby ceremonią przed czymś, co klient pobiera raz i renderuje w całości.