Skip to main content
A few kinds of secrets are involved in connecting Swan to other systems. Treat all of them like passwords — anyone who has one can act as your org.

​
Secrets you give Swan

Some catalog integrations and most custom MCP servers authenticate with an API key or header secret from the other tool, rather than OAuth. You paste the key in when connecting from Tools; Swan stores it and uses it on your behalf whenever the agent calls that tool. Connections (and their secrets) are shared at the org level, so connect only tools your whole team should be able to act through. To rotate a compromised key, generate a new one in the source tool and reconnect the integration on Tools.

​
Secrets for the agent’s own API calls

Beyond integration connections, you can store standalone named secrets — at the org level or personal to you — at Settings → Secrets, for the agent to use when it runs code. This is the escape hatch for any API Swan doesn’t integrate with: store the key as a secret, then ask Swan (in chat or in a trigger) to call that API. The agent references the secret by name; the actual value is substituted only at execution time and is never shown, logged, or returned in output — code that would leak a resolved secret value into an output file is blocked automatically. Personal secrets override org-level secrets with the same name. See direct API access for how Swan builds and reuses these integrations.

​
Webhook trigger URLs

Webhook-sourced triggers work the other way around — Swan gives you a unique URL to call when you want to fire the trigger, and that URL has a secret embedded directly in its path. Anyone with the URL can trigger the automation, so treat the URL itself as a credential: don’t post it anywhere public, and regenerate the trigger from its configuration tab (https://agent.getswan.com/triggers/{triggerId}) if you think it’s leaked, which issues a new URL.

​
Common questions

Does Swan have its own API key for calling a Swan API? No — Swan doesn’t offer a public REST API, so there’s no Swan-issued API key to manage. The programmatic surfaces are webhook triggers for kicking off Swan work from your systems, and Swan’s own MCP server for working with Swan agent-to-agent. To push data out to your systems, use your CRM sync, or set up a trigger whose instructions have the agent call your API with a stored secret. An app I use has no Swan integration — can I still connect it? Yes, two ways: connect it as a custom MCP server from Tools if it exposes one, or store its API key as a secret at Settings → Secrets and have Swan call its API directly — see direct API access. Is a webhook trigger URL safe to share with a teammate? Only share it with people who should be able to fire that automation — the URL itself grants access, there’s no separate login required to use it. How do I rotate a secret I gave Swan for an integration? Generate a new key in the source tool, then update the connection on Tools with the new value. The old key can then be revoked on the other side.