serviceIdstringrequired
The id of the service.
Example:7f9fd312-a987-4628-b4c5-bb4f4fddd5f7
apiSpecIdstringrequired
The id of the service.
Example:7f9fd312-a987-4628-b4c5-bb4f4fddd5f7
Get an API Spec Contents
Returns the API spec for the given service.
Specify Accept: application/json to retrieve the contents as JSON.
Specify Accept: application/yaml to retrieve the contents as YAML.
Defaults to JSON format.
get
Path Parameters
Response
Response
Response object containing raw API spec contents
ApiSpecContents
ApiSpecContentsobject
Represents raw API spec contents
* Additional properties are allowed.
get/catalog-services/{serviceId}/api-specs/{apiSpecId}/contents
Authentication
Path Parameters
Catalog Integrations
Integrations are applications, either Konnect-internal or external, which extend the functionality of the Service Catalog.
Install and authorize an integration to discover the resources across your organization which support your services.
Map relevant resources to your services to provide a rich view of cataloged services.
To set up and view a list of all the integrations we support please view our documentation.
Create Integration
Creates a catalog integration.
post
Body
application/json
Body
application/json
CreateCatalogIntegration
CreateCatalogIntegration
One Ofvisibilitystringrequired
Allowed values:private
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}}
descriptionstringrequired
Description of the integration.
<= 2048 characters
display_namestringrequired
The display name of the integration.
>= 1 characters<= 120 characters
Example:My Integration
Response
application/json
Response
application/json
A response containing a single integration object.
CatalogIntegration
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
authorization
Any Ofrequired
Defines the authorization strategy for an integration.
Variant 1object | null
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}}
discoveryobject | nullrequired
Defines how the integration participates in Discovery.
Discovery enables integrations to automatically ingest and update resources in the catalog.
Show Child Parameters
api_spec_providerobject | nullrequired
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
eventsobject | nullrequired
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 | null
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 | null
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 | null
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 | null
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.
post/integrations
Authentication
Body
{
"visibility": "private",
"description": "description of integration",
"display_name": "Catalog Integration",
"resource_types": {
"service": {
"display_name": "Service",
"scope": "service",
"schema": {
"type": "simple",
"definition": {
"id": "string"
}
},
"integration_data_schema": {
"type": "json_schema",
"definition": {
"type": "object",
"properties": {
"id": {
"type": "string",
"example": "456"
}
}
}
},
"resource_id_template": "{{id}}"
}
}
}
application/json
List 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.
get
Query Parameters
page[size]integer
The maximum number of items to include per page. The last page of a collection may include fewer items.
Example:10
page[number]integer
Determines which page of the entities to retrieve.
Example:1
filterobject
Filters a collection of integrations.
Show Child Parameters
sortstring
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’).
Example:created_at desc
Response
application/json
Response
application/json
A paginated list response for a collection of integrations.
* Additional properties are NOT allowed.
metaobjectrequired
returns the pagination information
Show Child Parameters
dataarray[object]required
Show Child Parameters
get/integrations
Authentication
Query Parameters
application/json
Get Integration
Gets a catalog integration.
get
Path Parameters
integrationstringrequired
The name of the integration.
Example:jira
Response
application/json
Response
application/json
A response containing a single integration object.
CatalogIntegration
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
authorization
Any Ofrequired
Defines the authorization strategy for an integration.
Variant 1object | null
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}}
discoveryobject | nullrequired
Defines how the integration participates in Discovery.
Discovery enables integrations to automatically ingest and update resources in the catalog.
Show Child Parameters
api_spec_providerobject | nullrequired
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
eventsobject | nullrequired
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 | null
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 | null
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 | null
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 | null
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.
get/integrations/{integration}
Authentication
Path Parameters
application/json