# Scopes

A key carries scopes written `resource:action`. Give each integration only what it uses. `GET /v2/scopes` returns this same list. A key can only issue keys with scopes it already has.

| Scope | Allows |
| --- | --- |
| `knowledge:read` | See which knowledge collections exist and which documents each one has. It cannot change them. |
| `conversations:resolve` | Report that an escalation was resolved and close the conversation. |
| `conversations:send` | Send a message to the person in a conversation from your number, signed with the key's author name, without running the agent. It does not write while the agent is handling an open case, and on WhatsApp it cannot send more than 24 hours after the person's last message. |
| `conversations:annotate` | Leave an internal note in a conversation, signed with the key's author name. Only your team sees it: it never reaches the person or the agent. |
| `conversations:read` | Read a conversation and its message history. |
| `agents:converse` | Open a conversation with an agent and talk to it. The agent answers and runs its tools. |
| `knowledge:write` | Change what the agent knows: create collections, assign them to agents or remove them, and add, replace and delete documents. |
| `agents:write` | Create agents from a template, detach a template, activate and pause agents. It cannot grant new actions: that is actions:write. |
| `agents:internal` | Create internal agents (copilots) that answer your team and read the data connector of your back office. A copilot created this way is then managed with the usual agent, action and case scopes. It never reaches the assistant of the owner, which the API does not expose. It is a sensitive scope: a copilot reads personal data of your customers through its tools. |
| `agents:read` | See how an agent is configured: prompt, model, channels and actions. It cannot change anything. |
| `conversations:write` | Write into a case the data your system already has, only in fields marked as filled by a connector. |
| `conversations:route` | Move a case to another pipeline. It changes which team sees it and who handles it. |
| `actions:read` | See which actions exist, which ones each agent is granted and the origin each action calls (scheme, host and port). It cannot see the full address or its credentials. |
| `actions:write` | Grant and remove actions on an agent. It is a sensitive scope: an HTTP action sends the data of your contacts to the system it points at. Give it only to integrations you already run. |
| `events:write` | Report that something happened in your system, which can make an agent write first to that person if a trigger is waiting for it. It does not choose what is said: the text comes from the trigger. |
| `triggers:read` | See your triggers: which fact each one answers, with which agent and which text. It cannot change anything. |
| `triggers:write` | Create, edit and pause triggers, which decides what the agent tells your users. Give it only to whoever manages the content. |
| `runs:write` | Assign an agent a job that runs unattended until it finishes, using any action the agent is granted, including the ones that write. It can also cancel a job and answer a job that asked something. The job runs as the person the key declares, or as the key itself: give it only to systems you already run. |
| `runs:credencial` | Assign jobs without the signature of a user of your system: the job carries a credential that your system issues and checks, and it runs with no user. Actions of the agent that do not go through your system run anyway at organization level; an MCP server that does not forward the credential is never called. Goes with runs:write. It cannot be chosen when creating a key: Lelemon grants it to the integration that issues those credentials. |
| `runs:read` | See how a job is going: its status, what it has spent and what the agent declared when it finished. It cannot create or cancel jobs. |
| `schedules:read` | See the scheduled tasks of your agents: when each one fires, for whom and what it asks the agent to do. It cannot create, change or delete them. |
| `schedules:write` | Create, edit, pause and delete scheduled tasks. On each date the agent starts a job on its own and can write to the contact by email, so give it only to systems you already run. |
| `scheduling:read` | See the agendas, their free slots to build your own grid, and the meetings booked in them with the name, email and phone of each attendee. It does not see what fills the busy slots or whose calendar it is. It cannot book, move or cancel. |
| `scheduling:write` | Book a slot, move a meeting and cancel it: an event is created, changed or deleted in the calendar of a team member and the attendee gets the invitation or the notice. It occupies the agenda of a person, so give it only to systems you already run. |
| `scheduling:configure` | Create and edit agendas: opening hours, meeting length, buffers and how far ahead people can book. It decides when the calendars of your team can be booked, so give it only to systems you already run. It does not book meetings. |
| `skills:read` | See the skills of an agent: which instructions it has and what each one says. It cannot change them. |
| `skills:write` | Write the skills of an agent: create, edit and delete the instructions it follows for each task. |
| `pipelines:write` | Create, change and delete pipelines with their stages, fields and routing rules, and replace the options of the list fields of a pipeline and its quick replies. It changes how conversations move, what the agent offers and the texts the team sends under their name. |
| `pipelines:read` | See pipelines, their stages, fields and routing rules. It cannot change anything. |
| `miembros:read` | Availability of one team member, looked up by email: available or away. It does not see their name, role or cases. It belongs to the v1 availability routes; v2 uses members:read and members:write. |
| `miembros:write` | Set one team member as available or away, looked up by email. It changes who receives new cases, as if the person pressed their own button. It does not change their role or pipelines. It is the writing side of miembros:read, used by the v1 availability routes; v2 uses members:write. |
| `teams:read` | See the teams of the organization: their members with name and email, their pipelines and how many cases wait in the queue. It cannot change them. |
| `teams:write` | Create, edit, merge and delete teams, and assign members and pipelines to them. It decides who receives the cases of a pipeline. |
| `members:read` | List the active members of the organization with name, email, role and availability, to find the id that assigns a case, and read whether one of them is available for the assignment. It cannot invite, change roles or set availability: that is members:write, which only sets availability. |
| `members:write` | Set one team member as available or away, by the id of the member. It changes who receives new cases, as if the person pressed their own button. It does not change their role or pipelines, and it does not include members:read. |
| `members:manage` | Change the role of a member and remove a member from the organization. The role it can give, and whose role it can change, is capped by the current role of whoever issued the key: an admin works on members and viewers, the owner up to admin, and nobody changes, removes or names an owner. Removing someone also leaves without power the keys they issued. It does not include members:read. |
| `members:audit-read` | Read the audit log of members: who invited, resent or cancelled an invitation, changed a role or removed a member, with the email of the person affected. It cannot change anything. It needs an admin or owner as the issuer of the key. |
| `invitations:read` | List the invitations of the organization with their status (pending, accepted, expired or cancelled), email, role and who invited. It cannot invite, resend or cancel. It needs an admin or owner as the issuer of the key. |
| `invitations:write` | Invite people, resend and cancel invitations. The role it can give is capped by the current role of whoever issued the key: an admin invites member or viewer, the owner up to admin, nobody as owner. It does not include invitations:read. |
| `subaccounts:read` | See the subaccounts of your platform. It cannot change anything. |
| `subaccounts:write` | Create, rename and delete subaccounts, and give them keys of their own. Each subaccount is a child organization that your platform pays for, so give it only to systems you already run. |
| `whatsapp:read` | See WhatsApp connection links and connected phone numbers, with the agent that answers on each one. It cannot change anything. |
| `whatsapp:write` | Create and revoke WhatsApp connection links, change the agent of a phone number, turn it off and disconnect it. |
| `email:read` | See the sender domains of the organization with their verification status and DNS records, and the emails sent and received. It cannot change anything. |
| `email:write` | Add, verify, change and remove sender domains, and send an email that opens a case. It decides the address people see as the sender, so give it only to systems you already run. |
| `contacts:read` | See the contacts of the organization: name, email, phone and external reference. It cannot change anything. |
| `contacts:write` | Create and edit contacts, and set an external reference on them so they are not duplicated. It does not open or close cases. Erasing a contact is contacts:erase, opt-outs are opt-outs:write and contact fields are contact-fields:write. |
| `contacts:erase` | Erase (anonymize) a contact when the person asks. The contact, its cases, messages, files and agent memory lose their content, and it cannot be undone. An admin or owner as the issuer of the key can hold it, as in the panel. |
| `opt-outs:write` | Opt a contact out of a channel and clear an opt-out, which decides who gets written to. An admin or owner as the issuer of the key can hold it, as in the panel. |
| `contact-fields:write` | Create, edit and delete the custom contact fields of the organization. It is configuration: an admin or owner as the issuer of the key can hold it, as in the panel. |
| `companies:write` | Create, edit and delete companies. Deleting a company does not delete its contacts: they stay and lose the company. Reading companies is contacts:read. Linking a contact to a company is contacts:write. |
| `lead-forms:read` | See the lead forms of the organization: name, pipeline, tags, source, status and the visible prefix of the key. It never returns the key itself. It cannot change anything. |
| `lead-forms:write` | Create, edit and delete lead forms. Creating one returns the key the website sends with each lead, shown only once. It decides which pipeline the leads of a website enter, so give it only to systems you already run. |
| `contacts:presence` | Report that your users are active or have gone offline in your app, in batches. It reads nothing back: it only tells Lelemon who is online. |
| `presence:configure` | Read and change the presence settings: turn the who-is-online signal on or off. An admin or owner as the issuer of the key can hold it, as in the panel. |
| `contacts:presence-read` | See whether a contact is online and when it was last seen, and filter contacts and cases by the ones online. It cannot change anything. |
| `connectors:read` | See your data connectors and read live through them: the manifest, account cards, searches and views. Sensitive values and anything shaped like a RUT, email or phone come back masked. Every read is audited. It cannot change a connector or reveal a masked value. |
| `connectors:write` | Register, edit, check and delete data connectors, and read and rotate the secret that signs the calls to your system. It is a sensitive scope: a connector receives requests from Lelemon for your account data. |
| `connectors:reveal` | Reveal one masked value of an account card. Every reveal is audited with the key that made it. Fields marked as special category cannot be revealed. |
| `connectors:audit-read` | Read the audit of who looked at which account, view and field through your data connectors. It never holds the values, and accounts are stored as keyed hashes. |
| `cases:read` | See cases, their notes and their attachments, and download the files. It cannot change anything. |
| `cases:write` | Open, move between stages of the same pipeline, assign, close and reopen cases, and add notes and files to them. Assigning follows the panel rule: a member only assigns to people of their team. It does not delete, archive or reorganize cases (cases:delete and cases:reorganize) and it never writes to the person on any channel. |
| `cases:delete` | Delete, archive and unarchive cases, and redact the content of a case message. An admin or owner as the issuer of the key can hold it, as in the panel. |
| `cases:reorganize` | Move cases in batch and move a case to another pipeline. An admin or owner as the issuer of the key can hold it, as in the panel. |
| `cases:send` | Write to the person of a case as your organization, from your number or channel, signed with the name you send. It does not write while the agent is handling the case, and on WhatsApp it cannot send more than 24 hours after the person's last message. Needs cases:write. |
| `cases:converse` | Write in a case as the contact, which makes the agent answer and run its tools. It spends model tokens. Needs cases:write. |
| `cases:reveal` | Reveal the value of a field marked sensitive in a case. Every reveal is audited with the key that made it, and the audit never holds the value. Reading a case never returns it. |
| `webhooks:read` | See the webhook endpoints of the organization, their deliveries and the event catalog. It never returns the signing secret. |
| `webhooks:write` | Create, change and delete webhook endpoints, rotate their secret, send a test event and resend an event. It decides which URL receives the data of your conversations, so give it only to systems you already run. |
| `recipient-allowlist:read` | See the recipient allowlist: whether it is on and which phones, emails and domains it lets through. It cannot change anything. |
| `recipient-allowlist:write` | Turn the recipient allowlist on or off and replace its entries. While it is on, nothing is sent to anyone outside it. It is a protection, so give it only to systems you already run. |
| `organization:read` | See the name of the organization, its settings (business hours, inactivity closing, presence, branding) and its company profile. It cannot change anything. |
| `organization:write` | Rename the organization. Only the owner holds this power, so a key issued by anyone else cannot use it. |
| `settings:write` | Change the business hours, the inactivity closing, presence, branding and the company profile of the organization. Business hours decide when the agent answers, so give it only to systems you already run. |
| `approvals:read` | See the approvals of agent actions: the exact arguments, who may decide, who decided and why. It cannot change anything. |
| `approvals:write` | Approve or reject an action an agent proposed, only where the tool policy names this key. Approving runs the action for real: it can move money or write to a person. It is a decision power, so give it only to systems you already run. |
| `team-questions:read` | See the questions agents left for the team and their answers. It cannot change anything. |
| `team-questions:write` | Answer a question an agent left for the team. The agent resumes the conversation and tells the person with its own words. |
| `turns:read` | See the turns the agent took in a case: the tools it called with their input and output (masked by shape), the model and the tokens. Tool input and output can still carry data about the person, so give it only to systems you already run. It cannot change anything. |
| `usage:read` | See how many conversations, turns, messages and tokens your agents used per day, agent and model. It does not show prices. It cannot change anything. |
| `budgets:read` | See the monthly budgets of the organization, in conversations, and how many of each are used. It cannot change anything. |
| `budgets:write` | Create budgets and change their limit, alert threshold and what happens at the limit. Raising a limit makes a stopped agent answer again at once, so give it only to systems you already run. Needs budgets:read. |
| `files:read` | See the files the organization uploaded for its WhatsApp messages, campaigns and templates: name, type and size. It cannot upload or delete. |
| `files:write` | Upload and delete files. What you upload can go out through WhatsApp to your contacts under the name of the organization. Needs files:read. |
| `linear:read` | See the Linear team and project that receive the escalated cases and the webhook URL. It never shows the Linear API key or the signing secret. |
| `linear:write` | Connect and disconnect the Linear of the organization with its own API key, choose the destination team and save the webhook signing secret. Escalated cases are sent to that Linear with the contact and the last messages, so give it only to systems you already run. |