Skip to main content
Provider connections reduce manual setup. Squasher starts the provider’s consent or infrastructure flow, creates only the resources needed for the selected Squasher project, and records the resources that it owns.

​
Supported providers

​
Connection lifecycle

  1. Select a provider in Integrations.
  2. Review the requested provider permissions and project, account, workspace, or service scope.
  3. Complete the provider consent, installation, API-key, or CloudFormation step.
  4. Use Verify to check the saved connection and its provider-owned resources.
  5. Use Repair to reconcile supported resources if they change outside Squasher.
  6. Disconnect to remove the remote resources that Squasher created and revoke its stored access.
After an OAuth or provider-installation callback, Squasher returns you to the Integrations page and shows a clear success or failure message. A failed callback does not leave you on an API error page. You can start the setup again from the same provider card. Squasher does not remove a provider resource that it did not create. If another tool already owns a single account-level stream or policy, setup stops or offers a narrower fallback instead of replacing that resource. Verify does not create a provider test event. Credential-gated live integration tests run only as operator release checks against dedicated provider test accounts; they are not part of the customer connection flow.

​
How the Integrations page is organized

The project Integrations page puts operational state before the provider catalog:
  • Needs action means authorization, project binding, or resource readiness is incomplete. Open the provider to repair the connection or finish its scope.
  • Connected shows active and provisioning connections. Authorization, project binding, and data state remain separate so a valid OAuth grant is not mistaken for a working data path.
  • Available integrations is the searchable catalog for providers that are not configured.
Users without integration-management permission can inspect these states, but the setup and repair controls stay read-only.

​
Agent operations

The connection framework manages authorization and provider resources. It does not give an agent a general-purpose HTTP client. Agent actions use the declared Squasher operations for that provider. Squasher checks the current project, validates the request, and requires confirmation for dangerous or destructive actions. MCP agents can discover supported providers, read connection state and readiness, and prepare a safe setup plan for the user. MCP does not expose setup-plan creation, OAuth consent, repair, or disconnect. Complete those interactive or mutating steps in the Squasher dashboard. The public API can create a short-lived setup URL, but a person must open that URL and approve the provider consent or installation. An API client cannot approve OAuth on the user’s behalf. The CLI can open a browser for the OAuth providers supported by squasher integrations connect; it does not provide non-interactive OAuth or a generic one-click repair and disconnect flow. For exact surface limits, see the Provider connections API.