Who can use the API

Which people on your account can create API keys and reach Goosy Bear programmatically, and what changes it.

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 do none of the making — so they have no programmatic access.

Changing who has it

It follows the role. Move someone between Member and Admin and their programmatic access comes with them; move them to Client and it goes.

There is no per-person switch for it on the members list. That list does carry per-person switches — Configure automations and Manage connections — but API access is not one of them, so a role change is what changes this.

A role 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 under Settings → API & MCP, 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, holding exactly the permissions that integration needs. Where your account has an active one, an account Owner sees it in the Holder list when creating a key, and mints its keys on Settings → API & MCP, listed with the Owner’s own keys — other roles mint keys for themselves only and see only their own, so the service account won’t appear in their list. Setting one up is not yet something you do from the app: if an Owner’s Holder list shows only people, the account has no active service account. See Service accounts.

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 account-wide switch is open, but this person’s role does not include Use the API and MCP. A client never has it; changing their role is what changes this.
• 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.