The corpus as JSON, read API

The endpoints

All read only. Responses are application/json, cached an hour at the edge and served out of the same corpus every page on this site renders.

GET/api/builderstry itEvery builder, in corpus rank order: verdict, output type, export status, who submits, price.GET/api/builders/{slug}try /api/builders/rorkOne builder with the evidence behind every claim on it, plus any App Store listings noted. 404 on an unknown slug.GET/api/matchupstry itThe head to head comparisons that exist, with the verdict text for each.GET/api/compare/{slug}try /api/compare/rork-vs-vibecodeOne head to head, hydrated: both builders and the evidence for each side.GET/api/healthtry itThe corpus reporting on its own condition: row counts, the verdict split, and what the nightly link check last found.

The vocabulary

review_verdict is the column this product exists for: ships, ships-with-caveats, blocked, unknown. How each one is reached.

submits_for_you is load bearing rather than cosmetic. App Store guideline 4.2.6 rejects apps submitted by a generation service on a client’s behalf, so builder-submits is a risk marker, not a feature.

kind, on every piece of evidence, says what the source is: apple-guideline, vendor-doc, vendor-marketing, third-party-report, app-store-listing. So a vendor’s marketing can be weighed differently from Apple’s own guideline text.

Anything the sources do not settle comes back unknown. Nothing is estimated, including price.

There is no write endpoint

By design. The corpus is a hand assembled file that a person read every source for, and the value is that a person read them. Corrections go to hello@thecompound.tech with the URL that contradicts the row, and the row changes.

For an answer engine rather than a client, the whole corpus is also served as prose at /llms.txt.