EveryCRT:Data API

Template:TOC right The EveryCRT Data API is a documented way to fetch the structured data of EveryCRT programmatically — for example, to build a third-party app that mirrors, indexes, or analyzes the wiki.

It is not a custom REST service. It is a thin documentation layer over the standard MediaWiki Action API and Semantic MediaWiki endpoints, plus one wiki-maintained manifest that lists the canonical entity-type categories.

No authentication is required. All data is publicly readable.

Sync pattern

The recommended way to mirror the wiki is two-step:

Fetch the manifest once to discover the entity types and how to enumerate each.
For each entity type, fetch its list of pages (with last-modified timestamps), then call entity facts on each page you want full data for.

For ongoing incremental sync, poll recent changes since your last sync timestamp and re-fetch only the affected pages.

Manifest

The manifest is a JSON document listing every canonical entity-type category, with live page counts and ready-to-use enumeration URLs. It updates automatically as the catalog grows; new entity types added in the future will appear here without API clients needing code changes (assuming they iterate over entity_types rather than hardcoding).

Human-readable view: EveryCRT:Data API/manifest

Programmatic fetch (recommended):

GET https://wiki.everycrt.com/w/api.php?action=expandtemplates&text=%7B%7B%23invoke%3ADataAPIManifest%7Cjson%7D%7D&prop=wikitext&format=json&formatversion=2

The response wraps the manifest in expandtemplates.wikitext as a string; parse that string as JSON:

<syntaxhighlight lang="javascript"> const url = 'https://wiki.everycrt.com/w/api.php'

 + '?action=expandtemplates'
 + '&text=%7B%7B%23invoke%3ADataAPIManifest%7Cjson%7D%7D'
 + '&prop=wikitext&format=json&formatversion=2';

const res = await fetch(url, {

 headers: { 'User-Agent': 'my-app/1.0 (https://example.com/contact)' },

}); const { expandtemplates } = await res.json(); const manifest = JSON.parse(expandtemplates.wikitext);

console.log(manifest.entity_types); </syntaxhighlight>

Listing entities

Use Semantic MediaWiki's action=ask endpoint to enumerate pages of a given entity type. The manifest's list_url for each entity type does exactly this — returning every page with its Modification date, which is what you want for indexing and for driving incremental sync:

GET https://wiki.everycrt.com/w/api.php?action=ask&format=json&formatversion=2&query=[[Category:CRT models]]|?Modification date|limit=500

The query supports any SMW ask syntax — additional printouts, filters, ordering, etc.

Page through with |offset=N in the query.
Maximum limit per request is 500.

Example — all Sony CRT models with screen size and release year:

GET https://wiki.everycrt.com/w/api.php?action=ask&format=json&query=[[Category:CRT models]][[Has brand::Sony]]|?Has screen size inches|?Has release year|limit=500

For interactive query development, use Special:Ask.

Entity facts

For a single page, the action=browsebysubject endpoint returns every SMW fact known about it — including subobjects (CRT inputs, outputs, voltage ranges, etc.):

GET https://wiki.everycrt.com/w/api.php?action=browsebysubject&format=json&formatversion=2&subject=Sony_KV-20FV300

This is the right endpoint for "give me everything you know about this entity" — no need to enumerate properties up front. New properties added to the wiki are automatically included in the response.

Subobjects are returned as additional subjects with names like Sony_KV-20FV300#_HASH. Treat them as child records of the parent page; together they describe the CRT inputs, outputs, voltage ranges, and so on.

For interactive browsing, use Special:Browse.

Recent changes

For incremental sync, poll action=query&list=recentchanges filtered by a timestamp. The standard MediaWiki Special:RecentChanges view is the human-readable equivalent:

GET https://wiki.everycrt.com/w/api.php?action=query&list=recentchanges&format=json&formatversion=2&rcprop=title|timestamp|ids|sizes|user&rclimit=500&rcend=2026-05-01T00:00:00Z

A typical sync loop:

Save your "last sync" timestamp (UTC ISO 8601) after each successful pass.
On the next sync, fetch recent-changes with rcend=<previous timestamp>.
For each unique title in the response, re-fetch via browsebysubject (or remove from your index if it was a deletion — see rctype=log and rcshow options for handling deletes and moves).
Save the new "last sync" timestamp.

To filter to specific namespaces, add &rcnamespace=0|3000 (main + Document, for example). Namespace IDs are listed via:

GET https://wiki.everycrt.com/w/api.php?action=query&meta=siteinfo&siprop=namespaces&format=json&formatversion=2

RDF export

For semantic-web-style consumption, Special:ExportRDF returns RDF/OWL for individual pages or entire category subtrees:

GET https://wiki.everycrt.com/wiki/Special:ExportRDF?pages=Category:CRT%20models&recursive=1

This is more verbose than the JSON endpoints; most app developers will prefer browsebysubject.

Conventions and stability

All endpoints return UTF-8.
Page titles are case-sensitive after the first character (standard MediaWiki).
Subobjects (per-input, per-output, per-voltage-range facts) appear as separate subjects in browsebysubject output, with titles ending in #_HASH. Treat them as child records of the parent page; you do not need to fetch them separately.
The set of properties on any one entity type may grow over time. Clients using browsebysubject automatically pick up new properties; clients using fixed action=ask printouts will need updates when they want to read newly added fields.
Entity-type categories listed in the manifest are stable. New entity types may be added; existing ones will not be silently renamed.
This is a community wiki; data quality varies. Treat values as best-effort, especially for newer or less-documented models.

Etiquette

The wiki is publicly readable and no authentication is required for any of these endpoints. Please be a good citizen:

Set a descriptive User-Agent on your requests (e.g. my-app/1.0 (https://example.com/contact)) so the wiki operators can reach you if there's a problem.
Cache the manifest — it changes slowly (new entity types are rare).
For full syncs, sleep briefly between requests; a few requests per second is fine.
Use recent changes for incremental sync rather than re-walking the whole catalog every time.

If your app is doing something cool with EveryCRT data, drop a note on the community channels — we'd love to see it.