Errors
This page covers the operational details you need when running a CertHub integration in production or CI.
Common HTTP status codes
| Status | Meaning | What to check |
|---|---|---|
| 200 | Success | - |
| 201 | Created, for example POST /records/ | - |
| 401 | API key missing, expired, or invalid | Regenerate the key in Settings and confirm the X-API-Key header |
| 403 | The key's user does not have permission for this operation | Check the user's role and permissions |
| 404 | Object not found | You may be using a history ID where a revision ID is expected, or vice versa |
| 422 | Validation error | Read the detail array in the response body and check required fields |
Empty list []
An empty list from GET /records/ usually means the KT revision ID is wrong. The most common mistake is using the dashboard history ID instead of the Records API revision ID.
Polling and change detection
CertHub does not currently send webhooks or push notifications when data changes. Your integration polls.
- Run your export on a schedule or trigger it on relevant events in your workflow
- Compare against a previous export to detect changes
- Avoid calling
GET /kt/without filters on large tenants
Rate limits
There are no published rate limits. Be reasonable: do not poll more frequently than your workflow requires, and avoid unbounded parallel requests to the Tracer batch endpoint.