Kairos Archive

CORS & browsers

Call the API from page JavaScript on any origin. Nothing to configure on our side.

Cross-origin requests

Every file is served with Access-Control-Allow-Origin: * for GET and HEAD, and ETag is exposed to scripts. OPTIONS is answered with the preflight a conditional cross-origin request needs, so a browser can send If-None-Match and receive 304 instead of the file again. A 404 carries the CORS header too, so your code sees the status rather than an opaque failure.

Browsers send their own User-Agent, so the User-Agent rule needs nothing from page code.

Browser · revalidate versions.json with ETag
const cached = localStorage.getItem("versions");        // { etag, body }
const headers = cached ? { "If-None-Match": JSON.parse(cached).etag } : {};
const response = await fetch("https://api.kairosarchive.net/versions.json", { headers });
if (response.status === 304) return JSON.parse(cached).body;
const body = await response.json();
localStorage.setItem("versions", JSON.stringify({ etag: response.headers.get("ETag"), body }));
return body;

Your own Content Security Policy

If your site sets a CSP, allow the API host for data and for images. Card art is served from the same host under /images/.

CSP · the two directives to add
Content-Security-Policy:
  connect-src 'self' https://api.kairosarchive.net;
  img-src 'self' https://api.kairosarchive.net;

Images from a page

Card images are ordinary <img> sources: permanent addresses, hotlinking allowed with credit to Erik's Curiosa, no rate limit. Images explains the sizes and how to build an address.

What a browser cannot see

A 403 from the edge carries no CORS header, so it surfaces to page JavaScript as a network error rather than a status. Browsers cannot cause either 403 case (they always send a User-Agent and cannot write), so in practice a network error from a browser means the network.


Reference: registry API contract and published object definitions. Report a data or documentation issue.