Release notes explain what the published docs cover for the Kiyotaka Data API: REST (/v1/points), WebSockets (book and nonbook), authentication, limits, errors, and the per–data-type reference pages. They are written for developers integrating the API—not for internal release engineering detail.
What we publish
| Artifact | Purpose |
|---|---|
| Release Notes | Version-by-version documentation history: scope of the documented API, operational behavior, and any contract or docs-only callouts. |
New entries appear newest first. Each major section uses short Added / Documented style bullets so you can see what became officially described in that release.
Versioning
Documentation releases use semantic-style versions (MAJOR.MINOR.PATCH) as documentation product versions:
- MAJOR — Baseline or reset of the documented public contract narrative (for example first documented alignment with REST
/v1). A future HTTP breaking change would correspond to a new API path or version line and would be reflected here together with migration guidance. - MINOR — New documented endpoints, parameters, data types, or materially expanded guides without redefining the baseline contract story.
- PATCH — Clarifications, corrections, and small additive documentation fixes.
The REST URL prefix v1 (https://api.kiyotaka.ai/v1/...) is the implementation anchor that v1.0.0 docs describe. WebSocket subscription payloads may carry their own version fields where documented (for example in subscribe examples).
Integration checklist
When you adopt or refresh an integration against the Data API:
- Read the Latest release callout on Release Notes.
- Confirm authentication (Authentication) and tier limits (Rate limits) match your plan.
- For REST, standardize on
GET /v1/pointsand theseries/pointsshape (Introduction). - For WebSocket, split book vs nonbook connections as needed and pick a region (WebSocket overview).
- Handle errors and backoff consistently (Errors).