Every endpoint except GET /health needs a credential. Code sends a personal access token as a Bearer header; the dashboard uses a session cookie. Nothing else authenticates a request.

​
Creating a token

In the dashboard, Organization → API Tokens → create, with a name of 1–100 characters. The value is shown once. Nothing can print it again; if you lose it, delete the token and create another. A token is an opaque signed string with no prefix and no expiry. Do not parse it. A value with anything glued to the front (such as tq_) is sent verbatim and comes back 401.

​
A token acts as its creator

A token authenticates as the person who created it, in the workspace it was created in, with that person’s live role. Membership and role are re-read on every request and never cached.
  • Change their role and every token they hold changes with it on the next request. Nothing is reissued.
  • Remove them from the workspace and their tokens for it are deleted with the membership.
  • Revoking a token is deleting it. The signature never expires; the stored row is the check, so deletion takes effect on the next request.
  • There is no per-token scope and no read-only token. A VIEWER’s token is read-only because the VIEWER is.
An ADMIN sees every token in the workspace and can delete any of them. An EDITOR or VIEWER sees only their own. The list shows name, kind, owner and creation time, never the value.
Never put a personal access token in a browser, a mobile app or a public repository. It carries its owner’s full role in the workspace. To let a browser join a call, your server calls POST /v1/calls/token and hands the page only the short-lived call token it returns. See web calls. Text chats from a browser work the same way with a chat token; see text conversations.

​
The MCP token

The token list also shows one token with kind: mcp. It is issued automatically, one per person per workspace, and is what the dashboard renders into ready-to-paste MCP configuration. Unlike a manual token it can be read again at any time. Deleting it rotates it: the next dashboard visit issues a new one, and anything configured with the old value stops working. Signing in sets talqing_sid, an HttpOnly cookie on the API host that lasts 30 days. It is stateless, so it cannot be revoked before it expires; signing out clears it in that browser only. Switching workspaces re-issues it. credentials: "include" makes the TypeScript SDK send the cookie instead of a token. That works only from a page on the dashboard’s own origin. The Python SDK always requires a token. Sign-in is Google OAuth only. There is no password and no domain auto-join: you belong to a workspace only by creating it or by being invited.

​
401 versus 403

Which role each operation needs is in workspaces and roles. Every error uses the standard error envelope.

​
What the API cannot do

Signing in, workspaces, members, roles and tokens are managed in the dashboard. None of them is in the published API reference, the SDKs or the MCP server, so a CoPilot or MCP client can never mint a credential or change who is in the workspace. A personal access token authenticates you to Talqing. The OpenAI, Deepgram or ElevenLabs key your agent runs on is a separate provider key, stored in the workspace and never sent in a request.

​
Next

Workspaces and roles

What ADMIN, EDITOR and VIEWER can each do.

SDKs

Install a client and make your first call.