Search
K
Konnect Service Catalog

CatalogIntegration

object
namestringrequiredread-only

The machine name of the integration that uniquely identifies it within the catalog.

Example:gateway-manager

display_namestringrequired

The display name of the integration.

Example:Gateway Manager

descriptionstring

The description of the integration.

built_inbooleanrequiredread-only

Denotes whether the integration is built-in to the catalog.
Built-in integrations are always connected and available by default.

Example:true

versionstringrequiredread-only

The integration version.

Example:v1

visibilitystringrequired

The visibility of the integration.

Allowed values:publicprivate

Example:public

authorizationAny Of
required

Defines the authorization strategy for an integration.

Variant 1object
config_schemarequired

Defines the configuration schema for the integration.

Example:{"base_url":{"type":"string","display_name":"Base URL","description":"The customer-specific API URL","required":true}}

resource_typesobjectrequired

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.

Example:{"gateway_svc":{"display_name":"Gateway Service","schema":{"type":"simple","definition":{"control_plane_id":"string","gatway_service_id":"string"}},"resource_id_template":"{{control_plane_id}}:{{gateway_service_id}}","integration_data_schema":null},"analytics_dashboard":{"display_name":"Dashboard","schema":{"type":"simple","definition":{"dashboard_id":"string"}},"resource_id_template":"{{dashboard_id}}","integration_data_schema":null}}

discoveryobjectrequired

Defines how the integration participates in Discovery.
Discovery enables integrations to automatically ingest and update resources in the catalog.

Show Child Parameters
api_spec_providerobjectrequired

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.

Show Child Parameters
eventsobjectrequired

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.

Example:{"gateway_svc":{"plugin_added":{"display_name":"Plugin Added","description":"Event triggered when a new plugin is added to a gateway service.","events_feed":{"enabled":true}}}}

incident_providerobject

Defines how an integration behaves as a source provider of Catalog Service Incidents.
Incidents are entities that can be attached to Catalog Services via an integration’s Resource mapping.
When an integration implements this capability, it can act as a source type for Incident data.
In this role, the integration becomes the source of truth for the incident data.
When an incident is attached to a Catalog Service using this source type, the platform relies on the external system to provide and update the incident data.
A null value indicates the given integration does not act as a source provider of incidents.

on_call_providerobject

Defines how an integration behaves as a source provider of Catalog Service On-Call schedules.
On-Call schedules are entities that can be attached to Catalog Services via an integration’s Resource mapping.
When an integration implements this capability, it can act as a source type for On-Call data.
In this role, the integration becomes the source of truth for the on-call schedule data.
When an on-call schedule is attached to a Catalog Service using this source type, the platform relies on the external system to provide and update the on-call schedule data.
A null value indicates the given integration does not act as a source provider of on-call schedules.

pull_request_providerobject

Defines how an integration behaves as a source provider of Catalog Service Pull Requests.
Pull Requests are entities that can be attached to Catalog Services via an integration’s Resource mapping.
When an integration implements this capability, it can act as a source type for Pull Request data.
In this role, the integration becomes the source of truth for the pull request data.
When a pull request is attached to a Catalog Service using this source type, the platform relies on the external system to provide and update the pull request data.
A null value indicates the given integration does not act as a source provider of pull requests.

workflow_providerobject

Defines how an integration behaves as a source provider of Catalog Service Workflows.
Workflows are entities that can be attached to Catalog Services via an integration’s Resource mapping.
When an integration implements this capability, it can act as a source type for Workflow data.
In this role, the integration becomes the source of truth for the workflow data.
When a workflow is attached to a Catalog Service using this source type, the platform relies on the external system to provide and update the workflow data.
A null value indicates the given integration does not act as a source provider of workflows.

Example

CatalogIntegrationAuthorization

Defines the authorization strategy for an integration.

Any Of

OAuth

object

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.

typestringrequired

Allowed values:oauth

overridable_configarray[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.

Allowed values:client_idclient_secretauthorization_endpointtoken_endpoint

configobjectrequired
Show Child Parameters
Example

MultiKeyAuth

object

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.

typestringrequired

Allowed values:multi_key_auth

configobjectrequired
Show Child Parameters
Example

GitHubAppInstallationAuth

object

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.

typestringrequired

Allowed values:github_app_installation

configobjectrequired
Show Child Parameters
Example