Connectors

An connector is two things at once: a connector that ships with the platform, and the credentials your organisation stores against that connector. The connector carries the vendor knowledge — which actions exist, what each one takes and returns, how signing in works — and is identical in every organisation. The credentials are yours, and a connector holds as many as you need: one per workspace, store, mailbox, or bot. Thirteen connectors ship today, and each one is already listed under Settings > Connectors, waiting for its first credential.

Prefer to watch first? Episode 7 walks the doors to the outside world — connectors, MCP, and the boundaries — in two and a half minutes, captions included.

What a connector is

There is nothing to install. Every connector arrives with the platform, which is why the catalog looks the same in every organisation and why an upgrade keeps it current without anyone maintaining it. A connector is a definition: a display name and a one-line description, the category tags it belongs to, the authentication methods it accepts, and the list of actions it can perform against the vendor.

Because the definition is shared, the only thing your organisation decides is which accounts Tale may act as. That decision is a credential, and it is the whole of setup.

The connectors that ship

Thirteen connectors ship, each tagged with the category it belongs to — Knowledge, Messaging, Email, Developer, Commerce, Search, or Files. Sign-in is the authentication method the connector accepts, which decides what the credential form asks for; Actions is how many operations it exposes, the same count the connector's section shows on the settings page.

Pages and files pulled in through Confluence or Google Drive run through the same indexing pipeline as a direct upload, and answers cite them back to the source — see Documents. The WebDAV connector is the write side of the same store your devices mount as a network drive, covered in WebDAV.

Credentials on a connector

A connector holds as many credentials as your organisation needs. One Slack workspace per business unit, one Shopify store per market, one mailbox per support queue — each is a separate row under the connector, with its own secret and its own state. That is what lets a single automation library serve several teams without any of them borrowing another's account.

Each credential carries four things:

• Name — the name an action uses to pick this credential. Write it for whoever reads the automation months from now: Support inbox, EU store, Release bot.
• Authentication method — API key, Token, Username & password, or OAuth, chosen from what the connector accepts.
• Default — one credential per connector can hold this. An automation node or chat action that names no credential uses the default.
• State — a credential is either in use or Disabled. Disabling keeps the row and its configuration but stops anything calling through it.

Leave a connector without a default and it still works for callers that name a credential outright, but a caller that names none has nothing to fall back on. The connector's section says as much, and the fix is to promote one of the existing credentials.

Connecting one

Where you start depends on what the connector accepts. Token-shaped connectors open a form and take the secret directly; OAuth connectors send you to the vendor's consent screen and return with the credential already filled in. Both paths end in the same place — a named row under the connector.

1. 1

   Open Settings > Connectors

   Every connector has a section, headed by its icon, description, category tags, and action count. Nothing is hidden behind a catalog dialog.

2. 2

   Add the credential

   Add credential opens the form for connectors that take a key, a token, or a username and password. Connect runs the vendor's consent flow for OAuth connectors, then binds the result to a new row.

3. 3

   Name it, and make it the default

   Give the credential a name your automations can point at, and promote it if it should be the one used when nobody names a credential. The connector's actions become available to automations and chat as soon as the row exists.

The per-method detail — what each form asks for, how to replace a secret, what happens when an authorization expires — lives on Connector credentials.

Actions in automations and chat

Every action a connector declares has a name, a description, an input schema, an output signature, and a declared effect of read or write. Automations place an action as a node in the workflow editor; chat reaches the same actions as agent tools. Either way the call resolves a credential first — the one the caller names, or the connector's default — and fails clearly when neither exists.

When no connector fits

Thirteen connectors cover the systems most teams reach for, and they cannot cover an internal API, a homegrown tool, or a vendor nobody has written a connector for. That is what MCP is for: you host a server, Tale registers it, and its tools join the agent toolbelt alongside connector actions. The bridge is your code rather than a shipped definition, which is exactly the trade — more freedom, more to maintain.

Register one under Settings > API > MCP, as described in MCP servers.

Where this fits

Connectors are how Tale reaches the systems your work already lives in, and credentials are how you decide which accounts it may act as. From here, Connector credentials is the operations side — adding, replacing, disabling, and reconnecting the rows under each connector. Agent tools shows how a connector's actions arrive in an agent's toolbelt, Configure approvals holds the write ones, and MCP servers covers the ground the catalog does not.