Changelog

Dates are when the change reached production. Additive changes do not bump the API version - see versioning.

2026-08-11

• docs.nextpki.com is live. Really this time: A record, Let’s Encrypt certificate, served from the same infrastructure as the other Datargo sites. A missing page returns a real 404, not the front page.

• OAuth 2.1 for assistants. A person can now let an assistant read their inventory without handing over an API token, and take that permission back from Connected applications in the console. Grants are read-only (certs:read), enforced as a database constraint and not as a default. New page: OAuth for assistants.

  What clients must bring: PKCE with S256, a resource parameter (RFC 8707), and a client_id that is an HTTPS URL to a Client ID Metadata Document. Dynamic Client Registration is not offered; it is deprecated in the MCP authorization specification, and earlier wording here that named it as the expected path was wrong.

• Reuse of a code or a rotated refresh token revokes the whole grant, following RFC 9700. Treat invalid_grant on refresh as “authorize again” rather than “retry”.

• An OAuth token for the MCP server is rejected by the API. The audience binding is real: the MCP server exchanges it (RFC 8693) for a short-lived API token instead of passing yours through, and every exchange is in the audit log.

• MCP server documentation corrected. It is implemented, not planned: seven tools, two transports, and certificate-derived strings marked as untrusted data in every tool response. Still not hosted, see what is not available yet.

2026-08-10

• Sensor licensing stated. The discovery sensor is source available under the PolyForm Internal Use License 1.0.0 with additional grants for review, self-build and operation on a client’s behalf. It is not open source, and earlier wording that implied otherwise has been corrected.

• This documentation set was created. The API reference is generated from the OpenAPI specification rather than maintained by hand, so it cannot drift from the service. It went live at docs.nextpki.com on 2026-08-11, not on this date: the entry that claimed so was wrong and has been corrected.

• Documented the discovery sensor: what it sends, what it never sends, the full configuration surface and troubleshooting.

• Documented the renewal state machine including every transition and failure mode, CA connectors and their spending guardrails, the supported authorities and the private PKI.

• Documented discovery sources and Certificate Transparency monitoring.

• Added task guides: monitor expiry, automate renewals, onboard a domain and pagination and caching.

• Added a tutorial that walks one renewal end to end, deployment recipes for nginx, Apache, Traefik and Kubernetes, and client library examples.

• Documented every returned field in certificate fields, including which are nullable.

• The OpenAPI specification is now downloadable at /openapi/nextpki-v1.yaml.

• Stated plainly that v1 returns no certificate bytes, so a renewal cannot be completed end to end through the API. Previously implied otherwise.

• Added reference material: enumerations, roles, security model, regions, certificate lifetimes, glossary and an explicit list of what is not available yet.

Earlier

v1 of the public API - token authentication with scopes, certificate and renewal-request reads, and renewal creation - has been available since Phase 2.5. It predates this changelog; entries start above.

Planned

Listed so you can plan, not as commitments with dates.

• MCP server, to connect NextPKI to Claude, ChatGPT, Slack and similar clients over the same API and the same scopes.
• Certificate-authority account sync, importing what you already manage in your CA accounts as an inventory source.
• Relay support for the sensor, so hosts without outbound access can report through an internal proxy.

If one of these is blocking you, saying so genuinely affects the order.