Skip to content

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.

Ask — the product’s Integrations page

Open the product’s Integrations page, at /{product}/integrations. It shows three groups, always in this order: Granted by the org, Available in the org, and Your own.

Available in the org is the group to use. It carries the subtitle “request access — an org admin approves”, and each row shows the provider, the external account it belongs to, and a Request button. Press it and the request is filed; the row then reads as pending until someone decides. A row for a connection this product was already refused is marked “previously denied” and still offers Request — a denial is not a lock.

The group is additive, so it fails quietly. If the list of available connections cannot be loaded, the page still renders everything else, with no error banner and no group — the same as having nothing on offer.

Decide — the organization’s Integrations page

Open the organization’s Integrations page. Each connection is a card, and a card with waiting requests carries a Needs your review block with the number of requests. Every row names the product that asked and the date it was filed, and offers Approve and Deny. A connection with nothing pending shows no block at all, so an empty queue looks empty.

The same flow from an agent

Nobody has to call a tool — the web app carries the whole flow. Over MCP it is four steps:

  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.

Who may do what

Access requests do not go through roles and permissions. Every operation in this flow is a user-scope operation, which means the permission check is skipped and the handler behind it decides for itself — see what user scope means in the catalog. organization_connectors_request is therefore informational: it is listed in the catalog, but it cannot be granted through a role and does not appear in permission pickers.

What the handlers check:

  • Listing available connections and filing a request — membership of the product. Any member qualifies, viewers included.
  • Listing, approving and denying requests — being an owner or admin of the organization that holds the connection.

An API key works on all of these. A product API key resolves to the human who owns it, and the checks above then run against that person’s membership and organization role — not against the key. So a request can be filed with a key, and it is the key owner’s standing that decides whether it goes through.

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

  • Approval re-checks the organization. Approving verifies that the product still belongs to the connection’s organization at that moment, so a stale request can never 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.

↑↓navigate↵select