> ## Documentation Index
> Fetch the complete documentation index at: https://docs.goosybear.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Who can use the API

> Which people on your account can create API keys and reach Goosy Bear programmatically, and how an owner grants or removes that.

Programmatic access is a permission like any other on your account, called
**Use the API and MCP**. It decides who can create keys and who can call your
account from outside the app.

## Who has it by default

People on your account hold one of four roles. By default:

| Role   | Can use the API |
| ------ | --------------- |
| Owner  | Yes             |
| Admin  | Yes             |
| Member | Yes             |
| Client | No              |

Clients are the guest role — they see the work you share with them and nothing
else — so they have no programmatic access unless an owner deliberately gives
it to one person.

## Granting or removing it for one person

An owner or admin changes it per person under **Settings → Members &
invites**. Turning it on for a client, or off for a member, is a per-person
exception that stays visible in the member list, so nobody has to remember who
was given what.

The change takes effect on that person's very next call. You do not need to
re-issue their keys, and you do not need to wait.

## Switching it off for the whole account

Programmatic access can also be switched off for the whole account. That stops
every key at once, whoever made it — the right move if you suspect a key has
leaked and you would rather close the door than hunt for it. An owner or admin
turns it back on in the account settings, and every key that was not revoked
starts working again on its next call.

## A key never exceeds its holder

Permission to use the API is the door, not the whole house. Inside, a key can
only do what the person who created it can do:

* If someone cannot approve content in the app, their key cannot approve it.
* If someone is removed from a workspace, their key stops reaching that
  workspace on the next call.
* If someone leaves the account, their keys go with them.

That last point is why anything shared should run on a **service account**
instead — an identity that belongs to the account rather than to a person. An
owner sets one up and gives it exactly the permissions that integration needs;
its keys are then minted and listed on **Settings → API & MCP** like anyone
else's. Switching the service account off stops its keys on their next call.

## Actions that still stop for a person

Some things are gated by consequence, not by role. Anything that publishes,
spends money, deletes, or hands out access stops for an explicit human
decision, whatever permissions the caller holds — and that is as true of an
assistant acting on your behalf as it is of you.

## Reading a refusal

A refused call says which of these applies:

* **Programmatic access is turned off for the whole platform** — a system-wide
  setting on our side, not something on your account. Nothing you change will
  reopen it; contact support.
* **Programmatic access is turned off for this account** — the account-wide
  switch above. An owner or admin can turn it back on.
* **You do not have permission to use this account programmatically** — the
  switches are open, but this person does not hold **Use the API and MCP**. An
  owner or admin can grant it under Settings → Members & invites.
* **This account is not enabled for the API and MCP surface yet** — the feature
  is not open for your account. This is about the platform, not your key or
  your permissions.