An MCP client asks for a RelayLink server address. One setup opens a browser and asks you to sign in; another asks for a custom HTTP header. Both can connect the same account, but they create different credentials and require different incident responses.
OAuth is available on every RelayLink deployment. Choose a named key only when the client cannot complete that browser flow, not because you expect a different set of RelayLink powers.
Prefer OAuth when the client can sign you in
With OAuth, the client sends you to RelayLink. You enter an emailed sign-in code, review the application on the consent page, and approve it. The client receives and manages tokens; you do not copy a RelayLink secret into its settings.
This is the normal choice for hosted assistants and MCP clients that implement browser authorization. It provides:
- an explicit sign-in and consent moment;
- an application identity shown in connected applications;
- token handling owned by the client rather than by your clipboard;
- one application-level disconnect control that revokes every live grant you gave it.
Approving the same application on several devices can create several authorizations. RelayLink groups them by application on the connections page. Disconnecting that application revokes all of its live grants and tokens for your account.
OAuth does not create a separate RelayLink identity. The client still acts as the account whose email you used at sign-in.
Use a named API key when the client cannot
Some frameworks and service configurations know how to call a remote MCP server and attach headers but cannot open a browser authorization flow. For them, sign in to RelayLink yourself, open /account/keys, and issue a named key for that integration.
The client sends:
X-RelayLink-Key: rl_<secret>
RelayLink shows the full secret once and stores only its hash. You are responsible for placing it in a protected connector setting or secret store. Never paste it into the assistant's conversation, put it in a URL, or commit it with configuration.
Issue one key per integration. Its name and last-used time help you identify the installation, and revoking it stops that key without interrupting other keys or OAuth applications.
Issuing a key is browser-only. An assistant cannot issue a successor for itself through MCP.
Understand what does not change
OAuth and API keys both authenticate the person's /mcp access. They reach the same account data and actions. Neither creates:
- a private inbox for one assistant;
- a smaller set of correspondence capabilities;
- a separate contact list;
- a different sender identity.
Do not describe an API key as read-only or narrowly scoped. RelayLink key separation is a revocation and attribution boundary, not a permission scope.
The assistant-composed send workflow also stays the same. The assistant drafts, you review, and only the confirmation step delivers. The @relaylink shorthand opens a draft and never sends merely because authentication succeeded.
Match revocation to the door
If the client used OAuth, disconnect its application under Connected applications. That action covers every authorization for that app, including other devices, but leaves API keys and other applications alone.
If the client used a key, revoke that named row under Keys. That action leaves OAuth connections and other keys alone. RelayLink emails the account owner when a key is revoked.
When containing an uncertain exposure, inspect both pages. A client may have been reconfigured from one method to the other, and closing the remembered door does not close the one it currently uses.
Configure one method per client. If a request presents a bearer token, a failed bearer authentication is terminal rather than silently falling back to an API key that also happened to be attached. That prevents an expired personal token from causing a request to run under a different credential's identity.
Make the choice quickly
Use this decision:
- Can the client open RelayLink sign-in and consent? Choose OAuth.
- Can it only configure a server URL and HTTP headers? Create a named API key for that client.
- Can it do neither? It cannot authenticate to RelayLink's remote MCP endpoint.
OAuth avoids manual secret handling and gives an application-level disconnect. A key supports simpler clients at the cost of storing a long-lived bearer credential yourself. Both are valid doors; keeping them distinct is what makes either one removable.