Implementations¶

This document tracks downstream implementations and integrations of Gateway APIand provides status and resource references for them.

Implementors and integrators of Gateway API are encouraged to update thisdocument with status information about their implementations, the versions theycover, and documentation to help users get started. This status information shouldbe no longer than a few paragraphs.

Conformance levels¶

There are three levels of Gateway API conformance:

Conformant implementations¶

These implementations have submitted at least one conformance report that has passes for:

• All core conformance tests for at least one combination of Route type and Profile
• All claimed Extended features

for one of the two (2) most recent Gateway API releases.

So, it's conformant to support Mesh + HTTPRoute, or Gateway + HTTPRoute, orGateway + TLSRoute, or Gateway + Mesh + HTTPRoute, plus any extended featuresthe implementation claims. But implementationsmust support at least oneProfile and one Route type in that profile, and must pass all Core conformancetests for that Profile and Route type in addition to all claimed Extendedfeatures.

Partially Conformant implementations¶

These implementations are aiming for full conformance but are not currentlyachieving it. They have submitted at least one conformance report passing someof the tests to be Conformant (as above) for one of the three (3) most recentGateway API releases. Note that the requirements to be considered "partiallyconformant" may be tightened in a future release of Gateway API.

Stale implementations¶

These implementations may not be being actively developed and will be removedfrom this page on the next page review unless they submit a conformance reportmoving them to one of the other categories.

Page reviews are performed at least one month after every Gateway API release,with the first being performed after the release of Gateway API v1.3, in lateJune 2025. Following the Gateway API v1.5 review process, due in mid-2026,stale implementations will no longer be listed.

Implementation profiles¶

Implementations also generally fall into two categories, which are calledprofiles:

• Gateway controllers reconcile the Gateway resource and are intended tohandle north-south traffic, mainly concerned with coming from outside thecluster to inside.
• Mesh controllers reconcile Service resources with HTTPRoutes attachedand are intended to handle east-west traffic, within the same cluster orset of clusters.

Each profile has a set of conformance tests associated with it, that lay outthe expected behavior for implementations to be conformant (as above).

Implementations may also fit both profiles.

Integrations¶

Also listed on this page areintegrations, which are other softwareprojects that are able to make use of Gateway API resources to performother functions (like managing DNS or creating certificates).

Gateway Controller Implementation Status¶

Conformant¶

• Agent Gateway
• Airlock Microgateway
• Cilium
• Envoy Gateway (GA)
• Istio (GA)
• kgateway (GA)
• NGINX Gateway Fabric (GA)
• Traefik Proxy (GA)

Partially Conformant¶

• AWS Load Balancer Controller (GA)
• Azure Application Gateway for Containers (GA)
• Contour (GA)
• Gloo Gateway (GA)
• Google Kubernetes Engine (GA)
• Gravitee Kubernetes Operator (GA)
• Kong Ingress Controller (GA)
• Kong Gateway Operator (GA)
• Kubvernor(work in progress)

Stale¶

• Acnodal EPIC
• Amazon Elastic Kubernetes Service (GA)
• Apache APISIX (beta)
• Avi Kubernetes Operator
• Easegress (GA)
• Emissary-Ingress (Ambassador API Gateway) (alpha)
• Flomesh Service Mesh (beta)
• HAProxy Ingress (alpha)
• HAProxy Kubernetes Ingress Controller (GA)
• HashiCorp Consul
• Kuma (GA)
• LiteSpeed Ingress Controller
• LoxiLB (beta)
• ngrok (preview)
• STUNner (beta)
• Tyk (work in progress)
• WSO2 APK (GA)

Service Mesh Implementation Status¶

Conformant¶

• Alibaba Cloud Service Mesh (GA)
• Istio (GA)
• Linkerd (GA)
• Cilium (GA)

Stale¶

• Google Cloud Service Mesh (GA)
• Kuma (GA)

Integrations¶

• Flagger (public preview)
• cert-manager (alpha)
• argo-rollouts (alpha)
• Knative (alpha)
• Kuadrant (GA)
• kruise-rollouts (alpha)

Implementations¶

In this section you will find specific links to blog posts, documentation and other Gateway API references for specific implementations.

Acnodal EPIC¶

EPIC is an Open Source External Gateway platform designed and built with Kubernetes. It consists of the Gateway Cluster, k8s Gateway controller, a stand alone Linux Gateway controller and the Gateway Service Manager. Together they create a platform for providing Gateway services to cluster users. Each gateway consists of multiple Envoy instances running on the gateway cluster not the workload clusters. The Gateway Service Manager is a simple user management and UI that can be used to implement Gateway-as-a-Service infrastructure for public and private clusters, and integrate non-k8s endpoints.

• Documentation
• Source Repo

Agent Gateway (with Kgateway)¶

Agent Gateway is an open source Gateway API implementation focusing on AI use cases, including LLM consumption, LLM serving, agent-to-agent (A2A), and agent-to-tool (MCP). It is the first and only proxy designed specifically for the Kubernetes Gateway API, powered by a high performance and scalable Rust dataplane implementation.

Airlock Microgateway¶

Airlock Microgateway is a Kubernetes native WAAP (Web Application and API Protection, formerly known as WAF) solution optimized for Kubernetes environments and certified for Red Hat OpenShift.Modern application security is embedded in the development workflow and follows DevSecOps paradigms.Airlock Microgateway protects your applications and microservices with the tried-and-tested Airlock security features against attacks, while also providing a high degree of scalability.

Features¶

• Comprehensive WAAP (formerly known as WAF) with security features like Deny Rules to protect against known attacks (OWASP Top 10), header filtering, JSON parsing, OpenAPI specification enforcement, and GraphQL schema validation
• Identity aware proxy which makes it possible to enforce authentication using JWT authentication or OIDC, with OAuth 2.0 Token Introspection and Token Exchange for continuous validation and secure delegation across services
• Reverse proxy functionality with request routing rules, TLS termination and remote IP extraction
• Easy-to-use Grafana dashboards which provide valuable insights in allowed and blocked traffic and other metrics

Documentation and links¶

• Product documentation
• Gateway specific documentation
• Check ourAirlock community forum andsupport process for support.

Alibaba Cloud Service Mesh¶

Alibaba Cloud Service Mesh (ASM) provides a fully managed service mesh platform that is compatible with the community Istio. It simplifies service governance, including traffic routing and split management between service calls, authentication security for inter-service communication, and mesh observability capabilities, thereby greatly reducing the workload of development and operations.

Amazon Elastic Kubernetes Service¶

Amazon Elastic Kubernetes Service (EKS) is a managed service that you can use to run Kubernetes on AWS without needing to install, operate, and maintain your own Kubernetes control plane or nodes. EKS's implementation of the Gateway API is throughAWS Gateway API Controller which provisionsAmazon VPC Lattice Resources for gateway(s), HTTPRoute(s) in EKS clusters.

APISIX¶

Apache APISIX is a dynamic, real-time, high-performance API Gateway. APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.

APISIX currently supports Gateway APIv1beta1 version of the specification for itsApache APISIX Ingress Controller.

AWS Load Balancer Controller¶

AWS Load Balancer Controller manages AWS Elastic Load Balancers for Kubernetes clusters. The controller provisions AWS Application Load Balancers (ALB) when you create a Kubernetes Ingress and AWS Network Load Balancers (NLB) when you create a Kubernetes Service of type LoadBalancer.

Gateway API support is GA for both Layer 4 (L4) and Layer 7 (L7) routing, enabling customers to provision and manage AWS NLBs and ALBs directly from Kubernetes clusters using the extensible Gateway API.

See theAWS Load Balancer Controller documentation for information on how to deploy and use the Gateway API implementation.

Avi Kubernetes Operator¶

Avi Kubernetes Operator (AKO) provides L4-L7 load-balancing using VMware AVI Advanced Load Balancer.

Starting with AKO versionv2.1.1, Gateway API version v1.3.0 is supported. It implements v1 version of Gateway API specification supporting GatewayClass, Gateway and HTTPRoute objects.

Documentation to deploy and use AKO Gateway API can be found atAvi Kubernetes Operator Gateway API.

Azure Application Gateway for Containers¶

Application Gateway for Containers is a managed application (layer 7) load balancing solution, providing dynamic traffic management capabilities for workloads running in a Kubernetes cluster in Azure. Follow thequickstart guide to deploy the ALB controller and get started with Gateway API.

Cilium¶

Cilium is an eBPF-based networking, observability and securitysolution for Kubernetes and other networking environments. It includesCiliumService Mesh, a highly efficient mesh data plane that canbe run insidecarless mode to dramatically improveperformance, and avoid the operational complexity of sidecars. Cilium alsosupports the sidecar proxy model, offering choice to users.Cilium supports Gateway API, passing conformance for v1.4.0 as of Cilium 1.19

Cilium is open source and is a CNCF Graduated project.

If you have questions about Cilium Service Mesh the #service-mesh channel onCilium Slack is a good place to start. For contributing to the developmenteffort, check out the #development channel or join ourweekly developer meeting.

Contour¶

Contour is a CNCF open source Envoy-based ingress controller for Kubernetes.

Contourv1.31.0 implements Gateway API v1.2.1.AllStandard channel v1 API group resources (GatewayClass, Gateway, HTTPRoute, ReferenceGrant), plus most v1alpha2 API group resources (TLSRoute, TCPRoute, GRPCRoute, ReferenceGrant, and BackendTLSPolicy) are supported.Contour's implementation passes most core extended Gateway API conformance tests included in the v1.2.1 release.

See theContour Gateway API Guide for information on how to deploy and use Contour's Gateway API implementation.

For help and support with Contour's implementation,create an issue or ask for help in the#contour channel on Kubernetes slack.

Easegress¶

Easegress is a Cloud Native traffic orchestration system.

It can function as a sophisticated modern gateway, a robust distributed cluster, a flexible traffic orchestrator, or even an accessible service mesh.

Easegress currently supports Gateway APIv1beta1 version of the specification byGatewayController.

Emissary-Ingress (Ambassador API Gateway)¶

Emissary-Ingress (formerly known as Ambassador API Gateway) is an open source CNCF project thatprovides an ingress controller and API gateway for Kubernetes built on top ofEnvoy Proxy.Seehere for more details on using the Gateway API with Emissary.

Envoy Gateway¶

Envoy Gateway is anEnvoy subproject for managing Envoy-based application gateways. The supportedAPIs and fields of the Gateway API are outlinedhere.Use thequickstart to get Envoy Gateway running with Gateway API in afew simple steps.

Flomesh Service Mesh (FSM)¶

Flomesh Service Mesh is a community driven lightweight service mesh for Kubernetes East-West and North-South traffic management. Flomesh usesebpf for layer4 andpipy proxy for layer7 traffic management. Flomesh comes bundled with a load balancer, cross-cluster service registration/discovery and it supports multi-cluster networking. It supportsIngress (and as such is an "Ingress controller") and Gateway API.

FSM support of Gateway API is built on topFlomesh Gateway API and it currently supports Kubernetes Gateway API versionv0.7.1 with support forv0.8.0 currently in progress.

• FSM Kubernetes Gateway API compatibility matrix
• How to use Gateway API support in FSM

Gloo Gateway¶

Gloo Gateway bySolo.io is a feature-rich, Kubernetes-native ingress controller and next-generation API gateway.Gloo Gateway brings the full power and community support of Gateway API to its existing control-plane implementation.

The Gloo Gateway ingress controller passes all the core Gateway API conformance tests in the v1.1.0 release for the GATEWAY_HTTP conformanceprofile exceptHTTPRouteServiceTypes.

Google Cloud Service Mesh¶

Google Kubernetes Engine (GKE) is a managed Kubernetes platform offeredby Google Cloud.

GKE's implementation of Gateway For Mesh (GAMMA) is through theCloud Service Mesh.

Google Cloud Service Mesh supportsEnvoy-based sidecar mesh andProxyless-GRPC (using GRPCRoute).

Google Kubernetes Engine¶

Google Kubernetes Engine (GKE) is a managed Kubernetes platform offeredby Google Cloud. GKE's implementation of the Gateway API is through theGKEGateway controller which provisions Google Cloud Load Balancersfor Pods in GKE clusters.

The GKE Gateway controller supports weighted traffic splitting, mirroring,advanced routing, multi-cluster load balancing and more. See the docs to deployprivate or public Gateways and alsomulti-clusterGateways.

The GKE Gateway controller passes all the core Gateway API conformance tests in thev1.4.0 release for the GATEWAY_HTTP conformance profile exceptHTTPRouteHostnameIntersection.

Gravitee Kubernetes Operator¶

TheGravitee Kubernetes Operator (GKO) lets you manageGravitee APIs, applications, and other assets in a Kubernetes-native and declarative way.

The Gravitee Kubernetes Operator provides partial conformance for Gateway - HTTP features in version 4.10.3. It does not support matching rules across routes. These feature will be introduced in a future release.

For support, feedback, or to engage in a discussion about the Gravitee Kubernetes Operator, please feel free to submit anissue or visit our communityforum.

HAProxy Ingress¶

HAProxy Ingress is a community driven ingress controller implementation for HAProxy.

HAProxy Ingress v0.13 partially supports the Gateway API's v1alpha1 specification. See thecontroller's Gateway API documentation to get informed about conformance and roadmap.

HAProxy Kubernetes Ingress Controller¶

HAProxy Kubernetes Ingress Controller is an open-source project maintained by HAProxy Technologies that provides fast and efficient traffic management, routing, and observability for Kubernetes. It has built-in support for the Gateway API since version 1.10. The same deployment of the ingress controller will allow you to use both the Ingress API and Gateway API. See thedocumentation for more details. In theGitHub repository, you will also find additional information about supported API resources.

HashiCorp Consul¶

Consul, byHashiCorp, is an open source control plane for multi-cloud networking. A single Consul deployment can span bare metal, VM and container environments.

Consul service mesh works on any Kubernetes distribution, connects multiple clusters, and Consul CRDs provide a Kubernetes native workflow to manage traffic patterns and permissions in the mesh.Consul API Gateway supports Gateway API for managing North-South traffic.

Please see theConsul API Gateway documentation for current information on the supported version and features of the Gateway API.

Istio¶

Istio is an open sourceservice mesh and gateway implementation.

A minimal install of Istio can be used to provide a fully compliantimplementation of the Kubernetes Gateway API for cluster ingress trafficcontrol. For service mesh users, Istio also fully supports theGAMMAinitiative's Gateway APIsupport for east-west trafficmanagement within the mesh.

Much of Istio's documentation, including all of theingress tasks and several mesh-internal traffic management tasks, already includes parallel instructions forconfiguring traffic using either the Gateway API or the Istio configuration API.Check out theGateway API task for more information about the Gateway API implementation in Istio.

kgateway¶

Thekgateway project is a feature-rich, Kubernetes-native ingress controller and next-generation API gateway.It is focused on maintaining a great HTTP experience, extending features for advanced routing in scenarios such as AI and MCP gateways, and interoperating with a service mesh such as Istio in both ambient and sidecar modes.This focus means that you can easily configure a set of Envoy instances that are reasonably distributed in a performant way across many north-south and east-west use cases.

Kgateway is generally available with its 2.0 release.

Kong Kubernetes Ingress Controller¶

Kong is an open source API Gateway built for hybrid and multi-cloud environments.

TheKong Kubernetes Ingress Controller (KIC) can be used to configure unmanaged Gateways. See theGateway API Guide for usage information.. See theGateway API Guide for usage information.

For help and support with Kong Kubernetes Ingress Controller please feel free tocreate an issue or adiscussion. You can also ask for help in the#kong channel on Kubernetes slack.

Kong Gateway Operator¶

Kong is an open source API Gateway built for hybrid and multi-cloud environments.

TheKong Gateway operator (KGO) can be used to configure managed Gateways and orchestrate instances ofKong Kubernetes Ingress Controllers.

For help and support with Kong Gateway operator please feel free tocreate an issue or adiscussion. You can also ask for help in the#kong channel on Kubernetes slack.

Kubvernor¶

Kubvernor is an open-source, highly experimental implementation of API controller in Rust programming language. Currently, Kubvernor supports Envoy Proxy. The project aims to be as generic as possible so Kubvernor can be used to manage/deploy different gateways (Envoy, Nginx, HAProxy, etc.).

Kuma¶

Kuma is an open source service mesh.

Kuma implements the Gateway API specification for the Kuma built-in, Envoy-based Gateway with a beta stability guarantee. Check theGateway API Documentation for information on how to set up a Kuma built-in gateway using the Gateway API.

Kuma 2.3 and later support theGAMMA initiative'sGateway APIsupport for east-west traffic management within the mesh.

Linkerd¶

Linkerd is the first CNCF graduatedservice mesh.It is the only major mesh not based on Envoy, instead relying on apurpose-built Rust micro-proxy to bring security, observability, andreliability to Kubernetes, without the complexity.

Linkerd 2.14 and later support theGAMMA initiative'sGateway APIsupport for east-west traffic management within the mesh.

LiteSpeed Ingress Controller¶

TheLiteSpeed Ingress Controller uses the LiteSpeed WebADC controller to operate as an Ingress Controller and Load Balancer to manage your traffic on your Kubernetes cluster. It implements the full core Gateway API including Gateway, GatewayClass, HTTPRoute and ReferenceGrant and the Gateway functions of cert-manager. Gateway is fully integrated into the LiteSpeed Ingress Controller.

• Product documentation.
• Gateway specific documentation.
• Full support is available on theLiteSpeed support web site.

LoxiLB¶

kube-loxilb isLoxiLB's implementation of Gateway API and kubernetes service load-balancer spec which includes support for load-balancer class, advanced IPAM (shared or exclusive) etc. kube-loxilb manages Gateway API resources withLoxiLB as L4 service LB andloxilb-ingress for Ingress(L7) resources.

Follow thequickstart guide to get LoxiLB running with Gateway API in a few simple steps.

NGINX Gateway Fabric¶

NGINX Gateway Fabric is an open-source project that provides an implementation of the Gateway API usingNGINX as the data plane. The goal of this project is to implement the core Gateway API to configure an HTTP or TCP/UDP load balancer, reverse-proxy, or API gateway for applications running on Kubernetes. You can find the comprehensive NGINX Gateway Fabric user documentation on theNGINX Documentation website.

For a list of supported Gateway API resources and features, see theGateway API Compatibility doc.

If you have any suggestions or experience issues with NGINX Gateway Fabric, pleasecreate an issue or adiscussion on GitHub. You can also ask for help in theNGINX Community Forum.

ngrok Kubernetes Operator¶

ngrok Kubernetes Operator After adding preliminary support last year, thengrok Kubernetes Operator supports the entire core Gateway API. This includes:

• Routes (HTTPRoute, TCPRoute, TLSRoute) + RouteMatches (Header, Path, +more)
• Filters: Header, Redirect, Rewrite + more
• Backends: Backend Filters + Weighted balancing
• ReferenceGrant: RBAC for multi-tenant clusters handling
• Traffic Policy as an extensionRef or annotation when the Gateway API isn’t flexible enough

You can read ourdocs for more information. If you have any feature requests or bug reports, pleasecreate an issue. You can also reach out for help onSlack

STUNner¶

STUNner is an open source cloud-native WebRTC media gateway for Kubernetes. STUNner is purposed specifically to facilitate the seamless ingestion of WebRTC media streams into a Kubernetes cluster, with simplified NAT traversal and dynamic media routing. Meanwhile, STUNner provides improved security and monitoring for large-scale real-time communications services. The STUNner dataplane exposes a standards compliant TURN service to WebRTC clients, while the control plane supports a subset of the Gateway API.

STUNner currently supports versionv1alpha2 of the Gateway API specification. Check theinstall guide for information on how to deploy and use STUNner for WebRTC media ingestion. Please direct all questions, comments and bug-reports related to STUNner to theSTUNner project.

Traefik Proxy¶

Traefik Proxy is an open source cloud-native application proxy.

Traefik Proxy currently supports versionv1.4.0 of the Gateway API specification, check theKubernetes Gateway Provider Documentation for more information on how to deploy and use it.Traefik Proxy's implementation passes all HTTP core and some extended conformance tests, like GRPCRoute, but also supports TCPRoute and TLSRoute features from the Experimental channel.

For help and support with Traefik Proxy,create an issue or ask for help in theTraefik Labs Community Forum.

Tyk¶

Tyk Gateway is a cloud-native, open source, API Gateway.

TheTyk.io team is working towards an implementation of the Gateway API. You can track progress of this projecthere.

WSO2 APK¶

WSO2 APK is a purpose-built API management solution tailored for Kubernetes environments, delivering seamless integration, flexibility, and scalability to organizations in managing their APIs.

WSO2 APK implements the Gateway API, encompassing Gateway and HTTPRoute functionalities. Additionally, it provides support for rate limiting, authentication/authorization, and analytics/observability through the use of Custom Resources (CRs).

For up-to-date information on the supported version and features of the Gateway API, please refer to theAPK Gateway documentation. If you have any questions or would like to contribute, feel free to createissues or pull requests. Join ourDiscord channel to connect with us and engage in discussions.

Integrations¶

In this section you will find specific links to blog posts, documentation and other Gateway API references for specific integrations.

Flagger¶

Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes.

Flagger can be used to automate canary deployments and A/B testing using Gateway API. It supports both thev1alpha2 andv1beta1 spec of Gateway API. You can refer tothis tutorial to use Flagger with any implementation of Gateway API.

cert-manager¶

cert-manager is a tool to automate certificate management in cloud native environments.

cert-manager can generate TLS certificates for Gateway resources. This is configured by adding annotations to a Gateway. It currently supports thev1 spec of Gateway API. You can refer to thecert-manager docs to try it out.

Argo rollouts¶

Argo Rollouts is a progressive delivery controller for Kubernetes. It supports several advanced deployment methods such as blue/green and canaries. Argo Rollouts supports the Gateway API viaa plugin.

Knative¶

Knative is a serverless platform built on Kubernetes. Knative Serving provides a simple API for running stateless containers with automatic management of URLs, traffic splitting between revisions, request-based autoscaling (including scale to zero), and automatic TLS provisioning. Knative Serving supports multiple HTTP routers through a plugin architecture, including agateway API plugin which is currently in alpha as not all Knative features are supported.

Kuadrant¶

Kuadrant is an open source multi cluster Gateway API controller that integrates with and provides policies via policy attachment to other Gateway API providers.

Kuadrant supports Gateway API for defining gateways centrally and attaching policies such as DNS, TLS, Auth and Rate Limiting that apply to all of your Gateways.

Kuadrant works with both Istio and Envoy Gateway as underlying Gateway API providers, with plans to work with other gateway providers in future.

For help and support with Kuadrant's implementation please feel free tocreate an issue or ask for help in the#kuadrant channel on Kubernetes slack.

OpenKruise Rollouts¶

OpenKruise Rollouts is a plugin-n-play progressive delivery controller for Kubernetes. It supports several advanced deployment methods such as blue/green and canaries. OpenKruise Rollouts has built-in support for the Gateway API.

Adding new entries¶

Implementations are free to make a PR to add their entry to this page; however,in order to meet the requirements for being Partially Conformant or Conformant,the implementation must have had a conformance report submission PR merged.

Part of the review process for new additions to this page is that a maintainerwill check the conformance level and verify the state.

Page Review Policy¶

This page is intended to showcase actively developed and conformant implementationsof Gateway API, and so is subject to regular reviews.

These reviews are performed at least one month after every Gateway API release(starting with the Gateway API v1.3 release).

As part of the review, a maintainer will check:

• which implementations areConformant - as defined above in this document.
• which implementations arePartially Conformant, as defined above in this document.

If the maintainer performing the review finds that there are implementationsthat no longer satisfy the criteria for Partially Conformant or Conformant, orfinds implementations that are in the "Stale" state, then that maintainer will:

• Inform the other maintainers and get their agreement on the list of stale andto-be-removed implementations
• Open a draft PR with the changes to this page.
• Post on the #sig-network-gateway-api channel informing the maintainers ofimplementations that are no longer at least partially conformant should contactthe Gateway API maintainers to discuss the implementation's status. This periodis called the "right-of-reply" period, is at least two weeks long, and functionsas a lazy consensus period.
• Any implementations that do not respond within the right-of-reply period will bedowngraded in status, either by being moved to "Stale", or being removedfrom this page if they are already "Stale".

Page review timeline, starting with the v1.4 Page Review:

• Gateway API v1.4 release Page Review (at least one month after the actual release): a maintainer will move anyone who hasn't submitted a conformance report using the rules above to "Stale". They will also contact anyone who moves to Stale to inform them about this rule change.You are here
• Gateway API v1.5 release Page Review (at least one month after the actual release): A maintainer will perform the Page Review process again, removing any implementations that are still Stale (after a right-of-reply period).
• Gateway API v1.6 release Page Review (at least one month after the actual release): We will remove the Stale category, and implementation maintainers will need to be at least partially conformant on each review, or during the right-of-reply period, or be removed from the implementations page.

This means that, after the Gateway API v1.6 release, implementations cannot beadded to this page unless they have submitted at least a Partially Conformantconformance report.