Managing API Keys: Per-Environment Split, Rate Limits and Usage Checks
Running every environment off a single API key is the most common — and most expensive — habit teams pick up after integrating. One runaway test script eats the production quota and rate limit at the same time, and when something breaks, the logs can't tell you which caller did it.
Here's how to split keys in the Rnote API dashboard, and how the rate limit actually works.
One key per environment
API Key management lets you create multiple keys, each independently named, rate-limited and revocable. A sensible minimum split:
prod— production services, full rate limit.staging— pre-release, half the limit.dev-<name>— one per developer, lowest limit.
The value shows up on the bad day: if a key leaks or gets misused, you disable that one key and every other environment keeps running — no config change across all your services. Your logs also tell you immediately which path sent the request.
The rate limit is per key
Each key has its own per-minute ceiling and they do not interfere with each other — that's the point of splitting them. Over the limit, the API returns 429 and nothing is billed.
The right way to handle 429 is exponential backoff, not an immediate retry:
import time, requests
def call(url, params, tries=5):
headers = {"X-API-Key": "YOUR_API_KEY"}
delay = 1.0
for i in range(tries):
r = requests.get(url, headers=headers, params=params, timeout=30)
if r.status_code != 429:
return r
time.sleep(delay)
delay *= 2 # 1s -> 2s -> 4s -> 8s
raise RuntimeError("still limited; check concurrency against this key's quota")
Fixed-interval retries stack every worker onto the same instant under concurrency. Backoff spreads them out.
Checking balance and usage
- Insufficient balance returns
402. The request is not executed and nothing is charged. Alert on402separately in production — it is not a code problem, it's a money problem, and retrying will never fix it. - The billing page breaks spend down by date and by endpoint, so you can see which endpoint costs the most, and export it for reconciliation.
Three habits that save money
- Failures aren't billed, but that's not a licence to hammer — validate parameters before the call instead of letting obviously bad requests hit the API.
- Batch instead of looping one by one — one search call that returns a page of notes is far cheaper than fetching each note's detail.
- Give dev its own low-limit key — a rate limit is a fuse. Much better than reading it off the invoice afterwards.
Get started
Sign up free and create your keys in the dashboard. Endpoints are in the docs, prices on the pricing page. For the full integration checklist, see RedNote API best practices.
Related articles
- RedNote API Best Practices: Rate Limits, Retries, Pagination & Dedup Engineering essentials for stable, scalable collection: concurrency throttling, exponential-backoff retries, per-endpoint cursor pagination, dedup by ID, and pay-only-for-success cost control — with a Python skeleton.
- Pugongying Content Square and Keyword Analytics: Decide What to Say Before Who Says It Content Square for category-level distribution, keyword/daily to bet on rising rather than high, related for long-tail expansion, and why the live pool is a different pool.
- Usage Doesn't Add Up? Split Billing by Date and by Endpoint Locate the anomalous day, find the expensive call pattern, export and reconcile against your own logs — plus three ten-minute checks that nearly always find something.
- Build a RedNote Competitor Dashboard from Scratch: One Table, One Cron Job Questions before fields; a three-layer collect/store/present design; snapshots instead of current values; three metrics that earn their place; and what 50 calls a day costs.
About the Rnote Xiaohongshu API
Skip building a RedNote scraper: one API key gets you notes, comments, users, search, products and Pugongying creator data. Pay per call, charged only for successful requests.