Connector credentials

Every connector ships with the platform, so the administrator's job is never installation — it is deciding which accounts Tale may act as, and keeping those credentials healthy. A connector holds as many credentials as you need, one per workspace, store, mailbox, or bot, and one of them answers for any caller that names none. This page is the operations side of that: what the page shows, how each authentication method is filled in, and what happens when you promote, disable, delete, or reconnect a row.

The catalog itself — the thirteen connectors, what each one buys you, and how their actions reach automations and chat — is on Connectors. Reading time here is best spent on the credential lifecycle, because that is the part that differs per organisation and the part that breaks.

What the page shows

Open Settings > Connectors. The page is gated on Admin or Developer permissions and is a table of the credentials your organisation holds — one row per credential, not one per shipped connector. A row shows its name, the connector it authenticates, its authentication method, and its coordinates: a masked preview of the stored secret, plus the instance URL where the connector needs one. A Default badge marks the one an action falls back to, a Disabled badge any that is switched off.

Search covers both the name you gave a credential and the connector behind it; the filter button narrows to one connector. A ?connector= link narrows the table the same way, which is where the OAuth round trip returns you.

Two warnings appear here, and they mean different things. No default credential for {connector} means every row works but nothing answers for a caller that names none. Reconnect needed on a row means an OAuth grant stopped refreshing and needs consent again — the credential itself is fine.

Adding a credential

Add credential opens the shipped catalog. Connectors you already hold a credential for come first, under In use; everything else follows below it, alphabetically, each with its category tags and how many actions it exposes. Search narrows the list; picking one moves you to the setup step, and Back to the catalog returns.

Setup asks for a Name first, and the field's help text is the reason it matters: the name an action uses to pick this credential. Choose something an automation author will recognise months later, such as Support inbox or EU store.

What follows the name depends on the Authentication method the connector accepts.

Adding a second credential to a connector that already has one is the same flow again — it simply appears under In use in the catalog. There is no limit to work around and nothing to disconnect first.

Choosing the default

One credential per connector can be the Default, and Make default on any row moves it. The default is what resolution falls back to when an automation node or a chat action names no credential. Mail sync is the exception that proves the rule the other way: conversation.sync_mailbox walks every active credential on the connector so adding a second IMAP mailbox (or a second Gmail account) does not leave it unsynced until you promote it. Inbox triage does the same fan-out through conversation.list_mailbox_messages.

A connector with several credentials and no default is a working configuration with a gap in it. Callers that name a row keep running; callers that do not cannot pick one and fail. Promote a row and the gap closes immediately.

Replacing a secret

Rotating a key is an edit on the credential, not a separate operation. Open the row and choose Replace API key, Replace token, or Replace username & password, depending on the method. The stored secret is never shown back to you, and entering a new one replaces it everywhere that credential is used — every automation node and every chat action pointed at that row picks up the new secret without being touched.

The credential keeps its name, its default flag, and its instance URL through a replacement, so nothing downstream has to be repointed. Edit name & instance covers the other direction: renaming a row, or moving it to a different instance origin.

Disabling and deleting

Disable takes a credential out of service while keeping the row and everything configured on it. The credential shows as Disabled and nothing resolves to it; Enable puts it back. Reach for this when an account is suspected rather than finished, or when you want a configuration parked without losing it.

Reconnecting a broken authorization

An OAuth credential whose stored authorization expired or was revoked shows Reconnect needed with the reason attached. This is the platform's own finding, not an operator's decision, which is why it reads differently from a credential someone disabled by hand: nothing about the row is wrong, the vendor stopped honouring the grant.

Reconnect re-runs the vendor's consent flow and restores access on the same row, keeping its name, its default flag, and every reference pointed at it. A credential you disabled yourself is not repaired this way — Enable is the fix for that one, and reconnecting it would be answering the wrong question.

Connectors and MCP servers

Both surfaces let an agent reach past Tale, and the difference is who owns the bridge. A connector is vendor-specific, ships with the platform, and is maintained for you; your side of it is the credential. An MCP server is a process you host and register under Settings > API > MCP, exposing whatever tools you write. Reach for the connector when one exists for the target system, and for MCP servers when none does.

Where this fits

Credential management is the whole of connector administration now that nothing is installed: add the accounts, name them well, keep one default per connector, and reconnect the OAuth rows that lapse. Connectors is the catalog those credentials attach to, Agent tools shows how the resulting actions arrive in an agent's toolbelt, and Configure approvals is where the write actions are held for a person to release.