Listo rolet
Çdo rol në hapësirën e punës, të integruarit të parët, me numrin e njerëzve dhe çelësave që mbajnë secilin.
Ekzekuton thirrjen reale kundrejt hapësirës suaj të punës, me çelësin tuaj.
GET /roles
Çdo rol në hapësirën e punës, të integruarit të parët, me numrin e njerëzve dhe çelësave që mbajnë secilin.
Dy boshte, dhe nuk janë e njëjta pyetje
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Një ROL thotë çfarë mund të BËJË dikush në këtë hapësirë pune: të lexojë postën, ta dërgojë atë, të redaktojë shabllone, të shtojë një domen. Një DHËNIE thotë mbi cilat ADRESA mund ta bëjë atë, dhe rri ngjitur te /members/{userId}/addresses si member (lexon adresën dhe dërgon si ajo) ose viewer (vetëm e lexon). Të dyja duhet të pajtohen përpara se të niset një mesazh: një rol që mban emails:send pa asnjë dhënie nuk mund të dërgojë nga asgjë, dhe as çdo adresë e hapësirës së punës nën një dhënie viewer nuk mund të dërgojë nga asgjë.
Çdo hapësirë pune krijohet fillimisht me të njëjtat gjashtë role. Owner, Admin, Member dhe Viewer formojnë një shkallë. Secili mban gjithçka që mban ai pas tij, prandaj ulja e dikujt në gradë ia ngushton aksesin në vend që t'ia këmbejë me një pjesë tjetër. Developer dhe Billing nuk janë shkallare të saj: Developer ndërton integrime (çelësa, webhook-ë, shabllone, dërgim) dhe nuk lexon asnjë mesazh të hapësirës së punës, ndërsa Billing sheh planin e faturat dhe asgjë tjetër. Të dy rrinë rreptësisht brenda Admin. Ata krijohen fillimisht në leximin e parë dhe jo në krijimin e hapësirës së punës, prandaj një hapësirë pune e bërë përpara se të ekzistonte kjo veçori i fiton ato në çastin që i kërkon diçka. builtin emërton nga cili shabllon fillestar vjen një rresht, dhe kaq emërton: të gjashtët janë një pikënisje që një hapësirë pune duhet ta formësojë, dhe secili prej tyre përveç Owner mund të riemërtohet, t'i ndryshohen lejet dhe të fshihet. Degëzoni mbi editable dhe deletable dhe jo mbi emrin: një rol që dikush e riemërtoi u përgjigjet ende saktë atyre të dyjave, ndërsa emri i tij nuk ju thotë më asgjë.
Owner-i është i vetmi përjashtim, dhe është përjashtim në çdo drejtim: editable: false, deletable: false, dhe i refuzuar si objektiv te PATCH /members/{userId}. Ai përshkruan llogarinë me të cilën është çelësuar hapësira e punës dhe mban çdo leje, përfshirë ato të shtuara në një publikim të mëvonshëm, prandaj lista e tij llogaritet dhe nuk ruhet. Ta bësh dikë tjetër owner është transferim i hapësirës së punës; këtu nuk ka asnjë endpoint që e kryen një të tillë.
Pesë të tjerët pranojnë gjithçka: një listë të re lejesh, një përshkrim të ri, një emër të ri, një DELETE. Ata janë parazgjedhje fillestare dhe jo pajisje fikse: një hapësirë pune që nuk ndërton kurrë një integrim duhet të mund të heqë qafe Developer, dhe një tjetër ku “Member” do të thotë diçka më e ngushtë duhet të mund ta thotë me fjalët e veta. Vetëm owner-i refuzon, dhe i refuzon të gjitha nën një kod të vetëm: role_immutable, një 409 që mbart param: "roleId", qoftë kur PATCH-i mbante një emër, qoftë një listë lejesh. Asnjë riemërtim nuk refuzohet më më vete, prandaj nuk ka pandryshueshmëri me param: "name" për t'u trajtuar; i vetmi 409 që mund të ngrejë ende një emër është role_name_taken, kur një rol tjetër i hapësirës së punës i përgjigjet tashmë atij.
Përtej të gjashtëve, një hapësirë pune shkruan deri në 24 role të vetat. Tavani numëron vetëm ato, prandaj fshirja e një roli fillestar nuk blen vend nën të. Lejet ZGJEROHEN gjatë hyrjes në vend që të merren fjalë për fjalë (templates:write i vetëm ruhet si templates:read dhe templates:write), prandaj lexojeni listën prapa nga përgjigjja në vend që të supozoni se është ajo që dërguat.
Një rol është gjithashtu tavani i një çelësi API. Një çelës i lëshuar kundrejt tij mund të bëjë key.scopes ∩ role.permissions dhe asgjë më, e zgjidhur për çdo kërkesë te kufiri, prandaj redaktimi i një roli ndryshon atë që mund të bëjnë çelësat e tij që në thirrjen e tyre të radhës, ndërsa një çelës pa rol nuk ka fare tavan. Faqja Scopes e ka të tërën.
Shembull
Kërkon roles:read. Pa kursor. Zarfi mbart hasMore dhe nextCursor që një klient t'ia japë të njëjtit kod liste si çdo koleksion tjetër, dhe nuk ka kurrë faqe të dytë.
curl "$OE/roles" -H "$AUTH"{ "object": "list", "data": [ { "object": "role", "id": "role_1c94e05d3862c1f0a44b7f3a", "name": "Owner", "description": "The person the workspace belongs to. Holds everything, including additions.", "permissions": ["emails:send", "emails:read", "…", "workspace:manage"], "builtin": "owner", "editable": false, "deletable": false, "members": 0, "apiKeys": 2, "createdAt": "2026-08-01T09:00:00.000Z", "updatedAt": "2026-08-01T09:00:00.000Z" }, { "object": "role", "id": "role_c40a95f21cc65d31c2a89e07", "name": "Viewer", "description": "Reads the mail on the addresses they hold, and changes nothing.", "permissions": [ "emails:read", "drafts:read", "threads:read", "labels:read", "contacts:read", "calendar:read", "templates:read", "rules:read", "connections:read", "settings:read" ], "builtin": "viewer", "editable": true, "deletable": true, "members": 3, "apiKeys": 1, "createdAt": "2026-08-01T09:00:00.000Z", "updatedAt": "2026-08-01T09:00:00.000Z" } ], "hasMore": false, "nextCursor": null}I renditur sipas rangut të integruar e më pas sipas emrit (owner, admin, member, viewer, developer, billing, pastaj të tjerët sipas alfabetit) dhe jo më i riu i pari si pjesa tjetër e API-t. Një matricë lejesh lexohet si një shkallë, dhe renditja e saj sipas createdAt e vendos rolin më të gjerë në një rresht tjetër çdo javë.
Leximi i kësaj liste është ai që i KRIJON fillimisht të gjashtë rolet në një hapësirë pune që nuk ka pasur asnjë. Krijimi fillestar bie ndesh me një indeks unik dhe nuk bën asgjë herën e dytë, prandaj thirrja është idempotente dhe vetëm e para shkruan, që është edhe arsyeja pse POST /members mund të emërtojë gjithmonë një roleId që ekziston.
Krijimi fillestar ndodh NJË HERË. Hapësira e punës e regjistron se është krijuar fillimisht, prandaj ky lexim plotëson një hapësirë pune më të vjetër se veçoria dhe më pas nuk shkruan më kurrë, gjë që e bën të përhershme fshirjen e një roli fillestar. Një build i mëparshëm rifuste çdo rresht shablloni që mungonte në çdo lexim, prandaj një Billing i fshirë kthehej nën një id të ri në ngarkimin e radhës të faqes; kjo nuk ndodh më.
members dhe apiKeys janë ato që do të duhej të zhvendoseshin përpara se roli të mund të ikte, gjë që i lejon një klienti të paralajmërojë përpara se të ofrojë fshirjen, jo pas 409-s. Rreshti i owner-it zakonisht lexon members: 0: owner-i nuk është anëtar i hapësirës së vet të punës, ai është llogaria me të cilën ajo është çelësuar.
Ka një tavan të fortë prej 24 rolesh të personalizuara pikërisht që kjo të jetë një përgjigje e vetme. Një hapësirë pune me dyzet role nuk mund t'i përgjigjet pyetjes “kush mund të dërgojë si billing@” thjesht duke parë, dhe kjo është e vetmja pyetje për të cilën ekziston kjo veçori.