Skip to content

Integrations

Request access to an integration

Ask an organization owner or admin to attach an existing connection to your product.

Problem

Your product is not attached to one of its organization’s connections, and you need it. Re-running the provider connect flow would not work, because an external account can be connected only once per organization. The path is to ask: a member of the product files a request, and an organization owner or admin decides.

Product App

  1. Open Integrations for your product, at /{product}/integrations. Alongside the connections already attached to your product, the page lists the other connections in the organization that your product could request.
  2. File a request for the connection you need.
  3. The request lands in the organization’s queue. An organization owner or admin opens Integrations for the organization, where every connection and the queue of access requests are listed, and approves or denies it.

The two Integrations pages are described in Integrations; the step-by-step UI walkthrough lands in the next docs cycle.

MCP

The same flow through the Lessly MCP server in your agent.

  1. See the connection. organization_connectors_list-available lists the organization’s connections that are not attached to your product. The listing is thin: provider, external account, display name, status, and whether this product already has a pending or denied request. See what a product can see about connections it is not attached to.
  2. File the request. organization_connectors_request creates a pending request for that connection and that product. Any member of the product may do this, including a viewer — filing a request grants nothing, so the approval is the gate, not the request.
  3. It lands in the organization queue. Organization owners and admins list requests with organization_connectors_list-requests, optionally filtered by status. Each entry names the connection, its provider and display name, the product, who asked, the status, and when it was filed.
  4. An owner or admin resolves it with organization_connectors_approve-request or organization_connectors_deny-request.

Request states

A request is pending, approved, or denied.

  • Pending — waiting for a decision. A product can have only one pending request per connection at a time. Asking again while one is open is rejected, as is asking for a connection the product is already attached to.
  • Approved — the product is attached to the connection in the same operation that resolves the request. From that moment the product sees the integration and can use it, exactly as if an owner had attached it directly; the attachment is recorded as granted by the organization. Nothing further is needed.
  • Denied — nothing is attached and nothing changes for the product. The denial is recorded and shows up as the product’s request status in the available-connections listing. A denial is not permanent: because only pending requests are unique, the product may file a new request for the same connection later.

Who may approve

Only an organization owner or admin may approve or deny. Product roles carry no weight here — being an admin of the product does not let you approve a request for it. That split is the point: the organization owns the connection, so the organization decides which products reach it.

Edge cases

  • The product moved organizations. Products can be moved between organizations while connections stay behind. Approval checks that the product still belongs to the connection’s organization at the moment it is approved. A request left over from before a move cannot attach a connection belonging to another organization.
  • Stale requests can always be cleared. Denying a request is not blocked by those checks, so an owner can always clear a queue entry that no longer makes sense.
  • The connection was deleted. Requests do not survive their connection or their product; removing either clears its requests.

Next steps

Was this page helpful?
Esc

Start typing to search the docs.

navigateselect