Account & Credits

Your per-minute rate limit is tier-based and changes with your credit balance. As you spend credits and move between tiers, limit_per_minute moves with you. These endpoints let your code read the live value instead of hardcoding it — ideal for keeping a client-side rate limiter in sync and avoiding rate-limit errors.

The three endpoints

Authentication

All account endpoints authenticate with X-AUTHAPI-Key header — the same key you use for data requests, available in Workspace → API Keys. No browser session or cookie is needed.

X-AUTHAPI-Key: your_api_key_here

Base URL: https://renidly.com/api/panel

Tier Info

Returns everything about your account's position in the credit tier system: your current tier and its limit_per_minute, your live balance, and the tiers immediately above and below you. Call this when you need to know your rate limit at runtime.

Request

curl https://renidly.com/api/panel/credits/tier/k/ \
  -H "X-AUTHAPI-Key: $RENIDLY_API_KEY"

Response

{
  "success": true,
  "message": "Tier info retrieved",
  "errors": null,
  "data": {
    "balance": 0.0,
    "credits_per_dollar": 100,
    "current_tier": {
      "name": "Testing",
      "min_credits": 0,
      "max_credits": 99,
      "limit_per_minute": 7
    },
    "next_tier": {
      "name": "Hobby",
      "min_credits": 100,
      "max_credits": 9999,
      "limit_per_minute": 30,
      "credits_needed": 100.0
    },
    "previous_tier": null
  }
}

Response fields

Balance

A lightweight endpoint that returns only your current credit balance. Use it when you just need the number — low-balance alerts, billing dashboards, deciding whether to top up — without the full tier payload.

Request

curl https://renidly.com/api/panel/credits/balance/k/ \
  -H "X-AUTHAPI-Key: $RENIDLY_API_KEY"

Response

{
  "success": true,
  "message": "Balance retrieved",
  "errors": null,
  "data": {
    "balance": 0.0
  }
}

Enterprise Balance

Returns the credit balance for an Enterprise workspace. This route is authenticated with your Enterprise API key — a Personal-tier key returns Invalid API key on this route.

Request

curl https://renidly.com/api/panel/credits/balance/k/enterprise/ \
  -H "X-AUTHAPI-Key: $RENIDLY_ENTERPRISE_KEY"

Response

{
  "success": true,
  "message": "Balance retrieved",
  "errors": null,
  "data": {
    "balance": 798676.0
  }
}

Credits on every response

You do not have to poll the balance endpoint after each call. Every billable request to the data, live, and email APIs returns two response headers that report what the call cost and what you have left:

Read them together: X-Credits-Consumed is the price of the call you just made, and X-Credits-Balance is your balance after that amount was taken off. The balance before the call was simply the sum of the two.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Credits-Consumed: 1
X-Credits-Balance: 463499

Use case: a self-tuning rate limiter

The most common reason to call these endpoints is to drive a client-side rate limiter from a horizontally-scaled service. Because limit_per_minute is tier-based, it shifts as your balance crosses tier boundaries — a hardcoded value in your config will drift out of sync, leaving you either over-throttling (wasting throughput) or hitting rate-limit errors and failing jobs.

Instead, read the live limit from /credits/tier/k/ and refresh it periodically. Your limiter then always matches your real allowance:

import time, threading, requests

API_KEY = "your_api_key_here"
BASE    = "https://renidly.com/api/panel"
HEADERS = {"X-AUTHAPI-Key": API_KEY}

_limit = {"per_minute": 7}  # safe default until first refresh

def refresh_rate_limit():
    """Pull the live per-minute limit for the current tier."""
    r = requests.get(f"{BASE}/credits/tier/k/", headers=HEADERS, timeout=10)
    data = r.json()["data"]
    _limit["per_minute"] = data["current_tier"]["limit_per_minute"]
    return _limit["per_minute"]

# Refresh on startup, then every few minutes so the limiter
# tracks tier changes as credits are consumed or topped up.
def keep_in_sync(interval=300):
    while True:
        try:
            refresh_rate_limit()
        except Exception:
            pass  # keep the last known value on transient errors
        time.sleep(interval)

refresh_rate_limit()
threading.Thread(target=keep_in_sync, daemon=True).start()

# ... your limiter reads _limit["per_minute"] when allocating tokens

Best practices

• Cache, don't poll per request. Read the limit once on startup and refresh on an interval (every 1–5 minutes is plenty). The tier only changes when your balance crosses a boundary.
• Refresh on a rate-limit hit. If you do hit a rate-limit error, immediately re-read /credits/tier/k/ — your tier likely dropped — then back off and resume at the new limit.
• Keep a safe default. Seed your limiter with a conservative value so a failed refresh never lets it run unbounded.
• Watch next_tier.credits_needed. Surface it in your monitoring to know exactly how many credits separate you from a higher limit, and to fire low-balance alerts before jobs start failing.
• Stay just under the limit. Target ~90% of limit_per_minute to absorb clock skew across horizontally-scaled instances.