Skip to main content
    QHSEtech
    Updated
    Release Notes

    API Changelog

    Back to docs
    1. 2026-04-18v1.1.0added

      Three new endpoints + standardized envelope

      • Added GET /v1/reviews/:softwareId — approved reviews per product.
      • Added GET /v1/glossary — full QHSE glossary (also supports ?q= filter).
      • Added GET /v1/search?q= — AI-ranked semantic search across the catalog.
      • All responses now include X-Request-Id and X-API-Version headers.
      • Errors moved to a structured envelope: { error: { code, message, request_id } }.
      • List endpoints now include has_more + next_offset in pagination.
      • Cache-Control headers added to GET endpoints (60s–1h depending on volatility).
    2. 2026-04-18v1.0.1fixed

      Accurate category counts

      • GET /v1/categories now uses a database-side aggregation (RPC) instead of a 1000-row scan, so counts stay correct as the catalog grows.
    3. 2026-04-17v1.0.0added

      Initial public release

      • GET /v1/software, /v1/software/:id, /v1/categories.
      • Bearer-token authentication (qhse_live_*).
      • OpenAPI 3.1 spec at /api-docs/openapi.json.
      • Postman collection + interactive Swagger UI explorer.
      • Magic-link email verification for sensitive key management actions.

    How to read this log

    Entries run from newest to oldest. Each one carries a date, a release number in the form major.minor.patch and one of four type labels. The log currently holds 3 entries, and the most recent is dated 2026-04-18. Treat the log as the record of changes that were written down, not as a guarantee that nothing else changed: if a response differs from what the documentation describes and no entry explains it, report it.

    • Added marks something new: an endpoint, a field, a header or a documented behaviour.
    • Changed marks an alteration to something that already existed.
    • Fixed marks a correction to behaviour that did not match its documentation, such as the category counts entry above.
    • Deprecated marks something scheduled for removal. No entry carries this label yet.

    Do not read only the “changed” and “deprecated” entries. In release 1.1.0 the new error format and the extra response headers are listed inside an “added” entry, so a client that parses error bodies should be checked against that entry even though its label does not say that something was altered.

    Which version number applies to you

    Three numbers appear around the API, and they answer different questions. The major version in the address, /v1/, is the one your code calls and changes only when a breaking change forces a new prefix. The X-API-Version response header repeats that major version, so it reads v1 and does not move for additive releases. The full release number, such as 1.1.0, is the one in this log and in the info.version field of the OpenAPI description. Compare that field with the top entry here: if they disagree, one of them has not been updated, and the discrepancy is worth reporting.

    A practical routine for an integration: pin your code to the major prefix, read this log when you upgrade a client library or when responses change, and log the X-Request-Id header from any failed call so that a report to us can point to a specific request. The interactive explorer and the documentation page describe each endpoint, and you can send a question or a suspected undocumented change through the contact form.

    Versioning policy: The API uses URL-based major versioning (/v1/). Breaking changes will introduce a new prefix (/v2/). Additive changes (new fields, new endpoints) ship without a version bump. Every response carries an X-API-Version header that reads v1. The API does not currently send a Sunset or any other machine-readable deprecation header, and no endpoint has been deprecated. A removal would be announced in this log, so read it when you upgrade rather than waiting for a header.