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.
What's in the gateway today
The gateway bundles 34 connectors: Stripe, GitHub, Slack, Gmail, Microsoft Graph, Vercel, Cloudflare, Linear, HubSpot, OpenAI, Braintree, Discord, DocuSign, Dropbox, ElevenLabs, Events Manager, fal, Google Ads, Google Analytics, Google Calendar, Google Drive, Google Meet, Google Veo, HeyGen, Mailchimp, Meta Marketing API, Microsoft Advertising, Microsoft Advertising Reporting, OpenRouter, Paddle, Reddit, Reddit Ads, Square and Xero. Those are the catalog tiles under Add connection, and the ids POST /v1/connections/from-preset accepts. For an API that is not bundled, Connect your own builds a connection from a WordPress site's address or from an OpenAPI document the API publishes.
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 organizations) 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. The gateway hands agents 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. From gateway 1.3.44 the list also covers the header, query parameter or variable the connection's credential is sent under, and the credential itself is replaced too, as is and in its common encodings, if it is at least 8 bytes long. A shorter credential, or any other secret, is caught only by field name.
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 for every call, even after you enable them. By default that approval can come from the console, the Permaura app or the CLI; to require a signature from a paired device, set the action to Device-signed in its policy or raise the approval floor.
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
Every connector in this section works unattended once it is connected, in one of two 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, since the tokens live on your gateway and nowhere else.
In the console it is the Gateway-held · your own app choice under OAuth when you add the connection: it takes the app's client id and secret, shows the redirect URI to register, and opens the provider's consent page. The same flow runs through the gateway's API, and 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 |
| Events Manager | WordPress application password | 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 |
| Your own OAuth app | Yes | |
| Reddit Ads | Your own OAuth app | 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 Ads | Your own OAuth app, plus a developer token | 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 |
| Meta Marketing API | Your own OAuth app, or a system user token | Yes, used at least once every sixty days |
| Microsoft Advertising | Your own OAuth app, plus a developer token | Yes |
| Xero | Your own OAuth app | Yes |
The table lists the connectors that have a page here. Microsoft Graph, Vercel, Cloudflare, Linear, HubSpot and OpenAI are in the gateway too, as above, and have no page yet.
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. Meta is the exception: it issues no refresh token, so the gateway holds a sixty-day token and renews it by exchange whenever the connection is used in its last week; the Meta page explains what that means for an agent that runs rarely. 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.
Some connectors need a value only you have
Most connectors are complete as published. A few cannot be, because part of the address, or a header on every call, is specific to your account, and a manifest pins one value for everyone:
- Mailchimp ships pointed at
us1. Your data center 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 organization. Without it every call returns 403. - Google Ads needs a
developer-tokenheader, and alogin-customer-idwhen you work through a manager account. Microsoft Advertising needsDeveloperToken,CustomerIdandCustomerAccountId. Those two connectors declare their headers, so the Add connection form asks for them by name and the gateway refuses a connection that leaves a required one out.
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 one exception is a header the connector's own definition declares every connection needs, such as the ad platforms' developer tokens, which identify your API access while the sealed OAuth token authorizes the account; the Google Ads page says what that custody means.
The Add connection form offers Use a different host only for connectors whose definition permits a host override. Fixed vendor connectors keep their reviewed host. For GitHub Enterprise or another private API, import a connector under your own id with its own pinned host; do not repoint the built-in identity. The form takes the headers a connector declares and no others, so Xero's tenant header is still set through the API.
A stored connection whose host no longer matches its connector shows Calls refused: host mismatch in the connection list. Its calls stay refused until you reconnect to the permitted host or import the intended host under your own connector id.
A WordPress connection works differently: you give the site's address and the gateway discovers where its API lives, so there is no host to edit by hand.
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, and GET /v1/presets reports it as provenance: builtin for the catalog compiled into the gateway, signed (with the signing key's id) for a manifest carrying a valid Permaura signature, whose capability list and endpoints have been reviewed and not tampered with in transit, and user for an unsigned manifest you brought yourself, which Permaura does not vouch for. The console shows it on every tile and on the connection form, names the host a credential will be sent to, and gives an unsigned manifest no logo or brand color. Installing or removing a definition through permaura.com is an owner or admin action; adding connections from what is installed stays with members.
Installing changes no enforcement. The manifest is inert until you create a connection from it and grant capabilities, and risky verbs still arrive disabled.
From gateway 1.3.56 an unsigned manifest's own action, risk, requires_approval and disabled lines can only make a capability riskier than its method and path make it, never safer, because Permaura has not reviewed them. A read the API takes as a POST (a search, a report run, a GraphQL query) therefore lands as a write from an unsigned copy: high, switched off, and asking for an approval on every call once on. The signed version of the same connector keeps the reads it declares. A manifest that tries to send a call as another method than the one it shows, through a _method parameter or a method-override header, is refused at install. The gateway's owner can still lower a capability they trust, one at a time, from the connection page.
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.