Skip to main content
Use this page to track changes to the Compute API that may affect your scripts, tools, or integrations. The endpoint reference shows the current API details. The changelog helps you understand what changed over time, especially when a request, response field, authentication behavior, or error response changes.
If you’re building against the API, check the changelog before updating your integration or debugging behavior that recently changed.

​
Current API version

The public Compute API uses versioned paths. Current version: https://api.hivenet.com/v1 Endpoint details, supported parameters, response schemas, and examples are available in the endpoint reference pages, such as List instances, Get instance, and Start instance.

​
How to read changelog entries

Each changelog entry should tell you:
  • What changed
  • Which endpoints or resources are affected
  • Whether you need to update your integration
  • Whether the change is backward-compatible
  • What to do next, if action is needed
Changes are grouped by date, with the newest updates first.

​
Change types

​
Latest changes

​

​
New endpoints: stop, SSH keys, regions, and presets

AddedNo action required. These are new endpoints and do not change existing behavior.
​

​
First version of API docs uploaded

No API changes have been added to this changelog yet.
When changes are published, entries will appear here with the affected endpoints and any required action.

​
What counts as a breaking change

A breaking change is a change that may require you to update code that already works. Examples include:
  • Removing an endpoint
  • Removing or renaming a response field
  • Removing a supported query parameter
  • Changing a field type
  • Changing the meaning of a status value
  • Requiring a new request body field for an existing endpoint
  • Changing authentication behavior in a way that affects existing tokens
<Danger> Do not assume undocumented fields will stay available. Build integrations against the fields documented in the API reference. </Danger>

​
What usually does not require action

Some changes should not break existing integrations. Examples include:
  • Adding a new optional response field
  • Adding a new optional query parameter
  • Improving descriptions or examples in the docs
  • Adding a new endpoint
  • Adding a new error message for a case that already failed
  • Fixing a bug without changing the documented request or response shape
<Note> Your code should ignore response fields it doesn’t use. This helps your integration keep working when new optional fields are added. </Note>

​
How to stay compatible

Use these habits when building against the API:
  • Use the versioned base URL shown in the docs.
  • Read endpoint details from the relevant endpoint reference page.
  • Handle unknown optional fields safely.
  • Check resource state before retrying actions.
  • Treat destructive actions, such as terminating an instance, with extra care.
  • Avoid relying on undocumented behavior.
  • Review this changelog when something changes unexpectedly.

​
When to check this page

Check the changelog when:
  • An integration starts behaving differently
  • You update code that calls the API
  • You add support for a new endpoint
  • You see a new response field or status
  • You receive a different error response than before
  • You’re preparing a script or integration for production use
For current endpoint details, use the endpoint reference pages: For safe request handling, see Handle errors and rate limits. For instance workflows, see Work with instances.