By Fikra Support • 3 min read

Troubleshooting Reserved Throughput vs Shared Pools

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).

JM
// The Founder

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.

usagestatusdashboard