Nadaj i odbierz dostęp do adresu
Druga oś: do których adresów jedna osoba może sięgnąć i na jakim poziomie.
Uruchamia dowolne z 2 wywołań na tej stronie na twojej przestrzeni roboczej, twoim własnym kluczem.
POST /members/{userId}/addresses
Druga oś: do których adresów jedna osoba może sięgnąć i na jakim poziomie.
Uprawnienie do adresu to nie rola
access to starsze słownictwo dla pojedynczych adresów i celowo nie pokrywa się z nazwami uprawnień: member czyta adres i wysyła jako on, viewer tylko go czyta. Nie mówi nic o tym, czy dana osoba w ogóle może wysyłać — to jest jej rola — i oba muszą pozwolić na wysyłkę, zanim ona nastąpi.
| Ich rola | Ich uprawnienie do billing@ | Czy mogą wysyłać jako billing@ |
|---|---|---|
| ma `emails:send` | member | Tak. |
| ma `emails:send` | viewer | Nie, uprawnienie do adresu na to nie pozwala. |
| bez `emails:send` | member | Nie, rola na to nie pozwala. |
| ma `emails:send` | brak jakiegokolwiek uprawnienia | Nie, adres nigdy nie trafia na listę, względem której sprawdzana jest wysyłka. |
Nadanie komuś roli nie daje mu żadnych adresów. Członek z rolą i bez uprawnień otwiera PUSTĄ skrzynkę, a nie skrzynkę wszystkich — i to jest właściwa awaria, dopóki dopiero decydujesz, co ma widzieć.
Nadaj dostęp do adresu
Wymaga members:write. POST /members/{userId}/addresses z { addressId, access }; access domyślnie ma wartość member. Zwraca całego członka w stanie, w jakim teraz jest.
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 na podkolekcji, a nie PUT na parze, ponieważ i tak jest to upsert, a identyfikatora wiersza wywołujący nigdy nie podaje. Ponowne wysłanie z innym access to sposób, w jaki viewer staje się member: jest jeden wiersz na parę (adres, osoba), więc drugie wywołanie zmienia poziom, zamiast dodawać drugie uprawnienie. To także czyni z niego rzadki POST, który bezpiecznie powtórzyć.
Bramkowane przez members:write, a nie przez posiadanie adresu, i to jest różnica między tym a starszą ścieżką nadawania uprawnień w routerze domen. Własność jest właściwą bramką dla osoby, która wstawiła domenę, i niewłaściwą dla administratora, który nie posiada niczego i prowadzi dostęp w przestrzeni roboczej w imieniu właściciela. Oba zapisują ten sam wiersz.
Wraca cały członek, a nie samo uprawnienie, żeby wiersz na ekranie dało się przerysować bez drugiego żądania i żeby odpowiedź czytała się tak samo niezależnie od tego, czy uprawnienie było nowe, czy zmienione.
Adres, którego nie ma w tej przestrzeni roboczej, to member_not_found, 422, niosące param: "addressId". Klucz może rozdawać wyłącznie adresy należące do przestrzeni roboczej, w której go wydano.
Nadanie uprawnienia WŁAŚCICIELOWI przestrzeni roboczej to member_is_owner, 422. Ma już każdy adres w niej, więc to wywołanie nie mogłoby nic dodać.
Odbierz dostęp do adresu
Wymaga members:write. DELETE /members/{userId}/addresses/{addressId}. Zwraca członka bez tego adresu.
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" }Wąskie odebranie uprawnień i to, po które sięgasz, gdy ktoś zmienia zespół: zachowuje swoją rolę i pozostałe adresy, a przestaje widzieć ten jeden.
Adres, którego nie ma w tej przestrzeni roboczej, zostaje odrzucony, a nie po cichu zignorowany. Literówka w identyfikatorze raportowałaby w przeciwnym razie udane odebranie uprawnień, które nigdy nie nastąpiło — a to jest awaria, której ten endpoint ma zapobiegać.
Wraca członek, a nie nagrobek, ponieważ interesującą odpowiedzią jest to, do czego nadal ma dostęp. { deleted: true } w tym miejscu zostawiałoby klientowi wyliczanie tego przez odejmowanie.
Żeby odebrać wszystko naraz, DELETE /members/{userId} usuwa rolę i każde uprawnienie razem oraz raportuje, ile ich zniknęło.