The name of the integration.
Example:jira
Gets a catalog integration.
The name of the integration.
Example:jira
A response containing a single integration object.
The machine name of the integration that uniquely identifies it within the catalog.
Example:gateway-manager
The display name of the integration.
Example:Gateway Manager
The description of the integration.
Denotes whether the integration is built-in to the catalog.
Built-in integrations are always connected and available by default.
Example:true
The integration version.
Example:v1
The visibility of the integration.
Allowed values:publicprivate
Example:public
Any OfDefines the authorization strategy for an integration.
Defines the configuration schema for the integration.
Example:{"base_url":{"type":"string","display_name":"Base URL","description":"The customer-specific API URL","required":true}}
Defines the resource types that the integration manages within the catalog.
This schema is a key-value object where:
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}}
Defines how the integration participates in Discovery.
Discovery enables integrations to automatically ingest and update resources in the catalog.
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.
Defines the event types across all resource types belonging to the integration that will be ingested into the catalog.
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}}}}
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.
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.
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.
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.
Updates a catalog integration.
The name of the integration.
Example:jira
Description of the integration.
<= 2048 characters
The display name of the catalog integration.
>= 1 characters<= 120 characters
Example:Updated Catalog Integration
A response containing a single integration object.
The machine name of the integration that uniquely identifies it within the catalog.
Example:gateway-manager
The display name of the integration.
Example:Gateway Manager
The description of the integration.
Denotes whether the integration is built-in to the catalog.
Built-in integrations are always connected and available by default.
Example:true
The integration version.
Example:v1
The visibility of the integration.
Allowed values:publicprivate
Example:public
Any OfDefines the authorization strategy for an integration.
Defines the configuration schema for the integration.
Example:{"base_url":{"type":"string","display_name":"Base URL","description":"The customer-specific API URL","required":true}}
Defines the resource types that the integration manages within the catalog.
This schema is a key-value object where:
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}}
Defines how the integration participates in Discovery.
Discovery enables integrations to automatically ingest and update resources in the catalog.
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.
Defines the event types across all resource types belonging to the integration that will be ingested into the catalog.
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}}}}
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.
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.
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.
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.
Deletes a catalog integration.
The name of the integration.
Example:jira
Catalog Integration was deleted successfully.
An integration instance represents a specific account of the integration which contains the resources used to manage and support your services.
Some integrations provide configuration options to customize how it should behave once authorized (see the integration’s manifest for details).
Konnect-internal integrations are built-in and do not need to be installed.
Once an integration instance is created, authorize the instance to allow the Service Catalog to discover its resources.
Note that deleting an integration instance is a destructive operation.
When an integration instance is deleted, all its resources and mappings will be deleted from the service catalog.
In cases where the integration instance’s credentials need to be updated, you may re-authorize the instance to retain all currently discovered resources and mappings.
To set up and view a list of all the integrations we support, please view our documentation.
Creates an integration instance.
The type of integration instance to create.
Match pattern:^[0-9a-z.-]+$
>= 1 characters<= 120 characters
Example:aws-lambda
The machine name of the integration instance that uniquely identifies it within the catalog.
Match pattern:^[0-9a-z.-]+$
>= 1 characters<= 120 characters
Example:aws-lambda-prod
The display name of the integration instance.
>= 1 characters<= 120 characters
Example:AWS (prod)
Optionally provide a description of the integration instance.
<= 2048 characters
JSON object representing configuration specific to the integration instance.
The expected schema depends on the integration type and is dynamically registered at runtime.
Default:{}
Example:{"account_region":"eu"}
A response containing a single integration instance object.
Information about an integration instance.
The integration instance ID.
Example:3f51fa25-310a-421d-bd1a-007f859021a3
The machine name of the integration instance that uniquely identifies it within the catalog.
Match pattern:^[0-9a-z.-]+$
>= 1 characters<= 120 characters
Example:aws-lambda-prod
The display name of the integration instance.
>= 1 characters<= 120 characters
Example:AWS (prod)
The description of the integration instance.
<= 2048 characters
Short-hand descriptor of an integration that omits instance metadata.
Denotes whether the integration instance has been authorized within the catalog.
Example:true
JSON object representing configuration specific to the integration instance.
The expected schema depends on the integration type and is dynamically registered at runtime.
Default:{}
Example:{"account_region":"eu"}
An ISO-8601 timestamp representation of entity creation date.
Example:2022-11-04T20:10:06.927Z
An ISO-8601 timestamp representation of entity update date.
Example:2022-11-04T20:10:06.927Z