shadcn.io is not affiliated with official shadcn/ui
Tiered API Pricing Block for Vue
API tiers by request quota, with the quota as the headline: four columns open with 10k, 250k, 2M and 10M+ requests a month at display size, then the price, the overage rate and a call to action, over grouped limits and features.
Installation
Overview
Sell an API by its quota with this tiered API pricing section. A compact header, a heading and one sentence, sits under the page's top rule and side rails, drawn by Guides. Below it, one table framed between hairlines with a + mark on each corner, and a hairline between every column, lines up Free, Developer, Business and Enterprise. Each column opens with its monthly request quota at display size, 10k, 250k, 2M and 10M+, the first thing you read, then its price, what a request past the quota costs and a Shine Button call to action. Thirteen rows follow in three groups, Limits, APIs and Data and support, with a check for what a tier includes, a dash for what it lacks and the limit where there is one. The Developer column carries a soft tint, a Most popular outline Badge and the only filled button, so the theme's colour marks one action. On a phone the table becomes plan tabs over one tier at a time: its quota, price and button first, then its rows beside their names, so nothing scrolls sideways. Built with Table, Segment Group, Badge, Shine Button, Guides and Lucide icons, with CSS transitions only. For maps, search and other API products, developer platforms and any usage-based pricing with a quota per tier.
FAQ
How do I change the tiers, quotas and feature rows?
Edit the arrays at the top of the file. PLANS holds each column's name, monthly price (null shows Custom), the quota as written ("250k") with quotaSpoken for screen readers ("250,000"), the overage line, the call to action's cta, and popular. GROUPS holds the categories, each with its features: a feature has a name and a value per plan id, true for a check, false for a dash, or text for a limit such as "100 × 100". The plan ids are a TypeScript union, so adding a plan flags every feature that still needs a value for it.
What do the quota and overage lines mean, and how do I bill them?
The big figure is the requests included in the monthly price, and the line under the price says what happens past it: a hard stop on Free, a price per thousand extra requests on the paid tiers, a quote on Enterprise. They're plain text, so write them in your own units (tiles, tokens, minutes, events). The billing itself happens in your payment provider: a metered price, reported from your API gateway, charges the overage at the rate you show here.
How do I connect the calls to action?
Each call to action is a real link. Point Free at your key signup, the paid tiers at checkout with the plan in the URL (/checkout?plan=developer), and Enterprise at your sales form. Set popular: true on another plan to move the tint, the badge and the filled button.
How does the table work on a phone?
Below the md breakpoint the table gives way to a second view of the same data: a Segment Group of the four plan names, with Developer selected, over the chosen tier's quota, price and button, then its rows as names and values. Nothing scrolls sideways, even at 320 px, and the quota stays the largest thing on screen.
Is the table accessible to screen readers?
Plan names are column headers, feature names are row headers and each group's heading heads the rows under it, so a cell reads as "Developer, Isochrones, Not included": every check and dash carries hidden text. The big quota is read in words ("250,000 requests"), prices with their period ("$49 per month"), and the buttons say which plan they're for.
When should I use a tiered table instead of plan cards?
Use the table for four or more tiers that differ on many technical limits, where developers compare row by row: rate limits, endpoints, support. The display-size quotas make the main difference obvious before anyone reads a row. When your tiers differ on a handful of features and the decision is quick, plan cards such as Three Columns Pricing read faster, and for pure pay-per-use without tiers a rate table fits better.