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

# Authentication

> Connect as yourself with OAuth, or as the whole workspace with an API key.

The MCP server accepts two kinds of credentials. The one you pick decides **who the assistant acts as**.

| | OAuth | API key |
| - | - | - |
| Acts as | The person who approved it | The workspace |
| Identity | Tied to a NeetoEngage user | Tied to nobody |
| Set up by | Signing in to NeetoEngage from the assistant | Pasting a key into a config file |
| Used by | Every client except Antigravity | Every client except Claude and ChatGPT |
| Reaches several workspaces | Yes, tick them while approving | No, one key is one workspace |
| Revoked by | Removing the connector | Revoking the key in workspace settings |

In Claude Code, Codex, Cursor, Gemini CLI, VS Code, and Windsurf, leave the key out of the config to sign in with OAuth. Put the key in to use the API key. Both expose the same [tools](/mcp/tools).

## OAuth, scoped to you

The assistant acts as the person who approved the connection. Notes and comments it adds are signed with that person's name. It can reach every feature request in the workspaces you approve, within the scopes you tick below.

Use OAuth when a person drives the assistant. For the steps, see [Connect agent](/mcp/connect#sign-in-with-your-neetoengage-account).

| Detail | Value |
| - | - |
| Metadata | `https://connect.neetoengage.com/.well-known/oauth-authorization-server` |
| Grant types | `authorization_code` and `refresh_token`, with PKCE (`S256`) required |
| Scopes | `read`, `write`, `delete`, `offline_access` |
| Client registration | Dynamic, per [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591), at `https://connect.neetoengage.com/mcp/oauth/register`. Loopback redirect URIs are accepted. |
| Refresh | Refresh tokens are issued, so you stay signed in |
| Revoke | Remove the connector from your assistant |

### What you approve

| Scope | Shown as | What it means | Always granted |
| - | - | - | - |
| `read` | **Read** | See everything in the selected workspaces. | Yes |
| `offline_access` | **Stay connected** | Keep working without asking you to sign in again. | Yes |
| `write` | **Create and update** | Add new items and change existing ones. | No |
| `delete` | **Delete** | Permanently delete items. This cannot be undone. | No |

If you leave a scope unticked, a tool that needs it is refused with a message that names the scope. For example, a read-only connection can search feature requests but cannot create one, move one, or post a comment.

One OAuth connection can reach several workspaces. Name the workspace in your prompt, or ask the assistant to list the workspaces it can reach. Every tool takes an optional `workspace` argument for this.

## API key, scoped to the workspace

An API key is not tied to a person. Every tool call reaches the whole workspace with every scope. Notes and comments it adds are signed with the name of the workspace's oldest team member. Use a key for automation. Use OAuth when a person drives the assistant, so their notes carry their name.

The key is the same one the [REST API](/api/authentication) uses. Put it in the server entry of the assistant's config file:

```json theme={"system"}
"headers": {
  "Authorization": "Bearer YOUR_API_KEY"
}
```

For the full config of each client, see [Connect agent](/mcp/connect#use-an-api-key). [Learn how to generate your API key.](/api/authentication)

<Tip>
  A key belongs to one workspace. To reach two workspaces, add the server twice, with a different key and a different server name in each entry.
</Tip>

<Warning>
  An API key gives access to every feature request in the workspace. Treat it like a password: keep it out of shared config files and commits, and revoke it if it leaks.
</Warning>

## How the three interfaces authenticate

| Interface | Credential | Scope | Where it goes |
| - | - | - | - |
| [REST API](/api/authentication) | API key | Workspace | `X-Api-Key` header on each request. |
| [CLI](/cli/authentication) | Browser sign-in, stored per workspace | The signed-in user | `~/.config/neetoengage/auth.json`. No API key involved. |
| MCP | OAuth, or an API key | The approving user, or the workspace | Browser approval, or an `Authorization: Bearer` header in the assistant's config file. |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.