Skip to content

Retrieval API

This guide publishes its content as machine-readable JSON so a tool can answer questions from it rather than scraping pages.

Base URL: https://smartproperty-admin-guide.pages.dev/api/v1/

Read meta.base_url from any response instead of hardcoding that host. It follows the site, so when documentation moves to its own domain, consumers move with it.

What this is

Static JSON files served by the documentation site. There is no query interface, no authentication, and no writes. Every caller receives identical bytes. Fetch a resource whole and filter it locally.

Resources

Resource Purpose
catalog.json Titles, summaries, roles, and coverage. No article bodies. Small enough to keep in memory.
articles/{id}.json One document, fetched after the catalog has chosen it.
articles.json The whole corpus in a single request.
glossary.json Canonical terminology.
releases.json Dated release records.
schema.json The JSON Schema. Its resources map names which definition validates each path.

Every response embeds meta.api, which lists all of the above. One request to any resource is enough to discover the rest.

Answering a question

  1. Hold catalog.json in memory. Load glossary.json into your prompt.
  2. Filter on roles. You know who is asking.
  3. Match on title and summary. That is what the person actually asked about. Do not require a module first. Modules organise the guide for its authors, and a question like "reset my password" does not announce whether it belongs to Role Management or Platform Settings. Filter on what you know, match on what was asked.
  4. Fetch articles/{id}.json for the entry you chose. Answer from content and cite meta.base_url + url.
  5. If nothing matches, say the topic is not documented yet.

Step 5 depends on step 1. A consumer that has seen the whole catalog knows what the guide does not contain. A consumer that ran a query and got nothing back cannot tell an absent article from a failed lookup, and that is where a tool starts inventing procedures that do not exist.

Identity

id is the stable key. For articles and workflow guides it survives a retitle; url does not, because it is derived from the title. Store id.

An id that stops resolving means the content was withdrawn. Only material marked Published appears here, and documents are removed when that changes.

Freshness

meta.content_hash covers every content block, so one comparison answers whether anything changed. Each entry carries its own content_hash to narrow that to what actually moved. Neither is a timestamp, so they change only when content does.

meta.releases_coverage.complete_since bounds the release record. Before that date, absence is not evidence that nothing shipped.

The unversioned path

/api/articles.json is the original path and is byte-identical to /api/v1/articles.json. It has a live consumer and is supported with no removal date. Every field it carried before the versioned contract still exists with the same name, type, and value.

It now also carries article bodies, so it is considerably larger than it once was. If you only need to know what exists, catalog.json is the lighter and better target.

Limits

Worth knowing before you build against this:

  • Everything here is public to anyone with the URL. There is no access control, so nothing customer-specific or internal belongs in it.
  • Coverage is partial while authors work through the backlog. Check catalog.json's coverage block rather than assuming the guide is complete.
  • Breaking changes get a new version prefix and both are served until consumers move.