Listar miembros
Todas las personas del espacio de trabajo, el rol que tiene cada una y las direcciones que se le concedieron.
Ejecuta la llamada real contra tu espacio de trabajo, con tu propia clave.
GET /members
Todas las personas del espacio de trabajo, el rol que tiene cada una y las direcciones que se le concedieron.
Un miembro son dos concesiones, no una
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"role es lo que PUEDE HACER: una fila, un rol, el mismo objeto que describe /roles. addresses es SOBRE QUÉ puede hacerlo: una entrada por dirección, cada una con su propio access. Un cliente no debe fusionarlos: un rol con emails:send y un array addresses vacío es alguien que no puede enviar desde ninguna dirección, y un array addresses lleno bajo un rol de viewer es alguien que tampoco puede enviar desde ninguna. La ruta de envío comprueba ambos, y una pantalla que muestre solo uno explicará con total seguridad el rechazo equivocado.
Las filas de direcciones dicen access donde la columna almacenada dice role, y el cambio de nombre es lo importante, no una simple limpieza: este objeto ya tiene un campo role que significa algo completamente distinto, y dos role separados por un nivel de anidamiento con valores de dos vocabularios diferentes son un error esperando a la primera persona que lo lea deprisa. access es member, que lee la dirección y envía como ella, o viewer, que solo la lee.
implied: true significa que NADIE ELIGIÓ ESTE ROL. El uso compartido se lanzó mucho antes que los roles, así que la mayoría de las personas con acceso a un buzón tienen concesiones de dirección y ninguna fila de miembro; en lugar de negarles su correo hasta que se ejecute un backfill, el servicio infiere un rol integrado a partir de la concesión más amplia que tengan y lo informa con role.id en null. Muéstralo como «implícito por el acceso» y no como un rol que alguien eligió. Hasta que un PATCH convierta la inferencia en una decisión, ampliar su acceso a direcciones amplía en silencio lo que puede hacer.
El PROPIETARIO es la PRIMERA fila, marcada con isOwner: true y con role.builtin igual a owner. Es la cuenta sobre la que está indexado el espacio de trabajo, tiene todos los permisos por definición, y POST, PATCH y DELETE lo rechazan con member_is_owner. Por eso un espacio de trabajo sin compartir informa de un miembro y no de ninguno. Cuenta las licencias excluyendo isOwner.
Ejemplo
Requiere members:read. El propietario va primero y después todos los demás por correo electrónico, y no por fecha de incorporación, porque esta lista se lee para encontrar a una persona y no para ver qué ha cambiado.
curl "$OE/members" -H "$AUTH"{ "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}Dos poblaciones en una sola lista, y tiene que ser así: alguien puede tener un rol y ninguna dirección, y alguien puede tener una dirección y ninguna fila de rol. Listar solo la intersección ocultaría a ambas, y en la mayoría de los espacios de trabajo el segundo grupo es el más numeroso.
createdAt es null para alguien que tiene concesiones pero para quien nunca se escribió una fila de miembro, las mismas personas para las que implied es true. Indica cuándo se le dio un ROL, no cuándo se le compartió una dirección por primera vez.
permissions es la lista plana ya resuelta y no un conjunto de booleanos. Un cliente que pregunta «¿esto incluye templates:write?» no puede quedarse atrás respecto al vocabulario; un cliente al que se le entrega { canEditTemplates: true } sí puede, y en silencio.
Sin cursor, con el sobre estándar. La membresía de un espacio de trabajo está acotada por el número de personas con las que su propietario lo ha compartido realmente, y paginarla sería pura ceremonia delante de algo que un cliente obtiene una vez y representa entero.