What are the rate limits for Fikra API?

Unverified accounts receive 30 Requests Per Minute (RPM), 300 requests per day and token quotas. Your first wallet top-up unlocks the Trusted tier at 3,000 RPM with no token ceilings (TPM and TPD are uncapped). Fixed request quotas only.

How does Fikra API track usage limits?

Every HTTP response injects decoupled Redis tracking headers: x-ratelimit-limit-requests, x-ratelimit-remaining-requests, and x-ratelimit-reset-requests.

What are the production rate limits for Fikra API?

Fikra API enforces strict throughput boundaries at the engine layer using a high-concurrency Redis token bucket. Caps stay deterministic per account tier and are enforced before any request leaves Fikra: you never share a bucket with anyone else.

Operational Account Tiers

Quotas are computed on a frequency basis (Requests Per Minute and Requests Per Day) and a token basis (Tokens Per Minute and Tokens Per Day) by our Redis proxy engine, completely independent of upstream hardware tracking.

Account Tier	Requests Per Minute (RPM)	Requests Per Day (RPD)	Tokens Per Minute (TPM)	Tokens Per Day (TPD)	Access Condition
Unverified	30 RPM	300 RPD	100,000 TPM	1,000,000 TPD	Default sandbox evaluation state. Free tier usage limits apply.
Trusted	3000 RPM	250,000 RPD	No limit	No limit	Unlocked permanently following your first successful wallet top-up. Token throughput (TPM/TPD) is uncapped on this tier; only request counts are metered.

Paid accounts have no token ceilings. Need higher request quotas than 3,000 RPM / 250k requests/day? Contact [email protected] for a reserved volume quota.

Decoupled Limit Tracking

Fallback routing happens entirely inside Fikra, so any rate-limit metadata an engine emits internally is irrelevant to you. Fikra strips internal routing headers and injects decoupled quota metadata based purely on your Fikra account tier.

Response Header Key	Returned Value Type	Metric Description
x-ratelimit-limit-requests	Integer	The hardcoded cap permitted under your assigned Fikra tier (e.g., 3,000 for Trusted).
x-ratelimit-remaining-requests	Integer	Remaining request count within your current 60-second sliding window.
x-ratelimit-reset-requests	Integer (Seconds)	Seconds remaining before your Redis sliding window resets completely.

Handling Rate Limits (429) & Upstream Backoffs

When request thresholds breach the assigned Fikra token bucket boundary, the system returns a standard 429 Too Many Requests. On the paid tier a 429 means the request-rate caps were hit (token counts are no longer metered there), so backoff briefly and retry.

Internal Retry Architecture

Engine capacity is pooled and internally retried by the Fikra router. If your application receives a 429, you breached your Fikra-assigned limits: it is never an internal capacity signal. 429s include Retry-After and X-RateLimit-Reset metadata.

Python Backoff Implementation

import time
import openai

def execute_safe_call(prompt):
    for attempt in range(5):
        try:
            return client.chat.completions.create(
                model="deepseek-v4.1-flash-1017",
                messages=[{"role": "user", "content": prompt}]
            )
        except openai.RateLimitError:
            # Backoff exponentially on Fikra limit exceptions
            wait_time = (2 ** attempt)
            time.sleep(wait_time)
            
    raise Exception("Inference execution abandoned after multiple timeouts.")

← Previous Topic

Model Registry

Review latency configurations and token limits across the engine matrix.

Next Topic →

Error Codes

Deconstruct server validations and identify client integration issues.