Outbound connections

Pyron reaches the systems you already run — a public data feed, a building-sensor API, your own back-office service — so your automations can pull information from them or send updates to them. An outbound connection is the saved definition of one such system: where it lives, and how Pyron authenticates to it. Set a connection up once, and every automation that calls that system works from the same trusted credentials.

The integrations hub

Outbound connections live in Setup, under Integrations. The page opens on the Outbound tab, which lists the connections your organisation has set up. The Inbound tab beside it handles the opposite direction — the keys external systems present to reach Pyron — and has its own page.

Each row summarises one connection: its name, the base address it points at, how Pyron authenticates, its status, and when it last changed. The status tells you whether a connection is ready to use. A connected connection is reachable and holds the credentials it needs; an unconfigured one is missing a credential you still have to supply; and a connection that authenticates through a provider's sign-in screen waits until you authorise it. A connection to a public system that needs no credentials at all shows as connected straight away.

From a row you can send a test request to confirm the system answers, or remove a connection you do not need. A connection that an automation depends on cannot be removed until you detach it there, which protects the automations already relying on it.

Creating a connection

Select Create Connection to open the connection form, then work down it:

1. Give the connection a name your team will recognise, and enter the base address of the system it calls — the root that every request builds on.
2. Choose how Pyron authenticates. A connection can present an API key, send a bearer token, sign in with a username and password, sign each request cryptographically, or hand off to the provider's own sign-in screen. Pick the method the external system expects.
3. Enter the credential that method needs — the key, token, password, or secret. For a system that needs no credentials, leave the method set to none.
4. Save the connection.

A connection can also hold two optional extras, both applied to every request whatever the authentication method: a signing secret Pyron uses to sign outbound webhook deliveries, and a client certificate for systems that require one.

When a connection authenticates through a provider's sign-in screen, saving it is not the last step — it stays in a waiting state until you authorise it. Starting the authorisation sends you to the provider to approve access, and the provider returns you to Pyron with the connection live.

Once saved, a connection is ready for your automations to use. The operators that make outbound calls — the steps that fetch data from another system or send it a request — refer to the connection by name, so updating a credential in one place flows through to every automation that relies on it.

Credentials are write-only

Every secret you give a connection — an API key, a token, a password, a signing secret, or a certificate — is stored in a protected vault and never shown again. The list and the connection form tell you whether a credential is set, but never reveal the value itself. A saved secret cannot be read back by anyone, including you.

This shapes how you edit a connection. When you reopen one, its credential fields are empty: leave a field empty to keep the stored secret in place, or enter a new value to replace it. Changing a connection's name, address, or other settings leaves the credentials it already holds untouched.