Connect an app through its owner’s hosted authorization
Discover an enabled app, preserve the connection attempt and verify active ownership after hosted authorization.
Distinguish link lifetime, account activation and uncertain creation before deciding whether to reconnect.
The hosted authorize_url starts a provider-owned account authorization flow. It is not a permanent application credential, and saving it forever does not preserve access. Composio’s link API returns session information including expiry, while Lupin exposes a sanitized authorization result for the pending connection. Do not promise a fixed link lifetime unless it is documented for the actual deployed flow. If an owner returns to an old browser tab, first determine whether the account was already activated, remains pending or belongs to an uncertain creation attempt.
Use GET /v0/connections to refresh authoritative provider status. An already active account may need no new authorization even if its old setup link no longer opens. A pending account needs the existing lifecycle investigated; a provider failure is not proof that the account does not exist. Keep the connection ID and original operation key with the pending setup UI. A callback URL’s status query cannot establish activation, and an expired tab should not cause the application to create a fresh connection automatically on every reload.
Creation and reconnect use durable journals so an interrupted response cannot safely be interpreted as no provider effect. When reconciliation_required appears, retain the same operation key and operation ID. Repeating the same key can replay a known outcome or recover local persistence, but it is not a request to mint a new authorization session. Changing the key solely to obtain a fresh URL can create another provider-side account and reserve more capacity. Escalate the existing operation to the operator if its outcome remains uncertain before initiating any replacement.
For a known connection that needs renewed authorization, reconnect creates a deliberate replacement under a saved operation key and keeps the old account registered while the owner completes the flow. Finish the pending authorization or disconnect before starting another reconnect. The owner should verify the account and scopes in the hosted page rather than forwarding the URL into a shared chat. Treat authorization links as sensitive setup artifacts and keep them out of analytics, public issues and reusable documentation. They are not a suitable substitute for the application’s authenticated connection management interface.
Show the selected app and saved connection, offer a status refresh and distinguish active, pending and reconciliation conditions. If a new owner-authorized reconnect is appropriate, explain that it replaces authorization and invalidates earlier revision-bound tool approvals. After activation, rediscover tools and request fresh action approval. A synthetic test should open an expired link after successful activation and another after an uncertain response, asserting that neither case blindly creates a duplicate connection. This makes recovery understandable without relying on undocumented expiry assumptions or asking the owner to handle provider tokens directly.
A stale-link screen should refresh the saved account’s state instead of using a client-side countdown as the source of truth. The provider can activate or revoke an account while a browser tab remains open. State-driven recovery handles those cases without claiming an undocumented number of minutes guarantees link validity or invalidity.
Reviewed against current checked-in Lupin routes, shared contracts and official provider references. No live calls, OAuth authorizations, app actions or purchases were performed.
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.