FFXIV Collect

Gotchas & limits

• This API has no pagination at all — ?page is accepted, echoed back, and completely inert. Live this run, /mounts?limit=2 returned ids [437, 435] and ?limit=2&page=2, &page=3, &page=70, &page=999 every one returned the same two ids; same result on /achievements and /minions. Don't trust the query echo as evidence the server honored anything: offset, start, skip, id_gt and even a made-up bogusParam are all echoed into query and all equally no-ops. What limit does do is cap the response and silently clamp to the corpus size (?limit=1 → 1, ?limit=353 → 353, ?limit=400 and ?limit=1000 → still 353), which is why no total-count field exists: the correct strategy is a single unlimited GET. GET /mounts with no params returned 200, 354,689 B, "count": 353 and all 353 mounts in one response. So count tells you how many came back, never how many exist.
• What that one big GET gives you instead of paging is a newest-content-first ordering — the only ordering guarantee on offer, and not mentioned in the Postman-documenter page that serves as the docs (documenter.getpostman.com, a third host distinct from both the API and the site's own homepage — confirmed live this run, 200, text/html; charset=utf-8). Verified live this run across the full unlimited response of all three collection types (353 mounts, 583 minions, 3,946 achievements): patch descends monotonically from newest to oldest in every one, with each patch's rows in one contiguous block (mounts and minions open at 7.55 and end at 2.0; achievements end at 1.0). So the first N results are the most recently added collectables. Note id is not monotonic — /mounts opens [437, 435, 430, 429, 337, 446] — so you can't hand-roll paging by id ranges. Don't over-read the within-patch tiebreak either: mounts happen to run order descending inside each patch group, but achievements do not and minions carry no order field at all, and order_group is not a sort key on any of them (mounts' 7.51 group runs 10262, 10254, 10011, 10271, 1240, monotonic in neither direction).
• Field sets diverge by collectable type — don't write one parser for all of them. owned (a percentage string) is on all three types checked live this run, but sources is on mounts and minions only and is absent from achievements entirely: /achievements/1, /2, /5, /100 and /500 each returned the same 10-key shape (id, name, description, points, order, patch, owned, icon, category, type) with no sources key at all, while /mounts/1 and /minions/1 both carry one. Achievements instead have points/category/type, and the key set isn't even fixed within the type: /achievements/1000 returned those same 10 keys plus an 11th, a reward object, which /achievements/1 does not have (still no sources on either). Check for a key rather than assuming it.
• The 404 shape is the same compact JSON as a success, not a distinct error dialect — a live GET this run against a nonexistent id (/mounts/999999) returned real HTTP 404, 34 B: {"status":404,"error":"Not found"}, same content-type: application/json; charset=utf-8 as every 200. Both the 200 and the 404 also carry undocumented x-runtime and x-request-id headers, handy for correlating a specific call when reporting a data issue upstream.
• Character lookups (/characters/{lodestoneId}) 404 for any Lodestone ID that hasn't already been indexed by FFXIV Collect's own crawler — several plausible-looking IDs probed live this run all returned the same {"status":404,"error":"Not found"} shown above. This endpoint only works for characters someone has already looked up on the site itself; it is not a general-purpose Lodestone proxy.