Tiered API Pricing Block for React

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.

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.

Each call to action is a real link. It's a ShineButton with render set to an a element and nativeButton={false}. 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.

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.

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.

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.