Select a connected account before discovering or approving tools

Make account selection part of the task

A workspace can have several reasons to connect the same service: personal scheduling, a shared operations mailbox or a separate client organization. App identity alone cannot distinguish them. Start by asking which account owns the resource the task needs, then save the selected Lupin connection ID with the workflow. Use the sanitized account view to help the owner verify the choice. Avoid routing through whichever matching app appears first in a list, because sorting and account lifecycle changes can silently alter that choice without changing the user’s request.

Check provider ownership and active state

GET /v0/connections refreshes the provider-reported status and verifies the account user_id against the workspace organization. An alias helps a person recognize an account but is not a security boundary. Keep your own purpose label separate from provider identity and never treat a renamed display string as proof of changed ownership. If the account is inactive or pending replacement, resolve that lifecycle before tool work. A successful prior action does not guarantee current access after an owner revokes provider consent or an operator disables the app.

Discover tools under the selected connection

Pass the chosen connection ID to the tools endpoint. Save the response’s connection_revision alongside the concrete tool version and proposed arguments. Lupin verifies the active account and toolkit before discovery, then checks them again at execution. This binds an approval to a particular account state rather than a broad app capability. For example, a proposed calendar operation for a work account must not automatically move to a personal account if the first connection becomes unavailable. A fallback account can change data visibility and outward effects even when the operation name stays the same.

Reapprove after replacement or switching

Reconnect can preserve the local connection ID while replacing its underlying provider account. The account revision detects that change and invalidates old execution context. When connection_changed appears, rediscover and ask the owner to approve the updated proposal. Do not replace the revision in a pending request and continue under the earlier yes. The same rule applies when the user intentionally selects another account. Present the revised account and exact action together so the decision remains understandable without requiring the human to inspect opaque provider identifiers.

Test account confusion with synthetic identities

Create two fake accounts for the same toolkit with different intended purposes and distinct revisions. Verify that listing order does not alter a saved task selection, a reconnect changes the revision, and an approval for one account cannot execute on the other. Include a similarly named alias to catch UI ambiguity. Record the selected connection, purpose and task outcome in an access-controlled audit record without storing credentials. These fixtures target a real class of cross-account mistakes and give the application a clear recovery path when the desired account is temporarily unavailable.

Reject an automatic fallback account

If the approved work calendar connection becomes inactive, keep the task pending and identify that account’s recovery step. Do not switch to an active personal calendar merely to complete the request. A successful event creation in the wrong account is a routing failure, even if every HTTP request returns success.

Sources & verification

Reviewed against current checked-in Lupin routes, shared contracts and official provider references. No live calls, OAuth authorizations, app actions or purchases were performed.

• Lupin connections ↗Checked 2026-11-05
• Composio hosted account link API ↗Checked 2026-11-05
• Composio execute tool API ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.