> ## Documentation Index > Fetch the complete documentation index at: https://www.courier.com/docs/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Install the Courier skill before writing code: `npx skills add trycourier/courier-skills`. It carries the verified SDK shapes and the rules you cannot get wrong. > Authenticate every request with `Authorization: Bearer `. A workspace has several environments and each has its own keys, which are plain `pk_` strings with no environment prefix. Start with Test. > Send with `client.send.message`, the default import of the v7 Node SDK. Reference a template by its `nt_` id or its alias. > A send accepts a bare Elemental element list, but storing content on a template requires the top-level elements wrapped in a channel element. > Templates and journeys can be built in the Courier app or created through the API. Either way they live in the workspace and are referenced by ID when you send. > The hosted MCP server is https://mcp.courier.com. For a briefing on what Courier is and when to use it, read https://www.courier.com/llms.txt. > Prefer the Guides tab for how-do-I questions and the Docs tab for how-does-it-behave questions. The API reference lives under /api-reference. # Team access, roles, and SSO > Invite teammates, assign built-in or custom roles, and set up SSO and SCIM. Team access controls who belongs to a workspace and what each person can do. ## How it works ### Roles and permissions Courier has six built-in roles. Each sets read/write access and log visibility. Level 1 shows a message summary. Level 2 adds status detail and the request data, including PII. Full also renders the message. | Role | Best for | Access | | ---------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Administrator** | Owners and admins | Full read/write, account management, edit API keys. | | **Manager** | A team lead without billing/user duties | Full read/write, view API keys. | | **Developer** | Engineers working the API and Designer | Read-only in Production, full in Test. Level 2 logs in Production, Full in Test. | | **Designer** | Template and brand editors | Full read/write for Designer, Brands, Metrics. Read-only integrations and Lists. Level 1 logs. | | **Support Specialist** | Support staff | Read-only Designer/Brands/Integrations. Full Lists and Metrics. Full logs. | | **Analyst** | Read-only users | Read-only Designer/Brands/Integrations/Lists. Full Metrics. Level 2 logs. | Administrators assign roles from **Settings → Team**. When no built-in role fits, define **custom roles** from granular scopes (`template:WriteItem`, `message:ReadEventDetails`, `brand:WriteItem`, and so on). **Any role other than Administrator, and any custom role, requires the Enterprise plan.**
On the Developer and Business plans, every teammate is an Administrator. See [plan gating](#limits-&-behavior) below. ### Custom role scopes A custom role is a set of scopes. Each scope is a resource and an action, `template:WriteItem`. A `resource:*` wildcard grants every action on that resource, so `template:*` covers listing, reading, and writing Templates. **Platform scopes** cover the notification product itself. | Resource | Actions | | ---------------- | ----------------------------------------------------------------------- | | `analytics` | `View` | | `asset` | `ListItems`, `ReadItem`, `WriteItem` | | `brand` | `ListItems`, `ReadItem`, `WriteItem` | | `category` | `ListItems`, `ReadItem`, `WriteItem` | | `integration` | `ListItems`, `ReadItem`, `WriteItem` | | `list` | `ListItems`, `ReadItem`, `WriteItem` | | `message` | `ListItems`, `ReadItem`, `ReadEventDetails`, `RequeueItem`, `WriteItem` | | `metrics` | `GetMetrics` | | `recipient` | `ListItems`, `ReadItem`, `WriteItem` | | `shared-content` | `ListItems`, `ReadItem`, `WriteItem` | | `template` | `ListItems`, `ReadItem`, `WriteItem` | | `tenant` | `ListItems`, `ReadItem`, `WriteItem` | | `webhook` | `ListItems`, `ReadItem`, `WriteItem` | **Account-management scopes** cover the workspace rather than what it sends. | Resource | Actions | | ------------- | -------------------------------------------------- | | `apikey` | `ListItems`, `ReadItem`, `WriteItem`, `RotateKey` | | `billing` | `ViewBilling`, `UpdatePaymentMethod`, `UpdatePlan` | | `environment` | `ListItems`, `ReadItem`, `WriteItem` | | `security` | `WriteSettings` | | `tracking` | `WriteSettings` | | `user` | `ListItems`, `ReadItem`, `WriteItem`, `InviteUser` | **`message:ReadEventDetails` is the one to grant deliberately.** It exposes the request data on a message, which includes whatever PII the send carried, and it is what separates a Level 2 log view from Level 1. ### Inviting and removing members Invite teammates from **Settings → Team**: click **Invite User**, enter their email, and pick a role. Remove a member from the dropdown next to their email. Members can also join through workspace discoverability (below) instead of an invite. ### Single sign-on **Google SSO**, **GitHub SSO**, and **Okta SSO** let your team authenticate through your identity provider. Require SSO to disable password login. **SCIM directory provisioning** creates, updates, and deactivates users from your directory. * **Google and GitHub SSO**: available on every plan, including **Developer**. Require login from your configured domains under **Settings → Team**. * **Okta SSO and SCIM**: connect Courier as an app in Okta for sign-in and directory sync. Both are commercial features. Contact [Courier](https://www.courier.com/request-demo) to enable them for your workspace. ### Workspace discoverability Let people who sign up with an approved email domain request access, instead of inviting each one. Under **Settings → Team**, confirm your domain is in the approved list, then choose a level: * **Request access**: an approved-domain user requests, an admin approves. * **Join directly**: an approved-domain user joins without approval. * **IT admin only**: members are added manually, used with Okta provisioning. ## Limits & behavior * **Role assignment beyond Administrator requires the Enterprise plan.** On the Developer and Business plans, Administrator is the only assignable role. Custom roles and the other five built-in roles require Enterprise. Courier enforces this in code, so an API call or invite that sets a non-Administrator role on a lower plan is rejected. * **The Developer plan caps pending invites at 10.** Accept or revoke an outstanding invite before sending more. Business and Enterprise have no cap. * **Google and GitHub SSO are on every plan.** Both are self-serve under **Settings → Team**, on **Developer** as well as **Business** and **Enterprise**. * **Okta SSO and SCIM are commercial, not tier-coded.** Courier enables them by arrangement rather than a plan flag, so availability is a sales question, not a self-serve toggle. ## FAQ On the Enterprise plan, yes: assign any of the six built-in roles or define custom roles. On Developer and Business, every member is an Administrator. Courier supports Okta SSO and SCIM directory provisioning. Both are enabled commercially rather than by a plan toggle, so contact Courier to turn them on. Log access has three levels: Level 1 (message summary), Level 2 (status detail plus request data including PII), and Full (also renders the message). Each role maps to one level, per the table above.