Authentication and errors

API keys

Send your key as Authorization: Bearer <key>. Keys start with sk_ followed by 40 letters and digits. One key grants every endpoint; keys have no scopes.

Create and revoke keys on the API keys page of the dashboard. A revoked key stops working within a minute. A key spends your account's credits, so keep it on servers and out of code you ship to browsers or apps.

Error format

Errors carry a stable code to branch on, a message for people reading logs, and details where the code has any:

{
  "error": {
    "code": "CONCURRENT_LIMIT_EXCEEDED",
    "message": "Concurrent limit exceeded",
    "details": { "limit": 1 },
    "timestamp": "2026-09-15T12:00:00.000Z"
  }
}

Validation failures use a different shape, with one entry per invalid field:

{
  "success": false,
  "error": "Request validation failed",
  "details": [{ "field": "prompt", "message": "Prompt cannot be empty" }]
}

Items of a batch fail inside a 200 response instead, with codes VALIDATION_ERROR, RESOURCE_ALREADY_EXISTS or INSUFFICIENT_CREDITS; see batches.

Error codes

Retrying safely

• 429 is always safe to retry: the request was not admitted, so nothing ran or was charged. A SERVICE_OVERLOADED 429 carries Retry-After in whole seconds — wait at least that long. The other 429s carry no Retry-After; back off with jitter. A rate-limit 429 clears within a second, a concurrency 429 when a running job finishes.
• 5xx, timeouts and connection errors are safe to retry for GET and DELETE, and for task creation when every task carries an idempotencyKey. A repeat of a task that was created answers 409 RESOURCE_CONFLICT (in a batch, RESOURCE_ALREADY_EXISTS): the task exists.
• Synchronous monitor calls are charged on success and may still be running when a connection drops. Retry them only when the request never reached the server (connection refused, host not resolved). A 500 or 502 from them is final: the server has already retried.
• Other 4xx will fail the same way again; fix the request.

The SDKs apply exactly this policy, with 2 retries by default (maxRetries / max_retries), capped exponential backoff with full jitter, and per-attempt timeouts of 30 seconds, or 360 seconds for synchronous calls (timeoutMs and syncTimeoutMs / timeout and sync_timeout). Errors they give up on are raised as ApiError:

TypeScript

import { ApiError, Client } from "@answerline/sdk";

try {
  await client.chatgpt({ prompt: "iPhone 17 or Galaxy S26?", country: "US" });
} catch (err) {
  if (!(err instanceof ApiError)) throw err;
  console.error(err.status, err.code, err.meta.requestId, err.body);
}

Python

from answerline import ApiError

try:
    client.chatgpt("iPhone 17 or Galaxy S26?", "US")
except ApiError as err:
    print(err.status, err.code, err.meta.request_id, err.body)

Request ids

Every response carries an X-Request-Id header. Send your own (1 to 128 letters, digits, -, _, . or :) to tie a request to your logs; otherwise one is generated. Quote it when you contact support. The SDKs send yours through the headers option of request, expose it as meta.requestId / meta.request_id and include it in ApiError messages.

curl

curl -i "https://api.answerline.dev/v1/credits" \
  -H "Authorization: Bearer $API_KEY" \
  -H "X-Request-Id: nightly-run-42"

TypeScript

const { data, meta } = await client.request("GET", "/v1/credits", undefined, {
  headers: { "X-Request-Id": "nightly-run-42" },
});
console.log(meta.requestId);

Python

data, meta = client.request("GET", "/v1/credits", headers={"X-Request-Id": "nightly-run-42"})
print(meta.request_id)