IntegrationApiSpecProvider
objectAPI spec provider registered by a catalog integration.
Integrations can function as API spec providers where they register a globally unique
type and config schema which defines the shape of config.
Consult integration documentation to learn more about available API spec providers.
The globally unique API spec provider type that is registered by a given catalog integration.
>= 1 characters<= 120 characters
Example:swaggerhub_api_version
JSON object containing values as defined by integration provider’s config schema.
Example:{"owner":"petco","api":"pet_store","version":"v3"}
Short-hand descriptor of an integration installed within the catalog.
Show Child Parameters
ResourceBoundIntegrationApiSpecProvider
objectAPI spec provider registered by a catalog integration.
These providers differ from IntegrationApiSpecProvider in that they
denote a binding relationship between a resource type and the API spec.
This means that the API Spec will automatically be created/deleted for/from a service
as resources of the given type are mapped/unmapped.
Consult integration documentation to learn more about available API spec providers.
The globally unique API spec provider type that is registered by a given catalog integration.
Resource-bound providers create a 1-to-1 mapping between a resource type and the API Spec.
>= 1 characters<= 120 characters
Show Child Parameters
Short-hand descriptor of an integration installed within the catalog.
Show Child Parameters
ResourceBoundIntegrationApiSpecProviderPayload
objectAPI spec provider registered by a catalog integration.
These providers differ from IntegrationApiSpecProvider in that they
denote a binding relationship between a resource type and the API spec.
This means that the API Spec will automatically be created/deleted for/from a service
as resources of the given type are mapped/unmapped.
Consult integration documentation to learn more about available API spec providers.
The globally unique API spec provider type that is registered by a given catalog integration.
Resource-bound providers create a 1-to-1 mapping between a resource type and the API Spec.
>= 1 characters<= 120 characters
Show Child Parameters
CatalogIntegrationFilterParameters
objectOne OfFilter using one of the following operators: eq, oeq, neq, contains, ocontains
Show Child Parameters
One OfFilter using one of the following operators: eq, oeq, neq, contains, ocontains
Show Child Parameters
One OfFilter using one of the following operators: eq, oeq, neq, contains, ocontains
Show Child Parameters
CatalogIntegration
objectThe 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:
- 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}}
Defines how the integration participates in Discovery.
Discovery enables integrations to automatically ingest and update resources in the catalog.
Show Child Parameters
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
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}}}}
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.