---
title: "List Integrations"
method: GET
path: "/v1/integrations"
tags: ["Catalog Integrations"]
---

# List Integrations

`GET /v1/integrations`

Returns a paginated collection of all catalog integrations available to connect.
Each integration represents a built-in connector that extends the platform's capabilities;
enabling discovery, resource management, event ingestion, and more.
Integrations expose metadata that describes how they authenticate, what configuration they
require, and how they interact with catalog entities like Resources and Services.

Currently, integrations are platform-defined and cannot be extend or registered by customers.

## Query parameters

- `page[size]` integer
- `page[number]` integer
- `filter` CatalogIntegrationFilterParameters
  - `name` StringFieldFilter — Filter using **one** of the following operators: `eq`, `oeq`, `neq`, `contains`, `ocontains`
    - `eq` string — The field exactly matches the provided value.
    - `contains` string — The field contains the provided value.
    - `ocontains` string — The field contains any of the provided values.
    - `oeq` string — The field matches any of the provided values.
    - `neq` string — The field does not match the provided value.
  - `display_name` StringFieldFilter — Filter using **one** of the following operators: `eq`, `oeq`, `neq`, `contains`, `ocontains`
    - `eq` string — The field exactly matches the provided value.
    - `contains` string — The field contains the provided value.
    - `ocontains` string — The field contains any of the provided values.
    - `oeq` string — The field matches any of the provided values.
    - `neq` string — The field does not match the provided value.
- `sort` string — The `asc` suffix is optional as the default sort order is ascending. The `desc` suffix is used to specify a descending order. Multiple sort attributes may be provided via a comma separated list. JSONPath notation may be used to specify a sub-attribute (eg: 'foo.bar desc').

## Response `200`

A paginated list response for a collection of integrations.

- object
  - `meta` PaginatedMeta, required — returns the pagination information
    - `page` PageMeta, required — Contains pagination query parameters and the total number of objects returned.
      - `number` number, required
      - `size` number, required
      - `total` number, required
  - `data` CatalogIntegration[], required
    - `name` string, required — The machine name of the integration that uniquely identifies it within the catalog.
    - `display_name` string, required — The display name of the integration.
    - `description` string — The description of the integration.
    - `built_in` boolean, required — Denotes whether the integration is built-in to the catalog. Built-in integrations are always connected and available by default.
    - `version` string, required — The integration version.
    - `visibility` 'public' | 'private', required — The visibility of the integration.
    - `authorization` union, required — Defines the authorization strategy for an integration.
      - object, nullable
      - OAuth — Defines the OAuth 2.0 authorization strategy used by an integration. This schema provides all necessary information for the platform to initiate and manage OAuth-based authorization flows on behalf of customers.
        - `type` 'oauth', required
        - `overridable_config` string[] — A list of field names from the `config` object (e.g., `client_id`, `authorization_endpoint`, etc) that can be overridden on a per-customer basis. When a field is listed here, the catalog allows customer-defined values to take precedence over the default configuration provided by the integration. This supports flexible deployment models, including both SaaS-based and self-hosted OAuth authorization flows.
        - `config` object, required
          - `grant_type` 'authorization_code', required — The OAuth 2.0 grant type used for authorization (e.g., `authorization_code`). Determines the flow the integration uses to request access tokens.
          - `client_id` string, required — The OAuth client identifier registered with the integration provider.
          - `authorization_endpoint` object, required
            - `url` string, uri, required — The URL where users are redirected to authorize access.
          - `token_endpoint` object, required
            - `url` string, uri, required — The URL used to retrieve access tokens.
          - `scope` string[], required — A list of permission scopes requested by the integration. Defines what level of access the token will grant.
          - `scope_delimiter` string — A string used to separate multiple scopes in the `scope` parameter.
          - `rolling_refresh_exp_seconds` number, nullable, required — Number of seconds before the refresh token grant can no longer be used to mint a new access token. Once expired clients must re-authenticate to restart the window interval.
      - MultiKeyAuth — Defines an authentication strategy based on one or more API keys passed via HTTP headers. This strategy supports integrations that require custom headers for credential-based access, allowing flexibility across providers with different authentication header requirements.
        - `type` 'multi_key_auth', required
        - `config` object, required
          - `headers` object[], required — A list of header definitions used to transmit API credentials to the integration's external API. Each header represents a unique key required by the provider.
            - `name` string, required — The exact name of the HTTP request header where the credential should be inserted.
            - `display_name` string, nullable, required — An optional user-friendly label for the key, used in UI forms to guide users.
            - `description` string, nullable, required — An optional brief explanation of the purpose or usage of the key.
      - GitHubAppInstallationAuth — Defines the GitHub App authorization strategy used by the GitHub integration. This strategy enables secure access to GitHub APIs using app installation tokens. It supports both API-based interactions and real-time event delivery via GitHub webhooks. Unlike standard OAuth flows, this strategy leverages GitHub's custom app installation flow and token lifecycle, making it ideal for deep, organization-level GitHub integration.
        - `type` 'github_app_installation', required
        - `config` object, required
          - `app_install_url` object, required
            - `url` string, uri, required — The URL where customers are directed to install the GitHub App into their GitHub organization.
          - `app_manage_url` object, required
            - `url` string, uri, required — The GitHub App management page URL where users can view, configure, or uninstall the app after installation.
          - `authorize_app_installation_endpoint` object, required
            - `url` string, uri, required — The endpoint used to link a completed GitHub App installation with a customer account in the catalog. This step finalizes the integration by exchanging metadata from the GitHub installation event.
          - `pending_app_installs_endpoint` object, required
            - `url` string, uri, required — The endpoint used to return a list of in-progress or unlinked GitHub App installations awaiting user confirmation.
    - `config_schema` unknown, required
    - `resource_types` CatalogIntegrationResourceTypes, required — Defines the resource types that the integration manages within the catalog. This schema is a key-value object where: - Keys are globally unique, machine-readable identifiers for each resource type. - Values are objects describing metadata about the resource type. This declaration enables the platform to understand the structure, identity, and behavior of resources discovered by the integration. By registering resource types, integrations communicate the kinds of entities they will ingest and maintain, allowing the catalog to enforce consistency, validation, and visibility across all integrations.
    - `discovery` CatalogIntegrationDiscovery, nullable, required — Defines how the integration participates in Discovery. Discovery enables integrations to automatically ingest and update resources in the catalog.
      - `resource_integration_data_examples` object, required — A map of example resource `integration_data` payloads by resource type. - Keys are the machine-readable, globally unique names of resource types registered by this integration. - Values are example `integration_data` payloads.
    - `api_spec_provider` CatalogIntegrationApiSpecProvider, nullable, required — Defines how an integration behaves as a source provider of Catalog Service API specs. API specs are entities that can be attached to Catalog Services. When an integration implements this capability, it can act as a source type for API spec contents. In this role, the integration becomes the source of truth for the spec. When a spec is attached to a Catalog Service using this source type, the platform relies on the external system to provide and update the spec data. A null value indicates the given integration does not act as a source provider of API specs.
      - `name` string, required — The globally unique name of the API spec provider that identifies it within the catalog. Corresponds to the API spec provider `type` when creating API specs.
      - `display_name` string, required — A user-friendly name for the API spec provider.
      - `description` string, required — An brief description of the API spec provider.
      - `config_schema` object, required — Defines the shape of the API spec provider config.
        - `type` 'simple', required
        - `definition` object, required
      - `resource_type` string, nullable, required — When non-null, denotes that the API spec provider is bound to the given Resource type. This means that API specs are auto-created when a Resource of the given type is mapped to a service. Furthermore, it couples the lifecycle of the API Spec with the given Resource mapping. When the given Resource is removed, the API spec will be deleted.
    - `events` CatalogIntegrationEvents, nullable, required — Defines the event types across all resource types belonging to the integration that will be ingested into the catalog. - Keys are the machine-readable, globally unique names of resource types registered by this integration. - Values are a map of event type definitions.

## Other responses

- `400` — Bad Request
- `401` — Unauthorized
- `403` — Forbidden

---

[API](https://skmtc.net/kong/apis/konnect-api-go-sdk.md) · [All operations](https://skmtc.net/kong/apis/konnect-api-go-sdk/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/kong/konnect-api-go-sdk/versions/f920f418f552/schema)