Video — entry 001 of 35
An API of Ice And Fire
An API of Ice And Fire is a fan-built REST API serving structured data from George R. R. Martin's A Song of Ice and Fire — characters, houses, and books with their cross-references — book-centric records that also carry TV-adaptation annotations, the character payload including tvSeries and playedBy. It's completely keyless and free, returning plain paginated JSON with no rate-limit headers observed on repeated calls.
An API of Ice And Fire is a fan-built, keyless REST API serving structured data from George R. R. Martin's A Song of Ice and Fire — characters, houses, and books, with cross-references between them. The records are book-centric (books, povBooks, culture, and in-world born/died dates) but they also carry TV-adaptation annotations: the character payload below includes tvSeries and playedBy, and the provider's own homepage describes its scope as the universe of Ice and Fire "(and the HBO series Game of Thrones)".
GreatAPIs Score
Embed this badge
<a href="https://greatapis.com/api/an-api-of-ice-and-fire/"><img src="https://greatapis.com/badge/an-api-of-ice-and-fire.svg" alt="Scored 88 on greatapis.com"></a>Auth quickstart
- No API key required. A live
GET /characters/583with no headers or credentials returned full character data this run; every documented endpoint (characters, houses, books) answered the same way.
Your key is stored only in this browser (localStorage) and sent directly to the API — never to greatapis.
Look up a character by ID
GEThttps://anapioficeandfire.com/api/characters/583
{"url":"https://anapioficeandfire.com/api/characters/583","name":"Jon Snow","gender":"Male","culture":"Northmen","born":"In 283 AC","died":"","titles":["Lord Commander of the Night's Watch"],"aliases":["Lord Snow","Ned Stark's Bastard","The Snow of Winterfell","The Crow-Come-Over","The 998th Lord Commander of the Night's Watch","The Bastard of Winterfell","The Black Bastard of the Wall","Lord Crow"],"father":"","mother":"","spouse":"","allegiances":["https://anapioficeandfire.com/api/houses/362"],"books":["https://anapioficeandfire.com/api/books/5"],"povBooks":["https://anapioficeandfire.com/api/books/1","https://anapioficeandfire.com/api/books/2","https://anapioficeandfire.com/api/books/3","https://anapioficeandfire.com/api/books/8"],"tvSeries":["Season 1","Season 2","Season 3","Season 4","Season 5","Season 6"],"playedBy":["Kit Harington"]}Try it
Developer reference
https://anapioficeandfire.com/api20,000 requests/day per IP
- GET/characters/{id}
- GET/books
- GET/houses
Gotchas & limits
- Plain
http://is not left open here: a liveGET http://anapioficeandfire.com/api/characters/583returned an HTTP 301 redirect (Location: https://anapioficeandfire.com/api/characters/583) to the https:// URL, confirmed this run. - A nonexistent-but-well-formed numeric ID (
/characters/9999999) and a non-numeric path segment (/characters/abc) are both HTTP 404 with an empty body — there is no JSON error envelope to parse either way, confirmed live this run against both. - Pagination is exposed only via the RFC 5988
Linkresponse header, not in the JSON body: a liveGET /booksreturnedlink: <.../books?page=2&pageSize=10>; rel="next", <.../books?page=1&pageSize=10>; rel="first", <.../books?page=2&pageSize=10>; rel="last"with no page/total fields anywhere in the array body itself — callers must parse the header to paginate, and it's only exposed cross-origin because of the next gotcha. - CORS is Origin-conditional: a GET with no
Originheader gets noaccess-control-allow-originheader at all, while the same GET with anOriginheader gets backaccess-control-allow-origin: *plusaccess-control-expose-headers: Link— that explicit expose is what makes theLinkpagination header above readable from browser JS at all; without it a browser's fetch/XHR can't see it even though curl always can. - A live
OPTIONSpreflight (withOrigin+Access-Control-Request-Method: GET) returned HTTP 204 withaccess-control-allow-methods: GET,HEADand set twoARRAffinitysession cookies scopedHttpOnly; Secure— harmless for a keyless GET-only API, but a sign the backend sits behind an IIS/Azure App Service load balancer rather than a bare Cloudflare Worker.