Choose the right API
The API reference is organized by backend service because that is how the platform is built. Your implementation usually starts from a workflow instead: what data do you need, where does it live, and whether you are reading, writing, or traversing links.
At a glance
| If you need to... | Use this API | Why |
|---|---|---|
| Read product structure, KUs, KTs, and field definitions | Tech Doc API | It is the source for schemas, products, and revision IDs |
| Read or create rows inside a knowledge topic | Records API | It stores the actual record data |
| Retrieve links between records | Tracer API | It exposes traceability nodes and edges |
| Create rendered document histories or revisions | Document API | It handles document objects rather than structured records |
Typical developer journeys
Export controlled data to engineering tools
Use this when CertHub is the source of truth and your downstream tools need a synchronized copy of requirements, verification definitions, or other controlled records.
Typical call sequence:
- Tech Doc API to resolve product, KU, and KT identifiers and read the KT schema
- Records API to list the records in the target knowledge topic
- Tracer API if you also need the links between those records
Start with Export Records from CertHub.
Write controlled evidence back
Use this when your engineering process produces evidence outside CertHub and you want CertHub to hold a controlled record that points back to that evidence.
Typical call sequence:
- Tech Doc API to resolve the current KT and KU revision IDs and read the schema
- Records API to create the evidence record
Start with Write Evidence Records.
Work with traceability itself
Use this when records already exist and you need to understand or reuse the links between them.
Start with Work with tracer.
Work with rendered documents
Use this when you are creating document histories or document revisions. If your goal is moving structured product data or engineering evidence, you probably do not need the Document API.
Start with Work with documents.
Common mistakes
- Starting in the API reference before understanding whether you need Tech Doc, Records, or Tracer
- Using dashboard history IDs where the API expects revision IDs
- Treating Records as if it contained the schema, instead of resolving the schema from Tech Doc first
- Storing full test artifact trees in CertHub instead of writing a short evidence record with a link