Bỏ qua tới phần tài liệu
API

Liệt kê vai trò

Mọi vai trò trên không gian làm việc, vai trò dựng sẵn trước, kèm số người và số khóa đang giữ mỗi vai trò.

GETapi.openemail.uk/roles

Chạy lệnh gọi thật với không gian làm việc của bạn, bằng khóa của chính bạn.

GET /roles

Mọi vai trò trên không gian làm việc, vai trò dựng sẵn trước, kèm số người và số khóa đang giữ mỗi vai trò.

Hai trục, và chúng không phải cùng một câu hỏi

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

VAI TRÒ cho biết ai đó được LÀM gì trong không gian làm việc này: đọc thư, gửi thư, chỉnh sửa mẫu, thêm tên miền. QUYỀN CẤP cho biết họ được làm điều đó với những ĐỊA CHỈ nào, và nằm ngay bên cạnh tại /members/{userId}/addresses dưới dạng member (đọc địa chỉ và gửi thư với tư cách địa chỉ đó) hoặc viewer (chỉ đọc). Cả hai phải đồng ý trước khi thư được gửi đi: một vai trò có emails:send mà không có quyền cấp thì không thể gửi từ đâu cả, và mọi địa chỉ trong không gian làm việc dưới quyền cấp viewer cũng không thể gửi từ đâu cả.

Mọi không gian làm việc được seed cùng sáu vai trò. Owner, Admin, MemberViewer tạo thành một bậc thang. Mỗi vai trò có mọi thứ mà vai trò kế tiếp có, nên hạ cấp ai đó sẽ thu hẹp quyền truy cập của họ thay vì đổi sang một phần khác. DeveloperBilling không phải bậc trên thang đó: Developer xây dựng tích hợp (khóa, webhook, mẫu, gửi thư) và không đọc thư nào của không gian làm việc, còn Billing thấy gói và hóa đơn và không gì khác. Cả hai đều nằm hoàn toàn bên trong Admin. Chúng được seed ở lần đọc đầu tiên thay vì khi tạo không gian làm việc, nên một không gian làm việc được tạo trước khi tính năng này tồn tại sẽ có chúng ngay khi có bất kỳ thứ gì yêu cầu. builtin cho biết một hàng đến từ bản seed nào, và đó là toàn bộ những gì nó cho biết: sáu vai trò là điểm khởi đầu mà không gian làm việc được kỳ vọng sẽ điều chỉnh, và mọi vai trò trừ Owner đều có thể được đổi tên, đặt lại quyền và xóa. Hãy rẽ nhánh theo editabledeletable thay vì theo tên: một vai trò đã bị đổi tên vẫn trả lời đúng hai trường đó, còn tên của nó không còn cho bạn biết gì nữa.

Owner là ngoại lệ duy nhất, và là ngoại lệ theo mọi hướng: editable: false, deletable: false, và bị từ chối làm đích trên PATCH /members/{userId}. Nó mô tả tài khoản mà không gian làm việc gắn với và có mọi quyền, kể cả những quyền được thêm trong bản phát hành sau, đó là lý do danh sách của nó được tính toán thay vì lưu trữ. Đưa người khác trở thành chủ sở hữu là chuyển nhượng không gian làm việc; không có endpoint nào ở đây thực hiện điều đó.

Năm vai trò còn lại chấp nhận mọi thứ: danh sách quyền mới, mô tả mới, tên mới, lệnh DELETE. Chúng là mặc định được seed chứ không phải cố định: một không gian làm việc không bao giờ xây dựng tích hợp nên có thể loại bỏ Developer, và một nơi mà “Member” mang nghĩa hẹp hơn nên có thể nói điều đó bằng từ ngữ của riêng mình. Chỉ owner từ chối, và từ chối tất cả dưới một mã: role_immutable, mã 409 kèm param: "roleId", dù lệnh PATCH chứa tên hay danh sách quyền. Không còn việc đổi tên nào bị từ chối riêng lẻ nữa, nên không có trường hợp bất biến param: "name" nào cần xử lý; mã 409 duy nhất mà một tên còn có thể gây ra là role_name_taken, khi một vai trò khác trên không gian làm việc đã dùng tên đó.

Ngoài sáu vai trò đó, một không gian làm việc có thể tự tạo tối đa 24 vai trò. Mức trần chỉ đếm các vai trò này, nên xóa một vai trò được seed không tạo thêm chỗ. Quyền được MỞ RỘNG khi nhập vào thay vì được hiểu theo nghĩa đen (chỉ templates:write sẽ được lưu thành templates:readtemplates:write), vì vậy hãy đọc lại danh sách từ phản hồi thay vì giả định đó là danh sách bạn đã gửi.

Vai trò cũng là mức trần cho một khóa API. Khóa được cấp theo một vai trò có thể làm key.scopes ∩ role.permissions và không hơn, được phân giải cho từng yêu cầu tại ranh giới, nên chỉnh sửa vai trò sẽ thay đổi những gì các khóa của nó được làm ngay ở lệnh gọi tiếp theo, và một khóa không có vai trò thì hoàn toàn không có mức trần. Trang Phạm vi có toàn bộ chi tiết về điều đó.

Ví dụ

Cần roles:read. Không dùng cursor. Envelope mang hasMorenextCursor để client có thể đưa nó vào cùng đoạn mã xử lý danh sách như mọi tập hợp khác, và không bao giờ có trang thứ hai.

curl
curl "$OE/roles" -H "$AUTH"
Phản hồi
{  "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}

Được sắp xếp theo thứ hạng dựng sẵn rồi theo tên (owner, admin, member, viewer, developer, billing, sau đó là phần còn lại theo bảng chữ cái) thay vì mới nhất trước như phần còn lại của API. Ma trận quyền được đọc như một bậc thang, và sắp xếp theo createdAt sẽ đặt vai trò rộng nhất ở một hàng khác mỗi tuần.

Việc đọc danh sách này là thứ SEED sáu vai trò trên một không gian làm việc chưa từng có vai trò nào. Việc seed xung đột trên một unique index và không làm gì ở lần thứ hai, nên lệnh gọi là idempotent và chỉ lần đầu tiên ghi dữ liệu, đó cũng là lý do POST /members luôn có thể chỉ định một roleId tồn tại.

Việc seed chỉ diễn ra MỘT LẦN. Không gian làm việc ghi nhận rằng nó đã được seed, nên lần đọc này điền vai trò cho một không gian làm việc cũ hơn tính năng rồi không bao giờ ghi nữa, đó là điều khiến việc xóa một vai trò được seed trở nên vĩnh viễn. Một bản build trước đây chèn lại bất kỳ hàng mẫu nào bị thiếu ở mỗi lần đọc, nên một Billing đã bị xóa sẽ quay lại với một id mới ở lần tải trang tiếp theo; giờ không còn như vậy nữa.

membersapiKeys là những gì phải được chuyển đi trước khi vai trò có thể bị xóa, nhờ đó client có thể cảnh báo trước khi hiển thị nút xóa thay vì sau lỗi 409. Hàng owner thường hiển thị members: 0: chủ sở hữu không phải là thành viên của chính không gian làm việc của họ, họ là tài khoản mà không gian làm việc gắn với.

Có mức trần cứng 24 vai trò tùy chỉnh chính là để điều này có thể nằm gọn trong một phản hồi. Một không gian làm việc với bốn mươi vai trò không thể trả lời “ai có thể gửi với tư cách billing@” chỉ bằng cách nhìn, mà đó là câu hỏi duy nhất tính năng này tồn tại để trả lời được.