Claims data JSON:API feed
Fact Check :: NZ publishes every Claim it has reviewed through a read-only JSON:API feed. No sign-up, no API key, no rate limit beyond ordinary good manners.
This document explains what a Claim actually is, not the JSON:API query mechanics, which the spec itself already covers well. The intended way to use this feed is to pull the full set of published Claims down and work with your own copy. Build a search index, a different front end, a research dataset, whatever you like. Go nuts. Rather than treating it as a live query backend for per-request lookups.
A Claim is an editorial verdict, not a neutral fact record: each one states something a public figure, social media comms, or advertisement said, and gives this site's rated assessment of it (see “Truthiness” below) along with the sourcing behind that rating. That rating is Fact Check :: NZ's own editorial judgment, not an objective fact if you republish or build on this data, attribute the verdict to this site rather than presenting it as your own.
Attribution can be as simple as a note in the footer or a mention on an About or Data Sources page.
An apology
This grew out of a semi-rushed project so some field names don't exactly mesh with their end content. e.g., the Speakers vocab and Said By field also include things like "Party Comms", and Pamphlets.
Also, the Primary/Secondary/Tertiary tags thing... These will be refactored in the future. I had too much data in the site to alter at this point. This update will happen after the General Election though.
Just roll with it in its current shape for now.
Access
Base URL: https://fact-check.nz/jsonapi
No authentication. Everything below is a plain GET; POST/PATCH/DELETE all return 405 Method Not Allowed — there is no write access at all, for anyone.
Only published content is ever returned. A Claim awaiting review (or since retracted) simply isn't in the collection and isn't fetchable by ID either. When fetching the full set you may want to verify all your current Claims are still present in the data. If you are wanting to keep the historical claims, that is your prerogative.
Getting the full set of Claims
GET /jsonapi/node/claim
This returns a page of Claims (50 at a time); the response's top-level links.next gives the URL for the next page. Follow it until a response has no links.next, and you have every published Claim. This is a safe and complete operation to repeat on a schedule. There's no separate “changes since” feed, so a periodic full re-fetch (comparing each Claim's changed timestamp against your own copy, to detect edits) is the supported way to stay current.
The same pattern applies to the supporting vocabularies (taxonomy_term/tags, taxonomy_term/speakers, taxonomy_term/political_parties, taxonomy_term/truthiness). Each is its own small collection worth fetching in full and keeping alongside your copy of the Claims, rather than resolved one at a time per Claim. A Claim's own JSON only carries UUID references to these (as JSON:API relationships); resolving those into actual names, colours, etc. is done by joining against your local copy of these collections, not by re-fetching per Claim.
What a Claim contains
Each Claim is a node--claim resource. Its meaningful attributes:
| Field | Meaning |
|---|---|
title | The claim's headline, as displayed on the site. |
body.processed | The editorial commentary and correction, as rendered HTML. This is the actual analysis, not just a caption. body.value is the same content as raw stored HTML; body.summary is a shorter standalone summary, present only on longer Claims. |
field_claim_date | Legacy field. Will likely be removed. |
field_source_urls | Where the claim came from and other supporting references, an array of {uri, title} pairs, e.g. a news article, an official transcript, a social media post. |
path.alias | The claim's canonical URL on the site, for linking back to the original. Linking back is not a requirement. |
changed | Last-modified timestamp, Compare this against your own stored copy to detect edits on re-fetch. |
And its relationships to other resources:
| Relationship | Points to | Notes |
|---|---|---|
field_truthiness | one taxonomy_term--truthiness | The rating, see below. Every Claim has exactly one. |
field_said_by | one or more taxonomy_term--speakers | Who made the claim, where attributable. |
field_primary_tag, field_secondary_tag, field_tertiary_tag | taxonomy_term--tags (each, zero or more) | The claim's subject matter, see “Tags” below. Each field can be zero or more Tags. |
field_media | zero or one media--image | Photographed evidence (a billboard, a mail-out flyer), where the claim came from print/physical material rather than a URL. |
Tags: subject matter
All three tag fields on a Claim (field_primary_tag/ _secondary_tag/_tertiary_tag) draw from the same single tags vocabulary, it's one subject hierarchy, not three separate ones. A tag's own parent relationship (in the taxonomy_term/tags collection) points to another tag one level up; how many links that chain has is what makes a given tag Primary, Secondary, or Tertiary. A top-level (Primary) tag's parent relationship resolves to a "virtual" placeholder resource rather than being absent, that is JSON:API's way of representing Drupal's “no parent” value, not an error.
Each tag also carries field_published_claim_count, how many published Claims sit under it, counting Claims tagged on any of its descendant tags too, not just that exact term. If you are using a subset of Claims, and you want to use this sort of count, you should calculate this yourself.
The truthiness scale
taxonomy_term--truthiness is a small, fixed, ordered vocabulary. Order by its weight attribute (ascending = most true):
| weight | name |
|---|---|
| 0 | True |
| 1 | Kinda True |
| 2 | Misleading |
| 3 | Mostly False |
| 4 | False |
| 5 | Unsubstantiated |
Speakers and political parties
A taxonomy_term--speakers resource is a person (or account) a Claim can be attributed to. An MP, a party, a political commentator, etc. Alongside the usual name, it carries field_electorate, field_wikipedia_reference, and a relationship to taxonomy_term--political_parties, some of these can be empty for a given "speaker" (not every speaker is an MP with an electorate, or even a person, for instance).
Images
A Claim's field_media resolves to a media--image resource, which itself relates to the underlying file--file for the actual image. The file's uri.url is the original, full-size upload, there is currently no way to request a resized version through this feed; if you need thumbnails, resize client-side after downloading.
Boundaries worth knowing about
- Links inside a Claim's
body.processedHTML (e.g. to a related gallery or article) are ordinary<a>tags, not a separate structured field — there's no dedicated “related content” relationship to follow. - Requesting a Claim that isn't published returns a plain
404, the same as a Claim that never existed. - This feed's shape may evolve over time, it isn't a versioned endpoint. If you're building something durable on it, keep an eye on this page.
- I will not alter existing fields until after the 2026 General Election though.