Llista els rols
Tots els rols de l'espai de treball, primer els integrats, amb quantes persones i quantes claus tenen cadascun.
Executa la crida real contra el teu espai de treball, amb la teva pròpia clau.
GET /roles
Tots els rols de l'espai de treball, primer els integrats, amb quantes persones i quantes claus tenen cadascun.
Dos eixos, i no són la mateixa pregunta
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Un ROL diu què pot FER algú en aquest espai de treball: llegir correu, enviar-lo, editar plantilles, afegir un domini. Una CONCESSIÓ diu a quines ADRECES ho pot fer, i viu al costat, a /members/{userId}/addresses, com a member (llegeix l'adreça i hi envia com a tal) o viewer (només la llegeix). Tots dos s'han de posar d'acord abans que surti un missatge: un rol que té emails:send sense cap concessió pot enviar des de res, i totes les adreces de l'espai de treball sota una concessió de viewer també poden enviar des de res.
Tots els espais de treball se sembren amb els mateixos sis rols. Owner, Admin, Member i Viewer formen una escala. Cadascun té tot el que té el següent, de manera que degradar algú li estreny l'accés en comptes de canviar-l'hi per una porció diferent. Developer i Billing no en són esglaons: Developer construeix integracions (claus, webhooks, plantilles, enviament) i no llegeix gens del correu de l'espai de treball, i Billing veu el pla i les factures i res més. Tots dos queden estrictament dins d'Admin. Se sembren a la primera lectura i no en crear l'espai de treball, de manera que un espai de treball fet abans que existís aquesta funcionalitat els obté en el moment que alguna cosa els demana. builtin anomena de quina sembra prové una fila, i això és tot el que anomena: els sis són un punt de partida que un espai de treball ha de modelar, i tots menys Owner es poden reanomenar, canviar de permisos i eliminar. Ramifica segons editable i deletable i no segons el nom: un rol que algú ha reanomenat continua responent correctament aquests dos, i el seu nom ja no et diu res.
Owner és l'única excepció, i ho és en totes direccions: editable: false, deletable: false, i rebutjat com a destinació a PATCH /members/{userId}. Descriu el compte al qual està vinculat l'espai de treball i té tots els permisos, inclosos els que s'afegeixin en una versió posterior, i per això la seva llista es calcula en comptes d'emmagatzemar-se. Fer propietari algú altre és una transferència de l'espai de treball; aquí no hi ha cap endpoint que en faci cap.
Els altres cinc ho accepten tot: una llista de permisos nova, una descripció nova, un nom nou, un DELETE. Són valors per defecte sembrats i no peces fixes: un espai de treball que no construeix mai cap integració hauria de poder desfer-se de Developer, i un on «Member» vol dir una cosa més estreta hauria de poder dir-ho amb les seves paraules. Només el propietari s'hi nega, i s'hi nega del tot sota un sol codi: role_immutable, un 409 amb param: "roleId", tant si el PATCH portava un nom com una llista de permisos. Ja no es rebutja cap canvi de nom pel seu compte, de manera que no hi ha cap immutabilitat amb param: "name" a gestionar; l'únic 409 que encara pot provocar un nom és role_name_taken, quan un altre rol de l'espai de treball ja hi respon.
Més enllà dels sis, un espai de treball escriu fins a 24 rols propis. El sostre només compta aquests, de manera que eliminar un rol sembrat no guanya espai per sota. Els permisos s'EXPANDEIXEN en entrar en comptes de prendre's literalment (templates:write tot sol s'emmagatzema com a templates:read i templates:write), així que torna a llegir la llista de la resposta en comptes de suposar que és la que has enviat.
Un rol és també el sostre d'una clau d'API. Una clau emesa contra un rol pot fer key.scopes ∩ role.permissions i res més, resolt per petició a la frontera, de manera que editar un rol canvia el que poden fer les seves claus a la crida immediatament següent, i una clau sense rol no té cap sostre. La pàgina Scopes ho explica tot.
Exemple
Necessita roles:read. Sense cursor. L'embolcall porta hasMore i nextCursor perquè un client el pugui passar al mateix codi de llista que qualsevol altra col·lecció, i mai no hi ha una segona pàgina.
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}Ordenat per rang integrat i després per nom (owner, admin, member, viewer, developer, billing, i després la resta alfabèticament) i no pel més recent primer com la resta de l'API. Una matriu de permisos es llegeix com una escala, i ordenar-la per createdAt posa el rol més ampli en una fila diferent cada setmana.
Llegir aquesta llista és el que SEMBRA els sis en un espai de treball que no n'ha tingut mai cap. La sembra entra en conflicte amb un índex únic i no fa res la segona vegada, de manera que la crida és idempotent i només la primera escriu, cosa que també explica per què POST /members sempre pot anomenar un roleId que existeix.
Sembra UNA SOLA VEGADA. L'espai de treball registra que ja s'ha sembrat, de manera que aquesta lectura omple un espai de treball més antic que la funcionalitat i després no torna a escriure mai més, cosa que fa que eliminar un rol sembrat sigui permanent. Una versió anterior tornava a inserir qualsevol fila de plantilla que faltés a cada lectura, de manera que un Billing eliminat tornava amb un id nou a la càrrega de pàgina següent; això ja no passa.
members i apiKeys són el que caldria moure abans que el rol pogués caure, cosa que permet que un client avisi abans d'oferir l'eliminació i no després del 409. La fila del propietari normalment diu members: 0: el propietari no és membre del seu propi espai de treball, és el compte al qual està vinculat.
Hi ha un sostre dur de 24 rols personalitzats precisament perquè això pugui ser una sola resposta. Un espai de treball amb quaranta rols no pot respondre «qui pot enviar com a billing@» només mirant, que és l'única pregunta que aquesta funcionalitat existeix per fer que es pugui respondre.