Rate limits.

01The three axes

Hypedata applies three separate ceilings. Hitting any one returns 429.

1. Requests per second (RPS). Token-bucket with a 1-second window. Bursting 10% above your plan is tolerated; sustained over-rate is throttled.
2. Concurrent connections. Counts open Stream sessions, in-flight Scrape calls, and active batch jobs together.
3. Credits per day. Soft ceiling on free / Pro plans, hard ceiling on metered Pay-as-you-go.

02Limits by plan

Limits are workspace-wide, not per-key. If you've split a workspace across services and one runs hot, every other service shares the consequences — split workspaces for hard isolation.

03Response headers

Every response (including non-429) includes:

RateLimit-Limit:     50
RateLimit-Remaining: 38
RateLimit-Reset:     1
RateLimit-Policy:    50;w=1
X-Hd-Concurrent-Used: 7
X-Hd-Concurrent-Cap:  32
X-Hd-Daily-Used:      284912
X-Hd-Daily-Cap:       500000

Use RateLimit-Remaining as a real-time backpressure signal. SDKs use the X-Hd-Concurrent-* headers to keep your in-flight count just below the cap.

04The 429 response

HTTP/1.1 429 Too Many Requests
Retry-After: 2
RateLimit-Reset: 2
Content-Type: application/json

{
  "status": "error",
  "code": "rate_limited",
  "message": "50 req/s cap hit. Slow down or upgrade.",
  "retryable": true,
  "retry_after_s": 2
}

Always honor Retry-After. Hammering through a 429 will get you trimmed (see below), which is much worse.

05Fair-use trimming

On top of plan limits, Hypedata applies per-target fair-use: if your workspace is generating more traffic to a single hostname than is polite, we trim concurrency on that hostname while letting your other targets flow at full speed. This is what keeps Hypedata's relationship with the open web sustainable — and keeps you out of permanent blocks.

Triggers:

• More than 5,000 requests per minute to one hostname.
• Sustained 503 / 429 rates from the target above 20%.
• Explicit slow-down signals (e.g. Retry-After: 60 from upstream).

When trimming kicks in you'll receive fair_use_trim errors with a generous retry_after_s. Don't fight it — back off, or contact us to discuss licensed access or a custom rate envelope.

06Client patterns

Token-bucket on the client

Mirror our token bucket on your side. The SDKs do this internally if you don't.

// Node — naive but works
const bucket = { tokens: 50, refillPerSec: 50, last: Date.now() };
async function throttle() {
  while (true) {
    const now = Date.now();
    bucket.tokens = Math.min(50, bucket.tokens + (now - bucket.last)/1000 * bucket.refillPerSec);
    bucket.last = now;
    if (bucket.tokens >= 1) { bucket.tokens -= 1; return; }
    await new Promise(r => setTimeout(r, 50));
  }
}

Exponential backoff with jitter

On 429 / 5xx, wait min(retry_after_s, base * 2^attempt) + jitter with base=200ms and full jitter. SDKs do this; if rolling your own, see Retries.

Concurrency limiter

Pair RPS limiting with a fixed-pool concurrency limiter (e.g. p-limit in Node, asyncio.Semaphore in Python). Stay just below X-Hd-Concurrent-Cap.

07Custom limits

Enterprise customers get bespoke per-axis limits and dedicated capacity. We can also configure:

• Reserved concurrency that's never shared with the public pool.
• Dedicated regional egress (your own /24 of proxy IPs).
• Burst windows aligned with your business schedule (e.g. 6× overnight).
• Soft-fail mode (degraded service instead of 429 during cap-hit windows).

Email sales@hypelabs.llc with rough throughput estimates and we'll size a plan.