The API accepts the same signed-in user token the console uses. Programmatic credentials with role-based access are on the roadmap and not available yet.
Today there is exactly one kind of token: the user access token issued when you sign in to the console. The API and the console accept the same credential, because the console is built on this API.
There are no programmatic credentials yet. Simnet does not issue API keys, client secrets, service accounts or scoped tokens, and there is no POST /api/v1/login on this API to exchange anything for a token.So an integration cannot authenticate on its own behalf today. It can only reuse a token belonging to a signed-in person, with that person’s full access.Machine credentials with role-based access control are on the roadmap. Until they land, treat the API as a way to script your own account rather than a way to build an unattended integration.
The console’s own Auth0 client is a public client — it holds no secret, because a browser cannot keep one. There is no secret to request from support, and anyone offering you one has misunderstood the setup.
Sign in to the console, then take the access token from your browser session. It is a personal, short-lived credential.
1
Sign in to the console
Sign in normally at your Simnet console URL.
2
Copy the access token from the session
The console keeps its Auth0 token in browser storage. Open developer tools → Application → Local Storage, find the Auth0 entry for your console origin, and copy the access_token value.Alternatively, open the Network tab, trigger any action, and copy the Authorization header from an outgoing /api/v1/... request — minus the Bearer prefix.
It is you. It carries your full account access, and anything done with it is attributed to you.
It expires, in minutes to hours depending on tenant configuration. When it does, sign in again and copy a fresh one — there is no refresh you can perform from outside the browser.
It cannot be revoked individually. Signing out does not invalidate a token already copied; it remains usable until it expires.
It is not a supported integration path. Anything you build on it will need rewriting when real credentials arrive.
Use it to explore the API, to script one-off work against your own account, and to prototype. Do not embed it in a service, a CI pipeline, or anything another person operates.
Three things must hold or the request is rejected with 401:
Check
Meaning
Signature
The token is signed by the identity provider’s current key.
Issuer
It came from the issuer configured for this deployment.
Audience
It was minted for the Simnet API, not for another application.
The audience check is the one that catches people out. An identity token, or a token issued for a different application, is refused here even though it is perfectly valid where it came from. If a fresh-looking token gets a 401, inspect its aud claim first — paste it into any JWT decoder and confirm it names the Simnet API.
An identifier the identity provider stamps into the token’s aud claim. Nothing is ever sent here.
Base URL
https://api.stg.simnet.cloud
The address you actually call.
Do not “correct” the audience to match the host you are calling. An audience of https://api.stg.simnet.cloud produces a token the API refuses with 401, because the audience is a fixed identifier rather than a location — it stays the same in every environment, while the base URL changes.
Your token’s subject is matched to a Simnet user, and that user’s account in the target region is what the operation runs against.Three things fail the request before it reaches the resource:
Condition
Result
The token’s subject has no matching Simnet user
403 · User not found in database
The user exists but is not active
403 · User account is SUSPENDED (or the relevant status)
The user has no usable account in any region
403 · You don't have an active account in any region yet
See Regions for how the region is chosen and what to do about the last one.
Authorization is whole-account: a valid token for an active user can reach every endpoint in this reference. There is no way to issue a token that is allowed to list instances but not delete them.
The platform reads a permissions claim on the token, and a single permission — simnet:admin — gates the administrative endpoints. Those are not part of the public contract and are not documented here.For customer-facing endpoints no permission is required beyond being an authenticated, active user. That is precisely the gap the roadmap’s RBAC work closes: scoped credentials so an integration can be granted only what it needs.
Because access is all-or-nothing today, a token copied from a console session can do anything you can do — including delete instances and release addresses. Treat it with the same care as your password, and prefer read-only exploration until you are confident in a script.
An X-Tenant-Context header exists, carrying a membership identifier, and the console uses it for organization-scoped screens like members and invitations.
Do not send X-Tenant-Context on resource endpoints. Region routing for organization context is not implemented yet, and the API fails closed rather than guessing: any instance, volume, network or VPC call carrying that header is refused with
{ "message": "Access denied", "detail": "Region-scoped tenant operations are unavailable until the tenant has an owner-qualified region account."}
Send it only on the /api/v1/tenants/** and invitation endpoints. Everything else operates on your personal account.
HTTPS only, and never put a token in a query string — it lands in access logs, browser history and proxy logs. The Authorization header is the only supported place for it.Do not commit a token to a repository or paste one into a ticket. Since individual tokens cannot be revoked, a leaked token is valid until it expires and there is nothing you can do to shorten that.
