Read connected account state through its full lifecycle

A connection ID is not proof of active access

Creating a hosted link returns a durable connection identity before the owner finishes authorization. The record can therefore exist while its provider account remains initializing or otherwise inactive. Store the connection ID, but do not start app work solely because creation returned successfully. Read GET /v0/connections to refresh the sanitized account view and status. Lupin checks the provider account’s user_id against the workspace organization before presenting it. A familiar alias or an authorize_url is not an equivalent ownership check.

Trust the provider status rather than the return URL

The hosted flow returns the browser to the console for navigation. A query parameter that says status=ACTIVE does not activate the account. Accept readiness only from the subsequent verified provider status read. If authorization is still pending, let the owner complete the existing flow or investigate why the provider has not activated it. Keep UI wording precise: authorization started is different from account connected. This avoids a workflow where the agent promises access and only discovers the missing grant after a sensitive task has already been planned.

Understand replacement during reconnect

Reconnect keeps the old account registered while a replacement authorization is pending. After the provider confirms that the replacement is active, a later list operation retires the old provider account. Finish the pending flow or disconnect before starting another reconnect. This deliberate overlap protects continuity but requires careful state handling. An application must not assume that the same local connection ID guarantees the same underlying account or approval context. Rediscover the account revision and request fresh approval before executing a task after replacement.

Treat disconnect as upstream access revocation

Disconnect validates ownership, requests provider revocation for authorized accounts and deletes the provider account and local registry only after successful cleanup. If revocation fails or is unsupported, Lupin preserves the record and reports failure for operator reconciliation. A hidden row is not evidence that external credentials were revoked. Already revoked or absent provider accounts support retry cleanup, but an unfinished lifecycle lock should not be cleared by deleting local state. Report the observed condition and preserve references needed to establish what access remains at the provider.

Build transitions and recovery into the product

Represent pending authorization, active use, reconnect pending and disconnect failure as operationally meaningful states. Disable tool proposals that require an inactive account and offer the appropriate owner step. For an uncertain creation or reconnect, keep the same idempotency key and operation ID rather than generating another attempt. A useful synthetic test walks through pending creation, verified activation, pending replacement, replacement activation and failed revocation. It should assert both displayed status and whether tool execution is admitted, ensuring the interface does not confuse a durable record with functioning authorization.

Keep replacement identity visible

In a synthetic reconnect, retain the same local connection ID while changing the provider account and revision. Verify that the interface still identifies the intended owner and blocks the earlier approval. This catches a subtle lifecycle defect that a test checking only the continued existence of the local connection row would overlook.

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.