Connections
Connected accounts — link a provider account for your end-user.
Connecting a provider has two sides: your credentials (an auth config) and your end-user's account (a connected account). Stacklink keeps them strictly separate.
Auth config vs connected account
| Auth config | Connected account | |
|---|---|---|
| Belongs to | Your project | One tenant (end-customer) |
| Holds | Your OAuth client id/secret, or an API integration template | The user's authorized account + encrypted credentials |
| Scope | Per provider, per project | Per provider, per tenant |
| Example | "Our Zoho Books OAuth app" | "Acme Corp's Zoho Books org" |
Your side — the OAuth app or API key — is covered in Auth. The end-to-end flow your user walks through is in Connect an end-user account.
Multi-account & resolution
A tenant can connect several accounts for the same provider. At execution time Stacklink resolves which
to use: explicit accountId → accountAlias → the session's single account → the account marked
default. Sessions can require explicit selection when ambiguity matters.
Health, refresh, validate
Project administrators can manage application-owned connections in Toolkits, including their learning settings. This keeps the original account owner and Memory owner. It does not let a personal session or MCP client act as that application's users. Members can manage their own personal connections.
Credentials are kept fresh automatically. A background worker validates accounts near expiry,
refreshes OAuth tokens (single-flight locked), and emits a stacklink.connected_account.expired
event if an account can no longer be used — so your app can prompt the user to reconnect.
Connect real accounts during the trial
Connect accounts during the trial. Connection-status reads are free. Successful toolkit actions use the 100,000 tool calls included for the whole trial. Connection setup adds no tool-call charge.