Rate Limits, Credits & Atomic Billing

Rate Limits & Concurrency Thresholds

To protect platform infrastructure and maintain consistent sub-150ms latency across all tenants, rate limits are enforced on a per-endpoint basis using in-memory token bucket tracking.

Handling 429 Responses with Exponential Backoff & Jitter

When rate limits are exceeded, RSFlowHub returns an HTTP 429 status with a Retry-After response header indicating the mandatory wait time in seconds. In high-throughput distributed architectures, retries must include randomized jitter to prevent the "thundering herd" problem:

import time
import random
import requests

def call_rsflowhub_with_retry(url, headers, payload, max_retries=4, base_delay=1.0, max_delay=16.0):
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json=payload, timeout=5.0)
        
        if response.status_code != 429:
            return response
            
        # Inspect Retry-After header or calculate exponential backoff with full jitter
        retry_after = response.headers.get("Retry-After")
        if retry_after and retry_after.isdigit():
            sleep_duration = float(retry_after)
        else:
            # Full jitter formula: random.uniform(0, min(max_delay, base_delay * 2 ** attempt))
            sleep_duration = random.uniform(0, min(max_delay, base_delay * (2 ** attempt)))
            
        time.sleep(sleep_duration)
        
    raise Exception("Max retries exceeded for RSFlowHub API")

Atomic Credit Pre-Authorization & Billing Flow

RSFlowHub uses an atomic 3-Phase Pre-Authorization Lock lifecycle to guarantee that developers are charged only for valid computations down to the exact token count:

Processing Cost Calculation

Because heavier natural language processing requires increased compute power, an incremental Processing Cost is added based on input character volume:

Endpoint Base Credits Reference