Versioning
CertHub versioning is mostly about the objects you work with, not about a public /v1 or /v2 URL prefix. The public API URLs documented in this portal do not currently use a versioned path segment.
History IDs versus revision IDs
For most CertHub objects, the stable identity and the current version are different things:
- A history ID identifies the object across all versions
- A revision ID identifies one specific version of that object
This matters because dashboard URLs often show history IDs, while API calls often need revision IDs.
Why revision IDs become stale
When a knowledge topic or knowledge unit is edited and a new revision is approved in CertHub, the old revision ID still exists but may no longer be the one you want to use. Any stored revision ID in configuration can become stale over time.
If your integration stores KT or KU revision IDs in configuration, re-resolve them from the history IDs after an approval:
- Call
GET /ku/{history_id}on the Tech Doc API to get the latest KU revision - Call
GET /kt/?product_history_id=...to get the latest KT revisions
Practical recommendation
Store stable history IDs where possible, and resolve fresh revision IDs at runtime or during a sync step. That reduces the chance of empty list responses and hard-to-diagnose 404s after approvals.
Cadence (CertHub’s public engineering example) pins revision IDs in its committed certhub.toml for the showcase tenant. That is fine for a frozen demo. On your own tenant, prefer history IDs in config and resolve revision IDs during sync. Otherwise the first approval after you paste IDs can return empty record lists.