# Request access to an integration

## 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`](/reference/mcp-tools/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](/integrations/integrations#what-a-product-can-see-about-connections-it-is-not-attached-to).
2. **File the request.** [`organization_connectors_request`](/reference/mcp-tools/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`](/reference/mcp-tools/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`](/reference/mcp-tools/organization_connectors_approve-request) or [`organization_connectors_deny-request`](/reference/mcp-tools/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](/access/roles-and-permissions). `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

- [Understand what attachment grants](/integrations/integrations#what-a-product-actually-gets): how narrow the access is, provider by provider.
- [Connect a new external account](/integrations/integrations#connecting): if no connection exists yet, an owner or admin starts one.
- [Browse the MCP tools](/reference/mcp-tools): the request and approval tools with their arguments.