Overview

The console is built on this API. There is no private back channel — every screen in the guides is calling the same endpoints documented here, so anything you can do in the interface you can do programmatically.
Base URL: https://api.stg.simnet.cloud Version prefix: every path begins /api/v1 Authentication: an OAuth 2.0 bearer token — see Authentication
Staging is the only deployed environment. The console is at app.stg.simnet.cloud, the API at api.stg.simnet.cloud, and these docs at docs.stg.simnet.cloud. There is no production host yet, so treat data here as impermanent.Note that the token audience is https://api.simnet.cloud — without the stg. It is an identifier, not an address, and it does not change between environments. See Authentication.
Read this before you plan an integration. The only credential available today is the access token from a signed-in console session — a personal, short-lived token carrying your full account access. There are no API keys, client secrets or service accounts yet, so nothing can authenticate unattended.Machine credentials with role-based access control are on the roadmap. Until then, the API is for scripting your own account and prototyping, not for building a service on. See Authentication.

What this reference covers

The customer-facing v1 surface: 453 operations across 33 areas, generated from the platform source so the paths, parameters and request schemas match what the service actually accepts.
Administrative endpoints — anything under /api/v1/admin, or gated on the simnet:admin permission — are not part of the public contract and are deliberately absent. So are the platform’s internal plumbing routes. If you find a path that isn’t in this reference, treat it as unsupported and subject to change without notice, however well it appears to work.

The shape of a request

Four things determine what a call does: the token says who you are, the region header says where the work happens, the path says what you are acting on, and the body says what to do.

Start here

Authentication

Getting a token, and what it is allowed to do.

Regions

Targeting the right region, and what happens when you don’t.

Conventions

Pagination, filtering, and the response envelopes.

Asynchronous work

Why a create returns a job id, and how to follow it.

Errors

The one error shape, and what each status actually means.

Duplicates and aliases

Where two paths do the same job, and which to prefer.

Your first call

List the zones available to you. It needs nothing but a token, so it is the quickest way to confirm your credentials work.
A 401 means the token is missing, expired, or issued for the wrong audience. A 403 with "You don't have an active account in any region yet" means the token is fine but your account has no region — activate one before going further.

A worked example: deploy an instance

Four calls: pick a zone, pick an offering, pick an image, then deploy.
1

Choose a zone

Keep the zone’s id.
2

Choose a compute offering

This is vCPU and memory. Keep the id.
3

Choose a template

Keep the id of an image whose zone matches step 1.
4

Deploy

The response carries a jobId. The instance exists before its network interface, volumes and any public address do, so poll the job rather than assuming the work is finished — see Asynchronous work.
Deploying into a zone that doesn’t offer your chosen template or offering fails with 422 and a detail explaining which. Fetch all three lists against the same region and zone, and that class of failure disappears.

Interactive reference

Every operation in the Endpoints section is generated from the platform source and rendered with a request builder, so you can send a real call from the page with your own token, and copy the result as cURL, Python, TypeScript, Go or a handful of others.
The spec is committed at api-reference/openapi.json. If you generate clients, build them from that file rather than scraping these pages.