Use one RelayLink API key per AI assistant

Give every key-based assistant a named credential of its own. The account stays shared, while each key's name, last-used signal, and revocation remain independent.

4 min read

An agent framework cannot complete OAuth sign-in, so you issue a RelayLink API key. Months later, the same string is in a desktop assistant, a scheduled worker, and a test configuration. One copy looks suspicious, but revoking it would stop all three.

Avoid that decision by issuing one named key per integration from the start.

Name the integration, not the person

All keys belong to the same RelayLink account and authenticate as the same person. The key name should identify where the credential is installed:

  • home-agent
  • workflow-runner
  • desktop-client
  • research-framework

Active key names must be unique within the account, ignoring case. Choose labels that will still make sense when you need to revoke one under pressure.

The name does not create a scope. Every active key authenticates the account's /mcp access. Separate keys improve attribution and revocation; they do not give one assistant a smaller inbox or a restricted tool set.

RelayLink OAuth is available on every deployment, so OAuth-capable assistants should normally use sign-in and consent instead. Keys are for clients and configurations that cannot complete that flow.

Issue each key in the browser

Sign in to RelayLink and open /account/keys. For each key-based integration:

  1. Enter a distinct name.
  2. Issue the key.
  3. Copy the full rl_ secret from the result page.
  4. Put it directly into the integration's secret or HTTP-header setting.
  5. Remove temporary clipboard or deployment notes that contain it.
  6. Make one authenticated call and confirm the named row begins showing use.

The full secret is displayed once. RelayLink stores its hash, not a recoverable plaintext copy. If you lose the secret before configuring the client, revoke that row and issue another rather than looking for a reveal control.

Issuing is deliberately browser-only and is not an MCP tool. An assistant can help list or revoke keys, but it cannot cause a live credential to be printed into a chat transcript.

An account can hold ten active keys. Revoked rows do not count toward that cap. The limit is an abuse bound, but it also gives an account holder a reason to remove credentials that no longer have an owner.

Store the secret in the connector, never the conversation

For a key-based MCP connection, the client sends:

X-RelayLink-Key: rl_<secret>

Use the connector's credential field, a secret store, or protected process configuration. Do not place the key in:

  • a chat message;
  • a source file or commit;
  • a query string or URL;
  • an issue, support message, or screenshot;
  • shared configuration intended for several integrations.

Matching is byte-exact. Changed case or an accidental trailing space makes the key invalid. Copy the value carefully and avoid helpers that trim or transform secrets.

Read Last used as a signal

The keys page records when a key last authenticated. That value updates at most once per five minutes per key, which avoids turning a burst of calls into a database write for every request.

Use it to answer practical questions:

  • Has this retired laptop used its key since I stopped it?
  • Did the worker authenticate after the last deployment?
  • Which of two similarly named installations is still active?

It is not an event ledger and cannot prove which action a client performed. A quiet timestamp also does not prove a secret was never copied; it only says RelayLink has not accepted it in that period.

Revoke one key without disturbing the rest

When an integration is retired, lost, or suspected of exposure, revoke its named key. Revocation takes effect for that credential and leaves other API keys active. It also leaves OAuth applications connected.

RelayLink emails the account owner when a key is revoked. That notice matters because an assistant session capable of revoking a key may itself be the thing under investigation.

After revocation, verify the affected client fails authentication and the other assistants continue normally. If several clients fail, they were probably sharing the revoked string; give each a separate credential before restoring them.

The operating rule is simple: one installation, one door, one name. A problem then has a narrow response instead of a coordinated outage.

Tags api-keys ai-assistants security credentials

Frequently asked questions

Can an AI assistant issue its own RelayLink API key?
No. Keys are issued only from the signed-in browser page. Listing and revoking can be assisted, but the full secret must not be written into a third-party conversation transcript.
Why not use the same key in every assistant?
A shared key makes revocation shared too. Separate named keys let one compromised or retired integration stop without interrupting the assistants that use other credentials.
Is Last used a complete activity log?
No. It is a coarse signal updated at most once per five minutes per key. Use it to judge whether a credential appears active, not to reconstruct every request.

Related articles