Connectors

Connectors are a secure key vault for REST APIs. Save a token-based API once — Notion, Airtable, Stripe, a CRM, any service — and any worker that holds the connector_call tool can reach it by name. askTheodor attaches the base URL and the authorization header for the worker, so the secret never appears in the chat or in the worker’s prompt.

This is the safe way to let a worker hit an API that doesn’t have a dedicated MCP server.

How a connector works

When a worker calls connector_call, it names a connector (by its kind) and a path — it never sees or types the key. askTheodor looks up the saved connector, prepends the base URL, adds the auth header with your stored secret, and makes the request. The worker gets the response; the credential stays in the vault.

The API key is write-only in this screen: once saved it’s never read back to the interface. The list only shows whether a key is set — you can replace it, but you can’t view it.

Saved connectors

Each saved connector shows as a row with:

• A kind tag (the name workers call) and the label.
• The base URL, and whether a key is set (🔑) or missing (⚠).
• Edit and 🗑 delete buttons. A disabled connector is dimmed and won’t resolve for workers.

Add or edit a connector

Presets

Quick buttons fill the form for common APIs, grouped by category — Work & project tools (Notion, Airtable, Linear, Jira, Asana…), Dev & infrastructure (GitHub, Cloudflare, Vercel…), Messaging & email (Slack, SendGrid, Mailchimp…), Commerce & business (Stripe, Shopify, HubSpot…), and Marketing, SEO & analytics (Klaviyo, Customer.io, ActiveCampaign, Kit, beehiiv, Ahrefs, DataForSEO, Webflow, Contentful, Plausible) — plus Custom REST for anything else. Each preset fills in a sensible base URL, header, and scheme; you just add the key.

Marketing tools that need OAuth

Google Analytics 4, Google / Meta / LinkedIn Ads, and Semrush use OAuth or query-param auth, which the key-in-header connector model doesn’t cover — reach those through an MCP server instead.

The fields

• Kind (required) — the short name a worker uses to call this connector (e.g. notion, airtable, stripe). Keep it lowercase and memorable. This is what goes in the worker’s connector_call.
• Label — a human-friendly name for the row (e.g. Marketing Notion). Optional; defaults to the kind.
• Base URL — the API’s root, which every call is appended to (e.g. https://api.notion.com/v1).
• API key — the secret token. Stored write-only; type it once. When editing, leave it blank to keep the current key.
• Auth header — the HTTP header the key is sent in. Default: Authorization. Change it only for APIs that expect the key in a different header (e.g. X-Api-Key).
• Auth scheme — the prefix placed before the key in that header. Default: Bearer (so the header reads Authorization: Bearer <key>). Leave empty for APIs that want the raw key with no prefix.
• Enabled — whether workers can resolve this connector. Default: on.

Key-in-header APIs

For an API that wants its key in a custom header with no prefix — say X-Api-Key: <key> — set Auth header to X-Api-Key and clear Auth scheme so there’s no Bearer in front.

Some APIs need an extra header

A few services want a second fixed header — Notion, for example, requires a Notion-Version header. Add those on the service side or via the worker’s call; this vault manages the one auth header plus the base URL.

Letting a worker use connectors

Saving a connector doesn’t grant any worker access by itself. Add the connector_call tool to a worker’s allowed tools (in its Skills tab). From then on that worker can reach every enabled connector by kind — and only that tool can read the vault; the keys never enter the conversation.

connector_call is broad

A worker with connector_call can reach every enabled connector. Grant it deliberately, and disable any connector you’re not actively using so it can’t be called.

In practice

Connectors are for the APIs that don’t have an MCP server. If a service already ships one, use MCP — you get real named tools with proper schemas. Connectors are the fallback for everything else: an internal REST API, a small service with only an HTTP endpoint, something whose MCP server you’d rather not run. The trade-off is that the worker must know the API’s paths, because a connector hands it raw HTTP rather than a menu of tools.

Three things this setup actually buys you:

• An internal API a worker can query. Save your own service as internal, give one worker connector_call, and it can look up an order status or a stock level mid-conversation instead of you fetching the answer and pasting it in.
• Access that shows up in the audit trail. Every request goes through a tool call, so it’s recorded like any other action — which a key pasted into a prompt is not.
• A credential you can revoke in one move. Disable the connector and every worker loses that access at once, with no worker edits.

The key never enters the model’s context, which is the whole point. A worker told “use this Stripe key” in chat would carry that secret in its conversation history — and in any export or backup of that conversation. Through a connector, the worker only ever names the connector; askTheodor attaches the credential when the request goes out.

Grant connector_call narrowly. The tool is all-or-nothing: a worker holding it can reach every enabled connector, not only the one you had in mind. Give it to the one or two workers that genuinely need API access, and disable connectors you aren’t currently using.

🎓 Learn it hands-on: The remote connector directory · OAuth sign-in

Terms in this page

• Connector — a saved API definition (base URL + auth + secret) that workers call by name through the connector_call tool.
• connector_call — the built-in tool a worker uses to make a request through a saved connector. It’s the only thing that can read the vault.
• Kind — the short, lowercase name that identifies a connector and that workers use to call it.
• Base URL — the root address of an API; every request path is appended to it.
• API key / token — the secret that authorizes requests to the API. Stored write-only and never shown back to you.
• REST API — a common style of web API where you make HTTP requests to URLs to read or change data.
• HTTP header — a labeled line of metadata sent with a web request. Credentials usually travel in the Authorization header.
• Auth scheme / prefix — the word placed before the key in the auth header. Bearer is the most common; some APIs use none.
• Write-only — you can set or replace the value but never read it back, so a saved secret can’t leak through the interface.
• Vault — the secure store where these credentials are kept, separate from chat content.