API architecture
The API portal is organized around four backend services because CertHub itself is organized that way. Each service has its own base URL and its own OpenAPI specification.
The four services
| Service | What it owns | Typical use |
|---|---|---|
| Tech Doc API | Products, knowledge units, knowledge topics, schemas | Resolve IDs, read structure, inspect field definitions |
| Records API | Record rows inside a knowledge topic | Export records, create evidence records |
| Tracer API | Traceability nodes and edges | Retrieve links between records |
| Document API | Document histories and revisions | Create rendered document objects |
The common call sequence
Most integrations do not start in the API reference and pick random endpoints. They follow a predictable flow:
- Use Tech Doc API to resolve product, KU, and KT identifiers and to fetch the KT schema
- Use Records API to read or create records
- Use Tracer API if you need the relationships between those records
The Document API is separate from that loop. It is for document histories and revisions, not for the usual records-and-evidence workflow.
Records and schemas live in different places
This is the most important architectural distinction:
- Tech Doc tells you what a knowledge topic looks like
- Records gives you the actual rows inside that topic
That is why integrations typically fetch the schema first, then fetch the records, then map opaque form keys to stable semantic names.
List responses
The public Records list flow documented today does not use dedicated pagination parameters such as page, limit, or cursor. Treat list responses as full filtered result sets and keep your filters as specific as possible.
Polling instead of webhooks
CertHub does not currently send webhooks or push notifications when product data changes. For recurring synchronization, poll on a schedule or trigger exports from your own workflow.