# API authentication

There is no authentication on the public API. No key is issued, no header is read, and no endpoint in the published description accepts one. That is a property of what the API exposes — generated documentation that anonymous visitors already receive — rather than a setting somebody forgot to turn on.

- **Status:** Available
- **Audience:** developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/developers/api-authentication/

## What to send

```bash
# Correct. No header, no token, no cookie.
curl -sS 'https://connectbyjbrh.com/api/public/docs/status'

# Also works, and the header is simply not read.
curl -sS -H 'Authorization: Bearer anything' \
  'https://connectbyjbrh.com/api/public/docs/status'
```

The second form is worth knowing because it means a client library that insists on a credential will appear to work with a wrong one. Do not read that as proof your key is valid — nothing validated it. Prefer a client configuration of *no authentication* so no secret is stored for a call that does not use one.

The published description makes the same statement in machine-readable form: it declares no security schemes, and its own text says there is no authentication and there are no write operations.

## Where workspace access actually lives

Workspace data — mail, calls, people, opportunities, files — is reachable only from a signed-in session in the application. Signing in is Google OAuth; there is no password sign-in, so there is no credential you could script against even if you wanted to. That boundary is the reason the public API can be as open as it is: the two surfaces do not overlap.

|  | Public API | The application |
|---|---|---|
| Reaches | Generated public documentation | One workspace's own records |
| Credential | None | A signed-in session |
| Methods | `GET` only | The application's own, not published |
| Described by | `/developers/openapi.yaml`, an allowlist | An OpenAPI document that stays closed |
| Isolation concern | None — nothing is private | Workspace isolation on three independent layers |

## Integration keys are a different thing

Connect has an integration-key mechanism, and it is easy to assume it is the missing credential for this API. It is not. No endpoint in the public description consults one, and sending one changes nothing about the response. What integration keys are for, how one is created and how one is withdrawn belong on their own page — [Integration keys](/developers/integration-keys/) — and this page will not sketch a scope model it cannot show you working.

The same applies to the MCP server and the A2A agent: neither reads a credential, and neither has a private half. If you are looking for an authenticated machine route into a workspace, the honest answer today is that the published interfaces do not provide one.

> **Note** Rotation and revocation questions have no answer here for the same reason: with nothing issued, there is nothing to rotate and nothing to revoke. The only lever on a client that misbehaves is the rate limit, which applies per address to everyone equally.

## Consequences for your client

- Do not build a token store, a refresh loop or a key rotation job for these calls. There is nothing to store.
- Do not treat a `200` as evidence that a credential worked. It is evidence that the request was well formed.
- Do expect `403` from the MCP endpoint if you send a browser `Origin` it does not recognise — that is origin validation, not authentication, and no credential fixes it.
- Do share aggressively. Because responses are public and cacheable for five minutes, a shared cache in front of your client is legitimate and cheap, which is not true of an authenticated API.
- Do plan for the rate limit rather than for quota tiers. There are no tiers, because there are no accounts.

## Questions

### How do I sign up for API access?

You do not. There is no registration step, no key request form and no approval queue for the public API. Call it.

### Is my usage attributed to me in any way?

Only as a rate-limit counter keyed on the calling address, held in the server process and ageing out over sixty seconds. No account, no profile and no history of your questions exists, because there is no identity to attach one to.

### Can I get workspace data with a key if I own the workspace?

Not through the interfaces described in this section. Workspace access is a signed-in session in the application. See [Account and access](/docs/account/).

## Related

- [The public API](https://connectbyjbrh.com/developers/public-api/)
- [Integration keys](https://connectbyjbrh.com/developers/integration-keys/)
- [API rate limits](https://connectbyjbrh.com/developers/api-rate-limits/)
- [Authenticating to the MCP server](https://connectbyjbrh.com/developers/mcp-authentication/)
- [Account and access](https://connectbyjbrh.com/docs/account/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [Three independent layers of tenant isolation](https://connectbyjbrh.com/research/three-layers-of-isolation/)

## What this page is based on

- `backend/app/public_developer_api.py` — no auth dependency on any route
- `webapp/developers/openapi.yaml` — no security schemes declared
- Connect capability registry (docs-source/facts.py)