Docs › API Reference › Response Headers

Response Headers

Every response from the FourA API includes a small set of custom headers. They're useful for tracing, support, billing reconciliation, and post-hoc analysis.

Headers FourA Sets

Header Set on Description
X-Foura-Request-Id Every /api/* response, including errors and 401s A UUID identifying this request. Log it on your side.
X-FourA-Credits Every /api/* response that reached the backend Credits spent on this call. Returned on success and on failure (the work was done either way).
Content-Type Every response Always application/json for the envelope. The target's content-type comes back inside the envelope's headers field.

X-Foura-Request-Id

Each call to POST /api/auto/, POST /api/single/, POST /api/proxy/, or POST /api/browser/ is tagged with a UUID. The header is set even when authentication fails, so you can correlate misconfigured calls too.

curl -i -X POST https://eu.api.foura.ai/api/single/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method": "GET", "url": "https://example.com"}'

HTTP/1.1 200 OK
X-Foura-Request-Id: 9f1c4e6c-7b2a-4d3e-8a1f-2c9d8e4a3b15
X-FourA-Credits: 2
Content-Type: application/json
...

When to use it

  • Support tickets: include the request ID and we can find the exact call in our records.
  • Your own logs: store it next to your application log line. If a customer complaint says "the data was wrong at 14:32", you can replay the exact request.
  • Dashboard tracing: the same ID appears in the Activity feed for keys you manage, so you can open the matching row and inspect the captured request and response.

Example: log on your side

import logging
import requests

log = logging.getLogger(__name__)

def fetch(url, api_key):
    resp = requests.post(
        "https://eu.api.foura.ai/api/single/",
        headers={"X-API-Key": api_key, "Content-Type": "application/json"},
        json={"method": "GET", "url": url},
    )
    request_id = resp.headers.get("X-Foura-Request-Id", "no-id")
    credits = resp.headers.get("X-FourA-Credits", "0")
    log.info("foura request_id=%s url=%s status=%s credits=%s", request_id, url, resp.status_code, credits)
    resp.raise_for_status()
    return resp.json()

async function fetchPage(url, apiKey) {
  const resp = await fetch('https://eu.api.foura.ai/api/single/', {
    method: 'POST',
    headers: { 'X-API-Key': apiKey, 'Content-Type': 'application/json' },
    body: JSON.stringify({ method: 'GET', url })
  });

  const requestId = resp.headers.get('X-Foura-Request-Id') || 'no-id';
  const credits = resp.headers.get('X-FourA-Credits') || '0';
  console.log(`foura request_id=${requestId} url=${url} status=${resp.status} credits=${credits}`);

  return resp.json();
}

X-FourA-Credits

X-FourA-Credits reports the credit cost of the call you just made. It's a meter, not a bill: the header reflects what the work spent regardless of outcome. The dashboard's billing layer only counts billable outcomes against your plan (see Request Outcomes for which outcomes are billable).

Cost reference

Engine Base With unblocker
Single 1 2
Proxy 5 10
Browser 15 30 (when a defense was solved)

/api/auto/ doesn't add a separate billable row. Its credit cost is the sum of the sub-calls it made internally (a single replay on a warm target can finish at 2; a cold solve on a hard site can spend much more). The X-FourA-Credits value on the auto response equals meta.credits in the body and tracks the full ladder cost.

Why both a header and a body field?

The header is convenient: you can read it before parsing the body, log it next to your request line, or sum it across many calls without JSON parsing. The body's meta.credits (Auto) or per-engine metadata (Single, Proxy, Browser dashboards) holds the same number, but readable inside the response envelope.

Cache Behavior

The API does not set Cache-Control or ETag on responses. Every call hits the backend. If you need caching, add it on your side.

Target Response Headers

The headers the target site returned are not on the FourA API response. They come back inside the JSON envelope as the headers field. For the Single and Proxy endpoints, this is an array of per-hop header objects (one entry per redirect step). For the Browser endpoint, it's a flat object of the final response headers.

{
  "status": 200,
  "headers": [
    { "Content-Type": "text/html; charset=utf-8", "Server": "..." }
  ],
  "data": "<!doctype html>...",
  "total_time": 0.42
}

If you need a specific target header, read it from the envelope's headers field, not from the HTTP response of the API call itself.

Last updated: June 30, 2026
← Request Outcomes