Renidlyrenidly
Guides

Production Checklist

4 min read

Twelve items to verify before pointing real traffic at Renidly. Each one represents an outage, surprise bill, or compromised credential we’ve seen at least once.

Secrets

  1. Production key lives in a secret manager. The RENIDLY_API_KEY for production is in 1Password, Vault, AWS Secrets Manager, Doppler, or your platform's equivalent — never in source code or a .env file checked into git.
  2. Separate keys per environment. Dev, staging, and production each have their own key. A leak in one environment doesn't take down another.
  3. Secret scanner on the repo. GitHub secret scanning, trufflehog, or gitleaks is wired into CI. The Renidly key prefix (rnd_live_, rnd_ent_) is in your custom-pattern list.

Request handling

  1. Branch on success, not statusCode. Your fetch wrapper checks body.success and throws a typed error when it's false. The whole codebase consumes data safely.
  2. Retries are exponential and capped. Retries fire only on network failures and rate-limit signals — never on validation or auth failures. Backoff grows exponentially with jitter, and you cap at 5 attempts. See Errors & Retries.
  3. Idempotency keys on writes. Every write request includes an Idempotency-Key header (UUID v4 is fine), so retries after a network timeout don't double-charge.
  4. Timeout shorter than the upstream. Your client timeout is 15 seconds or less. Long-tail live calls finish in under 10s; anything longer means the call is stuck and should be retried.

Cost and throughput

  1. Inputs deduplicated and normalised. Coalesce identical pending requests on your side, and lowercase / trim / consistently order params before calling. Renidly's 20-minute cache is keyed byte-for-byte — normalising inputs converts what would be paid live calls into free cache hits. See Data Freshness.
  2. Client-side cache for > 20-minute tolerance. Renidly already caches every call for 20 minutes. If your staleness tolerance is longer than that (daily backfills, weekly syncs), add a second layer on your side keyed on the canonical identifier returned in data — 24h TTL for people, 7d for organizations.
  3. Concurrency capped to your live tier limit. Your worker pool reads current_tier.limit_per_minute from /api/panel/credits/tier/k/ at startup and on a 1–5 minute interval — never hardcoded — and targets ~90% of it. See Rate Limits.

Observability

  1. requestId logged on every error. Your logs include the id. Support tickets become traceable in seconds.
  2. Credit balance monitored. An alert fires when workspace credits fall below your two-week burn rate. A scheduled job reads data.balance from /api/panel/credits/balance/k/ and pipes it into your metrics.
  3. Health probe in place. A scheduled job hits /api/panel/credits/tier/k/ every 5 minutes. Two consecutive failures (network error or success: false) page on-call.

Before you cut over

Run a 24-hour shadow window — fire each production request at Renidly in parallel with whatever you're replacing, log the difference, and only flip the read path once the diff is under your tolerance. That single discipline catches more incidents than any other in this checklist.

← Previous
Which endpoint to use