# Credential types

> Every kind of key an account can issue, what each prefix means, which ones are per environment, and which single key is safe to publish.

TeleQuick issues eleven distinct credential types. Each one is
created and revoked in the console that owns the product it reaches, so
a single account can accumulate keys with several different prefixes
sitting in several different config files.

This page is the map. If you have read `mpk_`, `ctk_`, `cwk_` or
`nck_test_` out of an environment file and need to know what it opens,
start with [Prefix reference](#prefix-reference).

For the underlying model — long-lived keys on your server, short-lived
tokens on clients — see [Authentication](/concepts/authentication).

## The credential map

| Credential | Prefix | Reaches | Created in |
| ---------- | ------ | ------- | ---------- |
| MCP access key | `mpk_` | The platform, on behalf of your user | Admin · API keys |
| Voice API key | `cvk_` | Voice API | Admin · API keys |
| CTI key | `ctk_` | CTI token exchange | Admin · API keys |
| External agent app key | `ck_` | Voice agent connect / call delivery | Voice AI · External agents |
| SMS API key | `smk_` | SMS API | Admin · SMS |
| Chat widget key | `cwk_` | Chat widget identification | Admin · Chat widgets |
| Stream API key | `tqs_live_` / `tqs_test_` | Stream API | Stream · Keys |
| Crypto API key | `cck_` | Block distribution network | Crypto · Developers |
| Netcode API key | `nck_live_` / `nck_test_` | Match session allocation | Arena · Netcode developers |
| Inference API key | `imk_` | Inference gateway | Inference · Developers |
| Realtime app key + secret | (no prefix) | Pusher-compatible realtime endpoint | Realtime · Apps |

The Credentials screen in the portal renders this same list with a
direct link into each owning console. It does not mint keys itself.

## Account keys: MCP access, Voice API, and CTI

Three credentials are account-level rather than product-level. They are
created together on **Admin · API keys**.

**MCP access key** (`mpk_`) lets a coding agent or MCP client operate
the workspace. It acts as *you*: the key carries your membership, and it
stops working when that membership ends. Treat it as equivalent to your
own console session, not as a service credential that outlives you.

**Voice API key** (`cvk_`) is the bearer key for the voice API — agents,
outbound calls, call records, recordings, and transcripts.

**CTI key** (`ctk_`) is the long-lived credential a CTI integration
exchanges for the short-lived token that its control leg presents. The
`ctk_` key itself never rides the wire; only the exchanged token does.
This is the same pattern as API key → relay token described in
[Authentication](/concepts/authentication).

## Agent and messaging keys

These three are created on the screen for the object they belong to, not
on a shared keys page.

**External agent app key** (`ck_`) is the key and secret your own voice
agent uses to connect and to receive calls. Created per external agent
on **Voice AI · External agents**. The secret is displayed once at
creation.

**SMS API key** (`smk_`) sends and reads messages over the SMS API, and
is scoped at creation to send, read, or both. Created on
**Admin · SMS**.

**Chat widget key** (`cwk_`) identifies a chat widget to the platform.
It is the one credential designed to sit in your page source — see
[Publishable vs secret](#publishable-vs-secret). Created per widget on
**Admin · Chat widgets**.

## Per-product keys

Each product console issues its own key for its own API.

| Credential | Prefix | What it does |
| ---------- | ------ | ------------ |
| Stream API key | `tqs_live_` / `tqs_test_` | Reaches the Stream API for live inputs, recordings, and playback. |
| Crypto API key | `cck_` | Submits transactions and reads trader feeds over the block distribution network. |
| Netcode API key | `nck_live_` / `nck_test_` | Allocates and joins match sessions from your game server. |
| Inference API key | `imk_` | Calls the inference gateway, which speaks the OpenAI-compatible API. |
| Realtime app key + secret | (no prefix) | Identifies a realtime app to the Pusher-compatible endpoint. |

The realtime credential is a **pair**, not a single string. The key half
is public and ships in client code; the secret half stays on your
server.

## Environment scoping

Two credential types are scoped to an environment, and the environment
is visible in the prefix:

| Credential | Live | Test |
| ---------- | ---- | ---- |
| Stream API key | `tqs_live_` | `tqs_test_` |
| Netcode API key | `nck_live_` | `nck_test_` |

A test key cannot touch live data. This is the property you rely on when
wiring a CI job or a local development environment: give it the
`_test_` key and a mistake in that environment cannot reach production
inputs or match sessions.

Every other credential type on this page has a single prefix with no
environment segment. For those, separation between staging and
production means issuing separate keys and tracking which is which
yourself — the prefix will not tell you.

## Prefix reference

Sorted by prefix, for when you have the string and not the context.

| Prefix | Credential | Owning console |
| ------ | ---------- | -------------- |
| `cck_` | Crypto API key | Crypto · Developers |
| `ck_` | External agent app key | Voice AI · External agents |
| `ctk_` | CTI key | Admin · API keys |
| `cvk_` | Voice API key | Admin · API keys |
| `cwk_` | Chat widget key | Admin · Chat widgets |
| `imk_` | Inference API key | Inference · Developers |
| `mpk_` | MCP access key | Admin · API keys |
| `nck_live_`, `nck_test_` | Netcode API key | Arena · Netcode developers |
| `smk_` | SMS API key | Admin · SMS |
| `tqs_live_`, `tqs_test_` | Stream API key | Stream · Keys |

`ck_` and `cck_`, and `ctk_` and `cvk_`, are easy to confuse at a
glance. Check the fourth character before you file a key in the wrong
secret store.

## Publishable vs secret

Exactly one credential type is intended to be visible to the public:

- **Publishable** — the chat widget key (`cwk_`). It is designed to sit
  in the HTML or JavaScript your visitors download.
- **Secret** — everything else on this page.

Treat every secret credential as a password: keep it server side, keep
it out of source control, and rotate it if it is ever exposed. Most are
shown once at creation and cannot be read back afterwards.

The realtime app credential deserves a note, because it is listed as
secret while half of it is not. The pair as issued contains a secret, so
the pair is secret. Within the pair, the **key** is public and ships in
client code, and the **secret** stays on your server. Splitting the pair
correctly is your responsibility; shipping the secret half to a browser
leaks it.

## Where each key is created and revoked

Creation and revocation live in the console that owns the product. That
is deliberate: a credential has exactly one authoritative place to be
issued and withdrawn, so there is never a second surface that can
disagree about whether a key is still valid.

| Console screen | Credentials it owns |
| -------------- | ------------------- |
| Admin · API keys | MCP access key, Voice API key, CTI key |
| Admin · SMS | SMS API key |
| Admin · Chat widgets | Chat widget key |
| Voice AI · External agents | External agent app key |
| Stream · Keys | Stream API key |
| Crypto · Developers | Crypto API key |
| Arena · Netcode developers | Netcode API key |
| Inference · Developers | Inference API key |
| Realtime · Apps | Realtime app key and secret |

The portal's Credentials screen links out to each of these. Use it as
the index when you know what you want to do but not which console does
it.

## Rotation and exposure

If a secret credential is exposed, issue a replacement in the owning
console, deploy it, then revoke the old one there. Because creation and
revocation are both on the owning screen, no other console needs to be
touched.

Two cases behave differently from the rest:

- **MCP access key.** It is tied to your membership. Revoking your
  membership revokes the key's access, without any separate key
  operation.
- **CTI key.** The key is exchanged for a short-lived token rather than
  presented to the service directly. Replacing the `ctk_` key stops new
  exchanges; tokens already issued remain valid until they expire.

Relay-token-style credentials that are minted from a long-lived key have
their own rotation procedure, covered under
[rotating keys](/concepts/authentication#rotate-keys-without-downtime).

## Related

- [Authentication](/concepts/authentication) — the API key and relay token model
- [Telemetry](/platform/telemetry) — operational data streams