Frequently Asked Questions

Short answer: It depends on what you mean by "faster."

What EZThrottle makes faster:

• ✓ Eliminates retry waste: Without EZThrottle, a rate-limited request might retry 3-5 times (wasting 15-30 seconds). With EZThrottle, we only send when we know it'll succeed. Zero retries = zero wasted time.
• ✓ Increases effective throughput: Every 429 error counts against your rate limit quota — even though it failed. We eliminate those wasted attempts, so you get ~40% more successful requests from the same quota.
• ✓ Removes waiting from your code: Your app doesn't block doing exponential backoff anymore. Fire the request, move on, get webhook later.

What EZThrottle does NOT make faster:

• ✗ The actual API call time: If OpenAI takes 2 seconds to respond, it still takes 2 seconds. We don't make the API itself faster.
• ✗ Requests when you're under rate limits: If you're only sending 1 req/sec and the limit is 10 req/sec, you're not rate limited. EZThrottle adds ~100-200ms routing overhead. Don't use it if you're not hitting rate limits.

It depends on two things:

1. Queue depth when your request arrives

• • Empty queue → processed immediately (~100-200ms latency)
• • 100 requests ahead → you wait for those 100 to complete first

2. The API's rate limit

• • 10 req/sec limit → each request processes in ~100ms
• • 1 req/sec limit → each request takes ~1 second

Example scenarios:

Key insight: We don't make the API faster. We make the waiting predictable and your code simpler.

Probably not.

EZThrottle is designed for "eventually consistent" workflows where you can wait seconds, minutes, or even hours for results:

• • Batch processing jobs
• • Background data collection
• • Overnight research tasks
• • Content generation pipelines

If you need responses in <5 seconds (like user-facing API calls), EZThrottle probably isn't the right tool unless you're already severely rate limited and willing to make users wait.

No. Your API's rate limit stays exactly the same.

But we maximize efficiency of your existing quota:

We don't retry against rate limits.

Traditional approach (what you're probably doing now):

Request → 429 error (counts against quota)
Wait 1s...
Request → 429 error (counts against quota)
Wait 2s...
Request → 429 error (counts against quota)
Wait 4s...
Request → Success

Result: 4 attempts to get 1 successful request

EZThrottle approach:

Request → (we wait until we know it'll succeed)
Request → Success

Result: 1 attempt for 1 successful request

We coordinate the timing so you never hit 429s in the first place.

2 requests per second per domain — carefully chosen to be safe.

Why 2 req/sec?

• • Conservative enough to avoid angering APIs
• • Fast enough to be useful (7,200 req/hour)
• • Proven safe across hundreds of APIs

The distributed magic:

Rate limits are NOT user-configurable. Here's why:

• • Prevents accidental DDoS
• • Protects our IP reputation with APIs
• • Ensures fair usage across all tenants
• • We stay responsible stewards

Need a higher rate for a specific API?

Email us at support@ezthrottle.network with:

• 1. The API domain
• 2. Official documentation showing their rate limits
• 3. Why you need more than 2 req/sec

We maintain a curated config of known-safe rate limits. If your API can handle more, we'll add it to the global config and everyone benefits.

One request = one API call you send us.

You are NOT charged for:

• • Internal retries we do (if something fails on our end)
• • Webhook delivery attempts
• • Dashboard API calls to check status

You ARE charged for:

• • Every request you send us, even if it fails (429, 500, timeout, etc.)
• • Requests that sit in queue but never get processed (if you cancel them)

We'll email you at 80% and 100% of your quota.

When you hit 100%: Your requests continue processing, but you're charged overage fees.

Overage pricing:

• • Free tier: Requests stop at 10k (upgrade to continue)
• • Paid tiers: $0.0005 per request over quota (billed next month)

To avoid overages:

• 1. Upgrade tier instantly (prorated, takes effect immediately)
• 2. Use smart routing (SDK only sends 429s, not all requests)
• 3. Monitor your dashboard (we show real-time usage)

No.

You include your API keys in the request headers/body when you send requests to us. We forward them to the target API and then forget them.

We never:

• • Store API keys in a database
• • Log API keys
• • Cache API keys

Metadata only. Not the actual content.

We log:

• • Timestamp
• • Target URL (domain)
• • HTTP status code (200, 429, 500, etc.)
• • Duration
• • Request ID (for debugging)

We do NOT log:

• • Request body
• • Response body
• • Headers (except standard rate limit headers)
• • Query parameters

Request/response bodies are processed in-memory only and never persisted to disk or database.

Worst case scenario: Attacker sees metadata (which APIs you call, when, how often).

They CANNOT see:

• • Your API keys (not stored)
• • Request/response content (not stored)
• • Sensitive data you're sending (not stored)

We're built this way intentionally. Zero persistent storage of sensitive data = minimal breach impact.

Not yet.

As a solo founder, I can't realistically claim SOC2 compliance right now. That requires:

• • $20k-50k in auditing costs
• • Months of preparation
• • Multiple employees for separation of duties

GDPR: We're better positioned here since we don't store personal data. Metadata is minimal and can be deleted on request.

Timeline: If EZThrottle grows, compliance is planned for 2026. Enterprise customers can request architecture review: support@ezthrottle.network

Smart routing: We only handle overflow, not your entire ocean.

The SDK doesn't blindly proxy all your requests through EZThrottle. That would be stupid and expensive.

What actually happens:

You can also force-route everything:

client.request(
    url="...",
    force_route=True  # Always go through EZThrottle
)

But why would you? You'd just add latency and burn quota faster.

Because distributed request coordination could be weaponized for DDoS attacks.

EZThrottle is a distributed system that:

• • Accepts requests from anyone on the internet
• • Coordinates across many machines
• • Sends requests to arbitrary URLs
• • Can queue millions of requests

If I open sourced it, someone could:

• 1. Fork the code
• 2. Remove rate limiting safety checks
• 3. Deploy 1,000 instances
• 4. Point them all at victim.com
• 5. Instant DDoS-as-a-service

I'm not interested in building attack infrastructure.

When your request completes, we POST the result to your webhook URL.

Retry schedule:

• • Immediate attempt
• • Retry after 1 minute
• • Retry after 5 minutes
• • Retry after 15 minutes
• • Retry after 1 hour
• • Give up after 24 hours

Webhook payload:

{
  "request_id": "req_abc123",
  "status": 200,
  "body": {...},  // API response
  "headers": {...},
  "duration_ms": 1234,
  "timestamp": "2025-01-15T10:30:00Z"
}

Results are also available via GET /results/:request_id for 7 days as backup.

We retry for 24 hours (see schedule above).

If all retries fail:

• • Results are still stored for 7 days
• • You can fetch them via GET /results/:request_id
• • We'll email you about failed webhooks

Not easily, and you probably shouldn't try.

EZThrottle is fundamentally async:

• • You send request → get "queued" response immediately
• • Request processes (seconds/minutes/hours later)
• • We webhook you the result

To use it synchronously, you'd need to:

• 1. Send request
• 2. Poll GET /results/:request_id in a loop
• 3. Block your thread waiting
• 4. Return result when ready

This defeats the entire purpose. If you're blocking and polling, just do exponential backoff yourself.

Cross-cluster routing via database coordination (the magic).

Right now, we run independent clusters per region. Eventually, they'll unite into a coordinated network:

Why this matters:

• ✓ Faster processing: Your request finds the cluster with capacity, not stuck waiting behind 1,000 others.
• ✓ Reliability: If entire US-East cluster goes down, EU can pick up the requests automatically.
• ✓ Low storage cost: Requests deleted immediately after completion. Only metadata persists for 30 days.
• ✓ Security: Minimal data at rest = minimal breach risk.

Latency consideration:

Cross-region routing adds ~50-100ms latency vs staying in-region. But if your request would wait 10 minutes in US-East queue vs 30 seconds in EU queue, that trade-off is worth it.

I don't promise an SLA yet.

Here's why I'm being honest about this:

What I CAN promise:

• • Built on BEAM/OTP (fault-tolerant by design)
• • Running on Fly.io (distributed across regions)
• • Supervision trees automatically restart crashed processes
• • Requests replicated across machines (minimal data loss)
• • I'm monitoring it 24/7 and care deeply about reliability

Goal: Rolling deploys with zero downtime.

Reality: EZThrottle may drop requests during deployments.

How deploys work:

• 1. Deploy new version to one machine
• 2. Wait for it to be healthy
• 3. Deploy to next machine
• 4. Repeat until all machines updated

Mitigation:

• • Deploys happen during low-traffic windows (3-5am ET)
• • Requests written to database for cross-region failover
• • If request drops, your SDK can retry (it'll hit EZThrottle again)

Requests: In-memory only (not stored)

Metadata: PostgreSQL on Fly.io (encrypted at rest)

Regions:

• • United States (primary)
• • Europe (GDPR-friendly)
• • Asia-Pacific (coming soon)

Data retention:

• • Request/response bodies: 0 days (never stored)
• • Metadata (logs): 30 days
• • Results (for polling): 7 days

Yes. Email: support@ezthrottle.network

What to expect:

Me. Rahmi Pruitt. Solo founder.

You probably shouldn't trust blindly. But here's my pitch: