How the catalog works
Each page in this section covers one connector: the credential it needs, where to create it, what an agent can do with it, and which of those actions arrive switched off. This page is the part that is the same for all of them.
A connector is a definition, not a connection. It pins one upstream host, fixes the authentication scheme, and lists a curated set of actions with a method and path each. A connection is one configured instance of it, holding a sealed credential. That split is what lets you connect the same API twice — production and sandbox, or two Xero organisations — without either one being able to reach the other's host.
What you get for free
Every connector in this catalog inherits the same four properties, whatever the API behind it:
- The host is pinned. An agent fills in allow-listed parameters; it never supplies a URL. A connection to Stripe can reach
api.stripe.comand nothing else, so a prompt-injected instruction to post your data somewhere has nowhere to post it. - The credential is sealed. You paste it once, at creation. It is encrypted on your gateway, injected server-side on each approved call, and never displayed again. Agents receive results, never keys.
- Only listed parameters travel. Each capability declares its path, query and body parameters. Anything else an agent sends is dropped before the request is built.
- Responses are redacted. Field names known to carry secrets or personal data are blanked on the way back. Each connector adds its own list on top of the gateway's defaults, and its page says which.
None of it does anything until you grant a capability to an agent. Adding a connection grants nothing.
Reads arrive on, risky verbs arrive off
Every capability is classified when the connector is installed. Reads and searches land enabled. Anything that creates, updates, deletes, or moves money lands disabled, and you switch it on deliberately. Money movement and irreversible sends additionally require a human approval on your paired device for every call, even after you enable them.
Across this whole catalog, nothing that spends money, sends something to a person, or destroys data is enabled when you connect. The actions that are on by default are all reads — but a read can still be sensitive, and the pages say so where it matters. google-meet returns verbatim meeting transcripts. xero returns your complete financial position. dropbox can mint a four-hour public link to a private file. Grant those to one agent for one purpose rather than leaving them on a broad policy.
Which connectors work unattended today
All of them, in two different ways.
Most take a static API key or token: you paste it once and it works indefinitely.
The rest are OAuth-only — the vendor issues no API key at all. From gateway 1.1.0 those connect with your own OAuth app: you register one with the provider, hand your gateway its client id and secret, approve once in a browser, and the gateway keeps the connection alive on its own from then on, refreshing the access token two minutes before it expires. Nothing to re-paste, and nothing reaches permaura.com — the tokens live on your gateway and nowhere else.
The console does not expose that step yet, so today you start it through the gateway's API. Each affected page has the exact calls.
| Connector | How you connect it | Keeps working on its own |
|---|---|---|
| Braintree | Public and private key pair | Yes |
| Discord | Bot token | Yes |
| ElevenLabs | API key | Yes |
| fal | API key | Yes |
| GitHub | Fine-grained personal access token | Yes |
| Google Veo | Gemini API key | Yes |
| HeyGen | API key | Yes |
| Mailchimp | API key | Yes |
| OpenRouter | API key | Yes |
| Paddle | API key | Yes |
| Slack | Bot token | Yes |
| Square | Personal access token | Yes |
| Stripe | Restricted API key | Yes |
| DocuSign | Your own OAuth app | Yes |
| Dropbox | Your own OAuth app | Yes |
| Gmail | Your own OAuth app | Yes |
| Google Analytics | Your own OAuth app | Yes |
| Google Calendar | Your own OAuth app | Yes |
| Google Drive | Your own OAuth app | Yes |
| Google Meet | Your own OAuth app | Yes |
| Xero | Your own OAuth app | Yes |
Registering your own OAuth app is a one-off: the gateway becomes a confidential client with it, holds the refresh token, and mints access tokens indefinitely. The one thing that will break a Google connection is leaving the OAuth app in Testing — Google expires those refresh tokens seven days after issuance and refreshing does not extend that. Each Google page says what to do instead.
Three connectors need a value only you have
Most connectors are complete as published. Three cannot be, because part of the address is specific to your account, and a manifest pins one host for everyone:
- Mailchimp ships pointed at
us1. Your data centre is the suffix of your own API key. - DocuSign ships pointed at the developer sandbox. Production has a per-account base URI.
- Xero needs a
Xero-tenant-idheader naming your organisation. Without it every call returns 403.
Each page explains exactly what to change and how to find your value. You supply it when you create the connection: POST /v1/connections/from-preset accepts an optional base_url to re-pin the host and optional static_headers merged over the manifest's, both scoped to that one connection. The response reports the host it actually pinned, so you can confirm it took.
The override is operator-supplied, never agent-supplied, so the pinned host is still the SSRF guard it always was — it just points at your account rather than the manifest author's default. It must be an absolute https origin with no userinfo or query string, and a credential-bearing header name is refused outright: a secret belongs in the sealed credential, not in a connection record stored in the clear.
The Add connection form does not expose these fields yet, so for now they are set through the API.
Installing a connector your gateway does not have
The gateway ships with a catalog compiled in. Anything beyond it arrives as a manifest you install at runtime, through POST /v1/connectors/install on the REST API. No rebuild, no restart.
The gateway records where each one came from. A manifest carrying a valid Permaura signature installs as signed and shows the Verified connector badge, so you know its capability list and endpoints have been reviewed and have not been tampered with in transit. An unsigned manifest installs too, recorded as user-provided — you brought it yourself, and the console says so rather than implying we vouch for it.
Installing changes no enforcement. The manifest is inert until you create a connection from it and grant capabilities, and risky verbs still arrive disabled.
A signed manifest takes precedence over a built-in connector of the same id, which is how a connector gets a correction without waiting for a gateway release. An unsigned one cannot: the gateway refuses to let a manifest you brought yourself take over a built-in connector's identity and its pinned host. Install your own under its own id instead, which is also how you run a second copy pointed at a sandbox.