---
title: "API v1 changelog"
description: "Track source-verifiable API documentation snapshots separately from product releases and SDK versions."
slug: "/docs/v1/api/api-changelog"
section: "API reference"
order: 44
audience: "all"
level: "intermediate"
last_updated: "2026-10-17"
version: "v1"
related: ["/docs/v1/start/authentication", "/docs/v1/api/conventions"]
draft: false
---
This changelog records verified contract snapshots; documentation publication is not a new payment or licensing release.

## What you will learn
- Distinguish API contract documentation from SDK/[product](/docs/v1/start/glossary#product) release versions.
- Find verified changes without invented historic dates.

## Prerequisites
- Read [API conventions](/docs/v1/api/conventions).
- Complete [the Sandbox quickstart](/docs/v1/start/quickstart).

## 2026-10-17: complete v1 reference snapshot
The current source registers11 licensing operations: public-key retrieval, creation, [activation](/docs/v1/start/glossary#activation), validation, deactivation, scoped retrieval, revoke, suspend, restore, renew and reset-devices. The reference records25 response/request components, exact credentials/[scopes](/docs/v1/start/glossary#scope),69 per-operation error examples and the documented current headers. This entry describes the P6 authoring snapshot, not an API behavior change.
The local contract suite captures all 11 successes and22 API/router error identifiers. Two creation-idempotency defects remain disclosed rather than silently corrected. SDK versions are separate from API v1; the currently audited official packages identify version 1.0.0.
No earlier API release date is reconstructed from undocumented assumptions. An older file timestamp is not evidence that a behavior was deployed on that date.

## Change entry format
| Field | What to record |
| --- | --- |
| Date | Actual verified publication/deployment date in UTC |
| Affected contract | Version, operation, fields, statuses, headers or error codes |
| Compatibility | Additive, documentation correction or breaking; explain why |
| Migration | Required client change, test vectors and upgrade guide |
| Evidence | Source commit and tested Sandbox response without secrets |
| Announcement | Actual notification channel/notice dates, not a presumed SLA |
A future entry must distinguish documentation correction from a changed server contract. Do not list a proposed [feature](/docs/v1/start/glossary#feature) as an available operation.

## Known limitations
The current API has no historical signing-key ring, no list/[customer](/docs/v1/start/glossary#customer)/product CRUD surface and no universal mutation replay. Existing canonicalization/cache and idempotency issues remain visible in the security/reference guides. This page does not close those product findings.

## Expected result
You can identify the documented v1 snapshot without confusing it with an SDK upgrade or an unverified production release.

## Common mistakes
- Treating this reference date as the original API launch date.
- Calling a documentation correction a payment/security product fix.

## Security notes
Changelog examples and evidence must exclude secrets, customer data and internal URLs. A change entry is not a compliance or uptime claim.

## Troubleshooting
| Symptom | Cause | Action |
| --- | --- | --- |
| Client behavior differs | Different package/server revision or documented limitation | Compare operation/schema and preserve [request ID](/docs/v1/start/glossary#request-id) |
| No historic entry | No verifiable release evidence | Ask support rather than infer a date |

## Next steps
Review [the endpoint reference](/docs/v1/api/public-key) and [signature verification](/docs/v1/security/verify-ed25519).

## Related
- [Authentication](/docs/v1/start/authentication)
- [API conventions](/docs/v1/api/conventions)
- [License lifecycle](/docs/v1/start/license-lifecycle)