shadcn.io is not affiliated with official shadcn/ui
API Rate Limit Tiers Settings Block for React
A matrix of API limits with the plans across and a number field in every cell, a daily capacity worked out under each plan and a guard that stops a higher plan from allowing less than the plan before it.
Installation
Overview
Let people set what each plan may ask of an API, with this rate limit tiers panel for React with Base UI. Inside a hairline frame with a plus mark on each corner, a native table has the limits down (requests per minute, burst, concurrent requests and a monthly quota) and the plans across (Free, Pro and Scale), with a Number Input in every cell. Under each plan's name the table works out what its rate adds up to in a day ("About 1.44M requests a day"), and a plan can never allow less than the plan before it: a cell that does gets a problem line ("Below Free's 60."), the band's count says how many limits are still in order, and Apply names the first offender and moves focus to it instead of saving. The last band counts unsaved changes in a status line beside a Shine Button to apply them and an outline Button to discard them. On a phone the plans become Tabs, each showing one plan's four fields with the neighbouring plans' values as a hint, and the action foot stays pinned to the bottom of the screen. It's built from Number Input, Tabs, Button, Shine Button and Guides, with a CSS entrance only. For API products, usage-based plans and any settings page whose limits must rise with the tier.
FAQ
How do I fill it with my own plans and limits?
Edit the constants at the top. PLANS lists the columns in order, lowest first, since that order is what "a higher plan" means. LIMITS lists the rows: each has an id, a name, a one-sentence hint and the largest value its field accepts. SAVED holds what the account has stored when the page opens, one entry for each limit and plan, keyed as "limit:plan". The daily capacity under a plan is worked out from the row whose id is rpm, so keep that row or change capacityLine.
What does in order mean, and what does Apply do when it isn't?
In each row a plan's value must be at least the value of the plan before it; equal is fine. A cell below its neighbour gets a problem line that names the neighbour and its value, and the count in the band's heading ("3 of 4 in order") counts the rows with no such cell. Pressing Apply while any cell is out of order saves nothing: the status line names the first one ("Not applied: Pro is below requests per minute on the plan before it."), the matching tab opens on a phone, and focus goes to that field. Fix it and Apply works again.
How is the daily capacity worked out?
It is the requests-per-minute value times 1,440 minutes, written in compact notation with up to three significant digits, so 1,000 a minute reads "About 1.44M requests a day" and 60 reads "About 86.4K". It is the most a key could send at the sustained rate, not a forecast, and it follows every edit. The monthly quota is a separate cap and does not change it.
What stays local, and how do I wire it for real?
Everything. Apply keeps the edited limits as the saved ones in this page and says so; nothing is enforced and nothing is sent. To make it real, send the edited limits to your API in the apply handler, check the same ordering rule on the server, and replace the saved copy with what the server returns, showing a failure in the status line. Keep the monotonic check on both sides: a form can be bypassed.
How is the matrix labelled for a keyboard and a screen reader?
It is a native table with a caption, column headers for the plans and a row header for each limit, so a cell is announced with both. Every field also has its own name ("Burst, Pro"), and its problem line is tied to it as a description. Apply and Discard stay in place and focusable while there is nothing to do: they are marked aria-disabled, and pressing one says so in the status line.
How does it look on a phone?
The table would be cramped, so the plans become tabs: Free, Pro and Scale across the top, and the selected plan's four fields below with a hint under each name ("Pro allows 1,000.") that shows the neighbour's value without switching tabs. Problem lines keep their reserved room, so the panel doesn't move when one appears, and the action foot stays at the bottom of the screen while you scroll.
Related
- Pro
Rate Limiting Settings
API and webhooksA rate limit you can try: a framed strip replays one client's 24 requests over 10 seconds against the chosen algorithm, limit, window and burst, marking each request allowed or rejected and counting both.
- Pro
Usage Limits Settings
Product controlsA row for each resource with a usage bar, a limit field, a policy for what happens at the limit (default, block, throttle or bill extra) and a sentence that restates the outcome, plus a default every row can follow.
- Pro
Plan Comparison Settings Billing
Upgrade and downgradeEvery plan side by side inside app settings: a table with the account's own plan marked and tinted, one change button per plan, a row for when each change takes effect, and plan tabs on a phone.
- Pro
API Key Builder Settings
API and webhooksAn API key settings panel with a table of keys, a builder that sets None, Read or Write for each resource, and a try-a-request check that answers Allowed or Denied with the reason before anything is saved.
- Pro
CORS Allowed Origins Settings
API and webhooksA CORS settings panel that checks its own origin list for four unsafe patterns, each with a Fix button that rewrites the list, plus origin rows with an environment tag, a validating add form and a policy band for credentials and preflight cache.
- Pro
Developer Tools Settings
API and webhooksFour SDK switches and an environment choice beside a request panel they steer: capture lists six requests, choosing one opens its JSON, and debug, verbose errors and timing each add their own part to what it shows.