Skip to main content
EyeQuant’s API is designed for high availability, but like any cloud service, temporary capacity issues can occur. This page explains how to monitor API status, what the over_capacity error means, and how to build a resilient integration that handles disruptions without manual intervention.

​
Checking API status

When the EyeQuant service is temporarily unavailable, the API responds with an over_capacity error code rather than silently failing or hanging. You can use this signal as a reliable indicator that the service is under pressure and that retrying after a delay is the right course of action. For extended outages, reach out to the EyeQuant team directly — the support and sales team can be contacted at sales@eyequant.com and can provide status updates or estimated recovery times if needed.

​
The over_capacity error

When the service is unavailable, you will receive the following JSON error body alongside an HTTP 503 Service Unavailable status: 
{
  "error": {
    "code": "over_capacity",
    "message": "The service is currently unavailable."
  }
}
Treat this error as transient — it signals a temporary condition, not a permanent failure. Your integration should catch this code and apply a retry strategy rather than surfacing it as an unrecoverable error to your users.

​
Handling outages gracefully

Building retry logic into your integration from the start means a temporary capacity issue has little to no impact on your users. Follow these best practices:
  • Implement exponential backoff when retrying failed requests — double the wait time between each attempt to avoid flooding the service.
  • Treat over_capacity as a transient error — always retry after a delay rather than surfacing it as a permanent failure.
  • Avoid tight retry loops — retrying immediately in a fast loop can worsen capacity issues for all users.
  • Build retry logic into your polling loop — if you poll for analysis results, your polling code is the right place to absorb transient errors.
The following Python example shows a simple retry function with exponential backoff: 
import time
import requests

def get_analysis_with_retry(api, url, max_retries=5):
    for attempt in range(max_retries):
        response = api.get(url)
        if response.status_code == 200:
            return response.json()
        elif response.status_code == 503:
            # over_capacity — back off and retry
            wait = 2 ** attempt
            time.sleep(wait)
        else:
            response.raise_for_status()
    raise Exception("Max retries exceeded")
This function doubles the wait time on each attempt — 1 second, 2 seconds, 4 seconds, and so on — giving the service time to recover before each retry.
For production integrations, use a job queue to manage analysis submissions and retries rather than polling synchronously. A queue decouples submission from result retrieval and makes exponential backoff straightforward to implement reliably.