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¶
- Hold
catalog.jsonin memory. Loadglossary.jsoninto your prompt. - Filter on
roles. You know who is asking. - Match on
titleandsummary. 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. - Fetch
articles/{id}.jsonfor the entry you chose. Answer fromcontentand citemeta.base_url+url. - 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'scoverageblock rather than assuming the guide is complete. - Breaking changes get a new version prefix and both are served until consumers move.