In this blog post, we'll talk about how to implement API product tiering, a powerful way to customize access, control usage, and monetize APIs. This model can help you scale efficiently while maintaining a smooth user experience. Read on to learn more!
We'll be talking about how to implement API product tiering with Kong Konnect, an API lifecycle management platform designed from the ground up for the cloud-native era and delivered as a service. This platform lets you build modern applications better, faster, and more securely. The management plane is hosted in the cloud by Kong, while you can choose to either host the data plane yourself in your preferred network environments or let Kong manage it for you in the cloud.
Want to check out Kong Konnect? Click [here](https://cloud.konghq.com/register)here to register for free.
API product tiering, what is it? And how can Kong Konnect help you achieve it? API product tiering is a way of offering different levels of access, features and usage limits for APIs based on a customer's subscription plan or payment level. This helps organizations monetize their APIs, control resource usage, and cater to a wide range of users with varying needs.
Let’s begin by defining some key concepts related to API product tiering:
**1. Different tiers for different Users:**
**2. Rate Limits:**
**3. Feature Access:**
**4. Authentication and authorization:**
**5. Monetization:**
**6. Support and service level:**
Product tiering can work across many industries such as AI, e-commerce, healthcare, telecommunications, travel and hospitality, and banking to name a few. To showcase how this works in Konnect, let's come up with a fictitious company called FinTech Corporation, a financial services company. To keep things simple, they offer three different API Products:
This setup allows FinTech to cater to different customer segments, from small app developers to large enterprises needing full access to real-time data and high transaction volumes.
Feeling efficient and want to test this out for yourself? Just push the deck configuration directly into Konnect, using [this Deck file](https://gist.github.com/DeclanPaulKeane/4de2a80bf4066d4d2ba1cc052dd7d0b2)this Deck file. Be careful not to override any current configuration.
$ deck gateway sync --konnect-token $KONNECT_TOKEN kong.yamlIf you aren't familiar with Deck, follow this [getting start guide](https://docs.konghq.com/deck/latest/guides/getting-started/)getting start guide. When authenticating with the control plane, you need to pass an access token. This link covers [how to](https://docs.konghq.com/deck/latest/guides/konnect/#authenticate-using-a-token)how to generate and use that token with Deck.
The first task is to define your APIs. Let’s expose and organize them into manageable products. To do this we will create routes and services in Konnect to correspond to your specific API endpoints.
Since this is just an example, I’m going to use a simple mocking service hosted by Kong, [https://httpbin.konghq.com](https://httpbin.konghq.com)https://httpbin.konghq.com. We'll create the following services for our Market Data, Account Information, and Payment Processing API:
Each service will have a corresponding route to expose the APIs:
To secure the APIs, we can require authentication on the different APIs through the various authentication methods supported by Kong Gateway, including basic authentication, JWT, OpenID Connect, LDAP, and [more](https://docs.konghq.com/hub/?category=authentication)more.
To keep things simple let’s enable key authentication for all APIs. Once enabled, you need to provide a key to get access to these endpoints. I've set it globally, but it could be also scoped per service or route:
To represent the end users or applications that will access these products, we'll create consumers and provision a key authentication credential to get access to each product. I’ve labeled the users with their tiers so we can keep track of them. Adam is in the free tier, Ben is in the basic tier, and Charlie is in the premium tier. I've also created a secure credential for each consumer:
A useful component of Konnect is Consumer groups. Consumer groups provide the ability to organize consumers within an API ecosystem. By grouping consumers, you eliminate the need to manage them individually, providing a scalable, efficient approach to managing configurations. We can also scope policies (plugins in the Konnect world) to Consumer Groups. To achieve our use case, we will create three different Consumer groups, free, basic, and premium. These will represent the different tiers we outlined in the previous section.
We will also add the Consumers we created in the previous step to their corresponding Consumer Group/Tier:
In a real-world scenario, you can have many consumers be part of a consumer group.
Fintech Corporation has decided to limit access to specific products based on the tier they are in. We can leverage Konnects built-in ACL plugin with Consumer Groups to limit access based on each tier.
Important Note: when configuring the ACL plugin there is a checkbox that enables the ACL plugin for Consumer Groups, it’s called “Include Consumer Groups.” Make sure this is enabled.
The market data product will allow access to all tiers/consumer groups:
The accounts product will only allow access to basic and premium:
Payments just allow access for premium consumers:
You now have three ACL plugins configured, one to each gateway service restricting access based on the consumer group the consumer or application is part of. The consumer group name in the “Allow” field is case-sensitive.
Not only can we apply rate limits based on which product, but we can also scope it to a specific tier in Kong Konnect. This will allow us to implement rate limiting and access restrictions to enforce the boundaries of each tier.
We will leverage Konnect's advanced rate-limiting plugin to achieve this. When applying the configuration for each rate limit we need to do three things:
For the Rate limit Advanced plugin configuration, the applied configuration will look something like this:
For example, this is what it would look like for the rate limit advanced plugin applied to the free tier market data product:
Once you’ve scoped the specific rate limits per minute for each consumer group on the three different gateway services we have, it should look like this:
And that’s it, we should have now successfully set up our different tiers with the correct request limits for each tier.
Let's verify the tiering model we’ve implemented works as expected. I’m going to use my favorite design, testing, and debug tool for APIs called [Insomnia](https://insomnia.rest/)Insomnia. Let’s access the APIs with Adam, who’s part of the free tier and therefore only has access to market data API. As we can see, Adam has access but as can be seen in the header information, he’s being limited to 100 requests per minute:
If Adam tries to access a product that he does not have access to like the accounts or payments product, he will get denied with a 403 error.
Let’s now test with Ben by accessing the account's products and we can see that the limit is much higher at 500 requests per minute:
API product tiering offers a powerful way to customize access, control usage, and monetize your APIs while catering to a wide range of users. Whether you’re offering limited access to developers just getting started or premium features, this model helps you scale efficiently while maintaining a smooth user experience.
Kong Konnect simplifies this process by providing a robust API lifecycle management platform that integrates essential features like authentication, rate limiting, consumers management, and analytics.
Companies like our fictitious FinTech Corporation can deliver tailored solutions, maximize value for users, and unlock new revenue streams. Whether your business is in financial services, e-commerce, healthcare, or any other sector, leveraging API management with Kong Konnect is a step toward building smarter, more scalable, and user-friendly applications.
The Shifting Economic Landscape: The AI token economy in 2026 is evolving, and enterprise leaders must distinguish between low-cost input tokens and high-premium output tokens to maintain profitability. Agentic AI Financial Risks: The transition t
[](https://konghq.com/blog/enterprise/ai-input-vs-output-cost-management)
Many companies start with a single payment provider like Stripe because it’s fast and reliable for self-service subscriptions. However, as OpenAI discovered, as your business needs to support a range of freemium accounts, self-service pro plans, and
[](https://konghq.com/blog/enterprise/multi-rail-billing-payment-provider-lockin)
Local-first: your data stays with you: Insomnia stores everything on your machine by default. No forced cloud sync, no account needed just to send a request. This is helpful if privacy or working in a regulated environment is a priority for you Fre
[](https://konghq.com/blog/engineering/migrating-collections-and-requests-from-postman-to-insomnia)
Traditional agreement processes were slow and heavily manual. Documents were often created in office tools, shared through email, printed, signed physically, and stored across multiple systems. Tracking the status of agreements required manual follo
[](https://konghq.com/blog/engineering/automating-agreement-workflows-kong-konnect-and-docusign-for-developers)
A Response to Gartner’s Latest Research We have crossed a threshold in the AI economy where the competitive advantage is no longer about access to data — it’s about access to context. The "context economy" has arrived, defined by a fundamental
[](https://konghq.com/blog/enterprise/the-platform-enterprises-need-to-compete)
Architecture Overview A multicloud DCGW architecture typically contains three main layers. 1\. Konnect Control Plane The SaaS control plane manages configuration, plugins, and policies. All gateways connect securely to this layer. 2\. Dedicated C
[](https://konghq.com/blog/engineering/dedicated-cloud-gateways-managed-redis-multi-cloud)
Tool discovery for AI agents In early agent implementations, tools are often statically configured inside the agent. For example: { "mcpServers": { "weatherServer": { "command": "uv", "args": "run", "weather_serv
[](https://konghq.com/blog/engineering/mcp-registry-dynamic-tool-discovery)