IDs and relationships
CertHub uses different identifiers in the dashboard UI and in the API. Mixing them is the most common integration mistake. This page explains which ID to use where and how the major objects relate to each other.
The core distinction: history ID vs revision ID
CertHub tracks two kinds of identifiers for most objects:
| Type | Where you see it | What it represents |
|---|---|---|
| History ID | Dashboard URLs, query parameters in the UI | The stable identity of the object across all its versions |
| Revision ID | API responses, Records and Tech Doc API calls | A specific version of that object |
They look the same, but they are not interchangeable. Using a history ID where the API expects a revision ID returns a 404 or an empty result.
Where to find each ID
Product history ID
In the CertHub dashboard, open a product. The URL contains the product history ID:
https://app.certhub.de/dashboard/products/PRODUCT_HISTORY_ID/...
Use this for linked_product in RecordCreate.context and for filtering products in the Tech Doc API.
Knowledge unit history ID and revision ID
The dashboard URL uses the KU history ID:
https://app.certhub.de/dashboard/products/.../ku/KU_HISTORY_ID/...
To create a record, you need the KU revision ID. Resolve it from Tech Doc:
curl "https://techdoc.prod.certhub-containers.containers.certhub.tech/ku/KU_HISTORY_ID" \
-H "X-API-Key: YOUR_API_KEY"
Use the returned id as knowledge_unit_id in RecordCreate.context.
Knowledge topic history ID and revision ID
The dashboard URL uses the KT history ID in the query parameter:
https://app.certhub.de/dashboard/products/.../ku/...?knowledgeTopicId=KT_HISTORY_ID
The Records API and most Tech Doc workflows need the KT revision ID:
curl "https://techdoc.prod.certhub-containers.containers.certhub.tech/kt/?product_history_id=PRODUCT_HISTORY_ID" \
-H "X-API-Key: YOUR_API_KEY"
Each KT in the response has a _id field. That is the revision ID you pass to the Records API.
Quick reference
| What you need | Where to find it | API field |
|---|---|---|
| Product history ID | Dashboard URL path segment | linked_product in RecordCreate.context |
| KU history ID | Dashboard URL path segment | Pass to Tech Doc GET /ku/{history_id} to get the revision |
| KU revision ID | Tech Doc API response id | knowledge_unit_id in RecordCreate.context |
| KT history ID | Dashboard URL query knowledgeTopicId= | Only for dashboard links |
| KT revision ID | Tech Doc API response _id | context__knowledge_unit_topic_id and knowledge_unit_topic_id |
| Record ID | Records API response _id | Tracer nodes, GET, PATCH |
How the objects relate
- A product contains knowledge units
- A knowledge unit contains knowledge topics
- A knowledge topic defines the schema for one type of record
- A record is a row inside a knowledge topic
- Tracer links records to other records
Common mistakes
- Using the KT history ID from the dashboard URL in a Records API call
- Using the KU history ID when
knowledge_unit_idexpects a revision ID - Assuming
linked_productwants a product revision ID when it actually wants the product history ID