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.
What to send#
# 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 — 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.
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
200as evidence that a credential worked. It is evidence that the request was well formed. - Do expect
403from the MCP endpoint if you send a browserOriginit 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.