Rnote API Rnote API
Back to Blog

Managing API Keys: Per-Environment Split, Rate Limits and Usage Checks

Rnote API Team · · 4 views · 中文
Xiaohongshu Data API Keys Rate Limits Best Practices

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 on 402 separately 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

  1. 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.
  2. 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.
  3. 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.

Back to Blog