API access, honestly described
The API surface is designed but not public. What it would expose, and the shapes it would use — no fabricated endpoint, key, or working call.
Status: not yet public
There is no public API: no keys, no SLA, no versioning promise. The JSON endpoints the desk itself calls — /api/verdict,/api/availability,/api/cold-read,/api/related-names — exist and are rate-limited per IP, but they are an internal interface: they can change without notice and are not supported for third-party use. Access is by request, granted individually, via the desk address.
Appraise
GET /api/verdict?name=<term>
Runs the same machine-checkable gates as the appraisal page. Response shape mirrors the appraisal structure: input, normalised name, TLD, length, syllables, a 0–100 score, a tier, and the per-gate checks (including the human judgement entries surfaced as manual flags, never scored).
Generate — planned, no endpoint
no route — the engine runs in the browser
The generator pageruns the construction engine in the browser and returns a shortlist of candidates sorted by score. Each candidate carries its root, suffix, phonotactic and neighbourhood numbers, and the morpheme story — the one-line “root + suffix” explanation the doctrine requires per candidate. A server-side route is planned, not built.
Availability check
GET /api/availability?name=<term>
Returns a per-TLD availability snapshot with an explicit re-check at the registry caveat, because every availability result is a snapshot and open seams close in days.
Requesting access
When the API opens, access will be granted case-by-case. To be considered, open an issue with your use case and volume on the project on GitLab. There are no keys to request today.