Troubleshooting Reserved Throughput vs Shared Pools
Understanding Capacity and Rate Limits
Fikra API does not currently advertise reserved throughput, dedicated capacity, or specific shared-pool isolation guarantees in its public documentation. Access is governed by account verification status and standard rate limits:
- Unverified accounts: 30 requests per minute (RPM).
- Trusted accounts: 100 requests per minute (RPM).
If you are experiencing capacity-related issues, they are likely due to hitting these rate limits or temporary upstream unavailability, rather than a lack of reserved infrastructure.
Common Error Codes
| HTTP Status | Meaning | Action |
|---|---|---|
| 400 | Malformed request or unsupported model alias. | Verify your request body structure and ensure the model field uses a valid Fikra alias (e.g., fikra-flash, fikra-pro-20b). |
| 401 | Missing, invalid, or inactive API key. | Check that your Authorization: Bearer fk_live_... header is correct and that the key is active in the Fikra dashboard. |
| 402 | Insufficient wallet balance. | Top up your token-credit wallet via the Fikra dashboard using Paystack (M-Pesa or cards). |
| 429 | Rate limit exceeded. | Implement exponential backoff. Ensure your account is verified to access the higher 100 RPM tier. |
| 503 | Upstream/provider temporarily unavailable. | Retry with exponential backoff. This indicates a temporary issue on the provider side, not a client-side error. |
Handling 429 and 503 Errors
When you receive a 429 (rate limit) or 503 (service unavailable) response, implement exponential backoff to avoid overwhelming the service. Do not assume automatic failover or dedicated capacity; instead, retry gracefully.
Python Example: Exponential Backoff
import time
import random
import requests
FIKRA_API_KEY = "your_api_key_here" # Load from environment variable in production
BASE_URL = "https://api.fikraapi.co.ke/v1"
def call_fikra_api(payload, max_retries=5):
url = f"{BASE_URL}/chat/completions"
headers = {
"Authorization": f"Bearer {FIKRA_API_KEY}",
"Content-Type": "application/json"
}
for attempt in range(max_retries):
try:
response = requests.post(url, json=payload, headers=headers)
if response.status_code in [429, 503]:
# Exponential backoff with jitter
wait_time = (2 ** attempt) + random.uniform(0, 1)
print(f"Received {response.status_code}. Retrying in {wait_time:.2f}s...")
time.sleep(wait_time)
continue
response.raise_for_status()
return response.json()
except requests.exceptions.RequestException as e:
if attempt == max_retries - 1:
raise e
wait_time = (2 ** attempt) + random.uniform(0, 1)
time.sleep(wait_time)
# Example usage
payload = {
"model": "fikra-flash",
"messages": [{"role": "user", "content": "Hello"}]
}
try:
result = call_fikra_api(payload)
print(result)
except Exception as e:
print(f"Request failed after retries: {e}")
Important Notes
- No SLA Guarantees: Fikra does not currently publish uptime SLAs or guaranteed response times. Plan your application logic to handle transient failures gracefully.
- Model Availability: Always check the Fikra dashboard or model registry for the current list of available aliases. Availability may vary.
- Verification: Ensure your account is verified to access the higher rate limit tier (100 RPM vs 30 RPM).
James Miano
CTO & ML Engineer at Lacesse Ventures. James specializes in low-overhead LLM quantization processes, custom ternary weights architectures, and localized server optimization.
Stop paying for overpriced round-trip latency
Why route queries over Western servers when you can use low-overhead hardware located in Nairobi? Save 87% on your monthly inference spend. No minimum credit limits. M-Pesa ready.