name: Kong Domain Vocabulary provider: Kong providerId: kong description: Tag-derived vocabulary for the Kong API surface; sourced from openapi/ tags. terms: - term: Control Planes - term: Control Plane Groups - term: Auth Settings - term: Invites - term: Roles - term: Team Membership - term: Teams - term: Users - term: System Accounts - term: System Accounts - Access Tokens - term: System Accounts - Roles - term: System Accounts - Team Membership - term: Me - term: Authentication - term: Impersonation Settings - term: Personal Access Tokens - term: Data-Plane Group Configurations - term: Networks - term: Transit Gateways - term: Private DNS - term: Add-Ons - term: Provider Accounts - term: Custom Domains - term: Cloud Gateways Resource Quotas - term: Resource Configurations - term: Resource Availability - term: Notifications description: Operations related to notifications - term: DCR Providers description: "Dynamic Client Registration Providers are configurations representing an external Identity Provider whose\ \ clients (i.e. Applications) Konnect will be authorized to manage.\nFor instance, they will be able to perform dynamic\ \ client registration (DCR) with the provider. \nThe DCR provider provides credentials to each DCR-enabled application\ \ in Konnect that can be used to access Product Versions that the app is registered for." - term: App Auth Strategies description: "Application Auth Strategies are sets of plugin configurations that represent how the gateway will perform\ \ authentication and authorization for a Product Version. \nCalled “Auth Strategy” for short in the context of portals/applications.\ \ \nThe plugins are synced to any Gateway Service that is currently linked or becomes linked to the Product Version." - term: API - term: API Documentation - term: API Specification - term: API Publication - term: API Image - term: API Implementation - term: API Operations - term: API Attributes - term: API Packages - term: API Package Operations - term: API Package Documentation - term: API Package Image - term: Portals description: APIs related to configuration of Konnect Developer Portals. - term: Portal Custom Domains description: APIs related to configuration of Konnect Developer Portals custom domains. - term: Portal Customization description: APIs related to customization of Konnect Developer Portals. - term: Portal Auth Settings description: APIs related to configuration of Konnect Developer Portal auth settings. - term: Portal Developers description: APIs related to Konnect Developer Portal developers. - term: Portal Teams description: APIs related to configuration of Konnect Developer Portal developer teams. - term: Portal Team Membership description: APIs related to Konnect Developer Portal developer team membership. - term: Portal Team Roles description: APIs related to Konnect Developer Portal developer team roles. - term: Portal Integrations description: APIs to configure Konnect Developer Portal integrations. - term: Assets description: APIs for managing static assets for Konnect Developer Portals. - term: Pages description: APIs related to Konnect Developer Portal Custom Pages. - term: Snippets description: APIs related to Konnect Developer Portal Custom Snippets. - term: Applications description: APIs related to Konnect Developer Portal Applications. - term: Application Registrations description: APIs related to Konnect Developer Portal Application Registrations. - term: Portal Emails description: APIs related to Konnect Developer Portal Emails. - term: Portals IP Allow List description: APIs related to Konnect Portal IP Allow List. - term: Catalog Services description: 'Create and maintain a centralized catalog of all services running in your organization. Add custom fields and map resources from across your organization to provide a 360-degree overview of your services. Custom fields allow you to surface key information such as: - `Owner`: The person or team responsible for the service - `Product Manager`: The person assigned to guide the service''s direction for customer success - `Jira Project`: The Jira project which represents past, present and future work for the service Resources are discovered from the integrations you use within your organization to create, operate and manage your services. Mapping the resources relevant to your service will provide a rich view of the service''s communication channels, dependencies and more. Types of resources which you can map to a service include: - `Code Repositories:` The software project(s) that make up the service - `Monitors and Dashboards:` Tools providing visibility into the health and performance of the service - `Communication Channels`: Virtual spaces where questions and concerns can be raised about the service - `Incident Management Resources`: Alerts setup within your incident management platform to notify individuals regarding issues with the service' - term: Catalog Integrations description: '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](https://developer.konghq.com/service-catalog/integrations/).' - term: Integration Instances description: '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](https://developer.konghq.com/service-catalog/integrations/).' - term: Integration Instance Auth Credentials description: 'Represents the credentials use to authorize an integration instance. You will want to configure the integration instance settings and authorization configuration before authorizing the instance. This will inform the authorization process on how to reach and authorize the account. Once the integration instance is authorized, the system will automatically discover all the relevant resources from the account. The integration instance''s auth credentials can be removed or updated while retaining all resources which have already been discovered.' - term: Integration Instance Auth Config description: 'A integration instance may need to be provided with an auth config before authorizing the instance. Typically an auth config will be required when authorizing against a integration which is hosted within your organization. The integration instance''s auth config will inform how the Service Catalog will authorize the integration instance. Note that updating the auth config for an instance which is already authorized will **remove the existing credential**, requiring you to re-authorize the instance.' - term: Catalog Resources description: 'Resources are entities discovered from integration instances and are intended to be mapped to the relevant services in the catalog. Once a resource has been mapped to a service, a rich view of this resource will be displayed when viewing your service. Any resources which you would like to ignore and hide can be archived. Note that archiving a resource will **remove** any mappings it has to services in the catalog. You can create Resources using only the properties required to identify the resource in the third-party system. Additional data will be hydrated if the integration that the Resource is linked to has been provided with authentication credentials. Resources which have not yet been hydrated may still be mapped to a Catalog Service.' - term: Catalog Resource Mappings description: 'Resource mappings represent the link between a resource and a service. Once a resource is mapped to a service, a rich view of the resource will be presented on the service page. A resource may be mapped to multiple services, but it cannot be mapped to the same service twice. If a resource mapped to a service is later archived, the resource mapping will be deleted.' - term: Catalog Service Resources description: Represents all the resources mapped to a specific service. - term: Catalog Resource Services description: Represents all the services mapped to a specific resource. - term: Criteria Templates description: 'Several criteria templates are provided to help ensure your services adhere to industry best practices. A criteria template is a collection of criteria grouped together to target various categories. Criteria may require a specific type of integration be installed and authorized. For example, criteria which evaluates the operation performance across incident management may require a integration related to incident management to be installed and authorized. Learn more about scorecards by visiting our [documentation](https://developer.konghq.com/service-catalog/scorecards/).' - term: Scorecards description: 'A scorecard helps you evaluate services based on its criteria. Scorecards help you detect issues, like whether there are services in the catalog that don''t have an on-call engineer assigned, or if you have GitHub repositories with stale pull requests that aren''t getting reviewed or closed. From the scorecard, you can view details on either a per-service or per-criteria basis. Learn more about scorecards by visiting our [documentation](https://developer.konghq.com/service-catalog/scorecards/).' - term: Catalog Service API Mappings description: 'Service API mappings represent the link between Service and API entities. Once an API is mapped to a Service, a rich view of the linked APIs will be presented on the APIs tab of the Catalog Service. Similarly, Services mapped to an API will be listed on the API overview page under Catalog. An API may be mapped to multiple services, but it cannot be mapped to the same service twice. If a mapped API is unlinked from a Service, the mapping will be deleted.' - term: Event Gateways description: Create an Event Gateway Control Plane, used to store Event Gateway configuration - term: Event Gateway Backend Clusters description: 'A backend cluster is an abstraction of a real Kafka cluster. It stores the connection and configuration details required for Kong Event Gateway to proxy traffic to Kafka. Multiple Kafka clusters can be proxied through a single Kong Event Gateway.' - term: Event Gateway Virtual Clusters description: Virtual clusters are the primary way clients interact with the Event Gateway proxy. They allow you to isolate clients from each other when connecting to the same backend cluster, and provide each client with modified view while still appearing as a standard Kafka cluster. - term: Event Gateway Listeners description: 'A listener represents hostname-port or IP-port combinations that connect to TCP sockets. Listeners need at least as many ports as backend brokers if you use port mapping in a Forward to Virtual Cluster policy. For SNI routing, you can route all brokers using a listener with only one port. Ports can be expressed as a single port or range. Addresses can be IPv4, IPv6, or hostnames. A listener can have policies that enforce TLS certificates and perform SNI routing. The listener runs at Layer 4 of the network stack. In Kong Event Gateway, listeners first take in the connection and then route the TCP connection to a virtual cluster based on conditions defined in listener policies.' - term: Event Gateway Listener Policies description: 'Policies control how Kafka protocol traffic is modified between the client and the backend cluster. Listener policies are routing policies that pass traffic to the virtual cluster.' - term: Event Gateway Virtual Cluster Policies description: 'Policies control how Kafka protocol traffic is modified between the client and the backend cluster. Cluster policies are transformation and validation policies that can be applied to Kafka messages.' - term: Event Gateway Virtual Cluster Produce Policies description: 'Produce policies operate on Kafka messages before they are written to the Kafka cluster. Where possible, apply transformations to the data using produce policies rather than consume policies for maximum efficiency.' - term: Event Gateway Virtual Cluster Consume Policies description: 'Consume policies operate on Kafka messages as they are read from a Kafka cluster. Transformations may be applied at consume time, but they are applied once per Consumer. Where possible, transofmrations should be applied as a Produce policy' - term: Event Gateway DataPlane Certificates description: DataPlane certificates control how your running Event Gateway instances connect to the Control Plane - term: Event Gateway Static Keys description: Static Keys are used by the Encrypt and Decrypt policies to encrypt data at rest - term: Event Gateway Schema Registries description: Configure a schema registry that can be used to validate payloads when producing/consuming messages - term: Event Gateway TLS Trust Bundles description: 'A TLS trust bundle defines a set of trusted certificate authorities (CAs) used for client certificate verification during mutual TLS (mTLS). Trust bundles are referenced by TLS listener policies to determine which client certificates are accepted.' - term: Event Gateway Nodes - term: OpenMeter Billing description: Billing manages the billing profiles, currencies, cost bases, and invoices for customers. - term: OpenMeter Apps description: Apps enable you to extend and customize billing and usage workflows by integrating with external systems and services. Apps can automate and enhance your billing ecosystem by supporting capabilities such as synchronizing usage data with third-party platforms, calculating taxes, generating and delivering invoices, handling payment collection, and other billing-related tasks. - term: OpenMeter Entitlements description: Entitlements are used to control access to features for customers. - term: OpenMeter Subscriptions description: Subscriptions are used to track usage of your product or service. Subscriptions can be individuals or organizations that can subscribe to plans and have access to features. - term: OpenMeter Customers description: Customers are used to track usage of your product or service. Customers can be individuals or organizations that can subscribe to plans and have access to features. - term: Metering Events description: Metering events are used to track usage of your product or service. Events are processed asynchronously by the meters, so they may not be immediately available for querying. - term: Meters description: Meters specify how to aggregate events for billing and analytics purposes. Meters can be configured with multiple aggregation methods and groupings. Multiple meters can be created for the same event type, enabling flexible metering scenarios. - term: MCP Servers - term: Dashboards - term: DP Nodes description: DP Nodes - term: DP Certificates description: DP Certificates - term: Custom Plugin Schemas description: Custom Plugin Schemas - term: Config Stores description: Config Stores - term: Config Store Secrets description: Config Store Secrets - term: ACLs - term: API-keys - term: Basic-auth credentials - term: CA Certificates description: 'A CA certificate object represents a trusted certificate authority. These objects are used by Kong Gateway to verify the validity of a client or server certificate.' - term: Certificates description: 'A certificate object represents a public certificate, and can be optionally paired with the corresponding private key. These objects are used by Kong Gateway to handle SSL/TLS termination for encrypted requests, or for use as a trusted CA store when validating peer certificate of client/service.

Certificates are optionally associated with SNI objects to tie a cert/key pair to one or more hostnames.

If intermediate certificates are required in addition to the main certificate, they should be concatenated together into one string.' - term: Consumer Groups description: 'Consumer groups enable the organization and categorization of consumers (users or applications) within an API ecosystem. By grouping consumers together, you eliminate the need to manage them individually, providing a scalable, efficient approach to managing configurations.' - term: Consumers description: 'The consumer object represents a consumer - or a user - of a service. You can either rely on Kong Gateway as the primary datastore, or you can map the consumer list with your database to keep consistency between Kong Gateway and your existing primary datastore.' - term: CustomPlugins - term: Degraphql_routes - term: GraphQL Cost Decorations - term: HMAC-auth credentials - term: JWTs - term: KeySets description: A JSON Web key set. Key sets are the preferred way to expose keys to plugins because they tell the plugin where to look for keys or have a scoping mechanism to restrict plugins to specific keys. - term: Keys description: A key object holds a representation of asymmetric keys in various formats. When Kong Gateway or a Kong plugin requires a specific public or private key to perform certain operations, it can use this entity. - term: MTLS-auth credentials - term: Partial Links - term: Partials description: Some entities in Kong Gateway share common configuration settings that often need to be repeated. For example, multiple plugins that connect to Redis may require the same connection settings. Without Partials, you would need to replicate this configuration across all plugins. If the settings change, you would need to update each plugin individually. - term: Plugins description: 'A plugin entity represents a plugin configuration that will be executed during the HTTP request/response lifecycle. Plugins let you add functionality to services that run behind a Kong Gateway instance, like authentication or rate limiting. You can find more information about available plugins and which values each plugin accepts at the [Plugin Hub](https://developer.konghq.com/plugins/).

When adding a plugin configuration to a service, the plugin will run on every request made by a client to that service. If a plugin needs to be tuned to different values for some specific consumers, you can do so by creating a separate plugin instance that specifies both the service and the consumer, through the service and consumer fields.' - term: Routes description: "Route entities define rules to match client requests. Each route is associated with a service, and a service\ \ may have multiple routes associated to it. Every request matching a given route will be proxied to the associated service.\ \ You need at least one matching rule that applies to the protocol being matched by the route.\n

\nThe combination\ \ of routes and services, and the separation of concerns between them, offers a powerful routing mechanism with which\ \ it is possible to define fine-grained entrypoints in Kong Gateway leading to different upstream services of your infrastructure.\n\

\nDepending on the protocol, one of the following attributes must be set:\n
\n\n- `http`: At least one of `methods`,\ \ `hosts`, `headers`, or `paths`\n- `https`: At least one of `methods`, `hosts`, `headers`, `paths`, or `snis`\n- `tcp`:\ \ At least one of `sources` or `destinations`\n- `tls`: at least one of `sources`, `destinations`, or `snis`\n- `tls_passthrough`:\ \ set `snis`\n- `grpc`: At least one of `hosts`, `headers`, or `paths`\n- `grpcs`: At least one of `hosts`, `headers`,\ \ `paths`, or `snis`\n- `ws`: At least one of `hosts`, `headers`, or `paths`\n- `wss`: At least one of `hosts`, `headers`,\ \ `paths`, or `snis`\n\n\n
\n A route can't have both `tls` and `tls_passthrough` protocols at same time.\n

\n\ \ Learn more about the router:\n- [Configure routes using expressions](https://developer.konghq.com/gateway/routing/expressions/)" - term: SNIs description: 'An SNI object represents a many-to-one mapping of hostnames to a certificate.

A certificate object can have many hostnames associated with it. When Kong Gateway receives an SSL request, it uses the SNI field in the Client Hello to look up the certificate object based on the SNI associated with the certificate.' - term: Schemas - term: Services description: 'Service entities are abstractions of your microservice interfaces or formal APIs. For example, a service could be a data transformation microservice or a billing API.

The main attribute of a service is the destination URL for proxying traffic. This URL can be set as a single string or by specifying its protocol, host, port and path individually.

Services are associated to routes, and a single service can have many routes associated with it. Routes are entrypoints in Kong Gateway which define rules to match client requests. Once a route is matched, Kong Gateway proxies the request to its associated service. See the [Route documentation](https://developer.konghq.com/gateway/entities/route/) for a detailed explanation of how Kong proxies traffic.

Services can be both [tagged and filtered by tags](https://developer.konghq.com/admin-api/).' - term: Targets description: 'A target is an IP address or hostname with a port that identifies an instance of a backend service. Every upstream can have many targets, and the targets can be dynamically added, modified, or deleted. Changes take effect on the fly.

To disable a target, post a new one with `weight=0`, or use the `DELETE` method to accomplish the same.' - term: Upstreams description: 'The upstream object represents a virtual hostname and can be used to load balance incoming requests over multiple services (targets).

An upstream also includes a [health checker](https://developer.konghq.com/gateway/traffic-control/health-checks-circuit-breakers/), which can enable and disable targets based on their ability or inability to serve requests. The configuration for the health checker is stored in the upstream object, and applies to all of its targets.' - term: Vaults description: 'Vault objects are used to configure different vault connectors for [managing secrets](https://developer.konghq.com/gateway/secrets-management/). Configuring a vault lets you reference secrets from other entities. This allows for a proper separation of secrets and configuration and prevents secret sprawl.

For example, you could store a certificate and a key in a vault, then reference them from a certificate entity. This way, the certificate and key are not stored in the entity directly and are more secure.

Secrets rotation can be managed using [TTLs](https://developer.konghq.com/gateway/entities/vault/).'