Connections
Connect an app account once, and reuse it everywhere. The credential never leaves Elizon.
Studio → Settings → Connections holds the app accounts your workflows and Agents act on your behalf with — a Google account, an API key for a SaaS you integrate.
A Connection is not a copy of a credential sitting in a config field. It is an account, and everything that uses it refers to it by name: a node, an Agent, an installed Package. Reconnect it once and every one of them works again.
Why this is not a Secret
Secrets and Connections look similar and solve different problems.
- A Secret is a value. A node's config points at it with
{{secret.KEY}}, and you rotate the value when it changes. - A Connection is an account. Elizon signs in to it, keeps the tokens, and renews them on its own — which a Secret cannot do, because an OAuth token expires and nothing in the vault knows how to get another one.
Use a Secret for a long-lived key you own. Use a Connection for an account you sign in to, and for any key you would rather manage in one place than in six nodes.
Connecting an account
Press Connect account and pick the app.
For an app you sign in to (Google), choose what Elizon may do with the account — each permission says what it buys, not what it is called — and continue to the provider's own consent screen. You come back to this page and the account is listed.
For an API you authenticate with a key, choose how it authenticates (an API key, a username and password, a bearer token, or your own headers) and enter the credential. It is encrypted the moment it arrives and is never shown again.
A Connection is created at the organization level or scoped to one project, the same choice most Settings resources offer. An organization-level Connection is usable from every project; a project-scoped one is not visible from any other.
Google Drive asks for less than you might expect
The only Drive permission on the list is Drive (files this app creates). There is no "all of my Drive" option, and that is on purpose: Elizon can work with files it created and files you hand it explicitly, and it cannot see the rest of your Drive at all. Google calls the wider permission a restricted scope, and no Elizon feature needs it.
What that means in a workflow — including why a Drive step can say "file not found" about a file you are looking at — is in Google Drive.
The Gmail permissions, and why Gmail may not be offered
Gmail has five permissions on the list and each covers one kind of step, so grant only what your workflows use:
| Permission | What it buys |
|---|---|
| Gmail (send) | Sending mail as the account. Reads nothing. |
| Gmail (read-only) | Searching and reading mail and attachments. |
| Gmail (read and change) | Labels, read/unread, archiving — plus reading and sending. |
| Gmail (drafts) | Creating drafts. Reads nothing else. |
| Gmail (labels) | The list of labels, with their ids. Reads no messages. |
A workflow that only sends the weekly digest needs Gmail (send) and nothing more; a step whose permission the account has not granted says which one by name before it runs. Elizon never offers https://mail.google.com/, the permission that grants all of it at once.
Gmail may be missing from the app list entirely. Every one of these is a permission Google classifies as restricted, which an app may only ask for after a security review — so Gmail is off on Elizon's hosted service until that review completes, and a self-hosted deployment turns it on for its own Google client. See Gmail for how.
What each status means
| Status | What happened | What to do |
|---|---|---|
| Connected | The account is working. | Nothing. |
| Last attempt failed | A request did not get through — the provider was unreachable, or a call timed out. | Nothing, usually. The credential is probably fine, and the next run will try again. |
| Expired | Elizon tried to renew the account's access and the provider refused. | Reconnect the account. Runs that need it fail until you do. |
| Revoked | Access was withdrawn — by you, or in the provider's own console. | Restore it at the provider if you meant to keep it, then Reconnect. |
Test calls the provider with the stored credential and writes the outcome back to the list. Entering a credential is not evidence it works, and neither is having connected successfully last week.
Reconnecting
Reconnect sends you through the consent screen again for an account that has expired, and keeps the same Connection — so every node and Agent that refers to it starts working again with nothing else to change.
You must sign in as the same account. Signing in as a different one is refused and nothing is changed: a workflow that refers to this Connection means "the account this is", and quietly repointing it at someone else's mailbox is not an outcome anyone wants.
Deleting
Deleting tells the provider to forget the grant and removes the Connection. Anything that authenticates through it stops working, so the dialog names the workflows that do before you confirm.
Using a Connection
In a workflow. The HTTP Request node's Authentication setting offers Connection — pick the account and the node authenticates as it. The node holds only the account's id; the credential is applied inside Elizon, and never appears in the run record, the node's output, or a log, even if the API you called echoes it back.
If a call comes back 401, Elizon renews the account's access once and retries once. That retry does not come out of the node's own retry setting.
In a Package. A Package can declare that it needs an account for a named app. The install wizard then offers the accounts you have already connected, or a link to connect one — and the Package is installed referring to the account, never to a credential.
Who can do what
| View | Connect / reconnect | Delete | |
|---|---|---|---|
| Owner, Admin | ✔ | ✔ | ✔ |
| Editor | ✔ | ✔ | |
| Normal | ✔ |
Everyone can see which accounts are connected and run a Test, because "why did this step fail?" is unanswerable otherwise. Only Admins and Owners can delete one, because deleting breaks everything that uses it.
Self-hosting
Elizon's cloud uses its own OAuth client. A self-hosted deployment registers its own with each provider and sets:
CONNECTIONS_GOOGLE_CLIENT_ID=...
CONNECTIONS_GOOGLE_CLIENT_SECRET=...The redirect URI to register with the provider is your API's own address plus the callback path:
https://<your-api-host>/api/v1/workspace/connections/oauth/callbackThat is the API host, not the web app's — the callback is served by the backend. Until a client is configured, the Connect button for that app says so rather than sending you into a consent screen that cannot complete.
A Google OAuth client still in testing mode expires refresh tokens after seven days. A Connection made with one will go Expired on its own until the client is verified; that is Google's rule, not Elizon's.
Where the credential lives
In the gateway, encrypted with your organization's own key (AES-256-GCM), and nowhere else.
The workflow worker and the AI workers never receive a token. When a step needs to call an app, it asks the gateway to make the call with a named Connection — so the token exists only inside the one process that holds the key, for the length of one request. Egress goes through the same guard every outbound request does: a redirect to another host drops the credential rather than carrying it along.