GalaxyGate Docs

Appearance

Overview ​

Everything you can do in the control panel, you can do over HTTP. The API is how you script server creation, wire us into your own tools, and manage fleets of instances. This section walks the core loop most people need: create a server, control its power, and run code on it at boot.

Base URL ​

https://api.galaxygate.net/v1

Every endpoint on this site is relative to that base. Requests and responses are JSON.

Authentication ​

Every call carries a bearer token in the Authorization header:

Authorization: Bearer <your-token>

There are no exceptions. A request with no Authorization header is rejected with 403 Forbidden. A request that carries a bearer token the server does not recognize (invalid or expired) is rejected with 401 Unauthorized. In both cases the response body is empty and the reason is returned in an X-Message header. You create an API token in the panel under Security and send it on every request. See Authentication and tokens to mint one.

Workspaces ​

Most resources belong to a workspace. Your instances, SSH keys, and tokens all live inside one. Workspace-scoped endpoints include the workspace ID in the path as {wid}, for example:

POST /v1/workspaces/{wid}/instances

You can find your workspace ID in the panel, or by listing your workspaces through the API. Endpoints that act on a single instance are addressed by instance ID instead, for example GET /v1/instances/{id}.

Asynchronous operations ​

Creating, deleting, and power-cycling an instance do not finish instantly. These endpoints return a workflow object right away and continue the work in the background. The workflow object carries an id, a name (the workflow type, for example instance.power), and a state that starts at QUEUED and moves through RUNNING to COMPLETED (or FAILED, ABORTED, TIMED_OUT). Power actions return 202 Accepted with this object.

There are two ways to watch the result. You can poll the workflow directly at GET /v1/workflows/{wfid}, or list the workflows for an instance at GET /v1/workspaces/{wid}/instances/{iid}/workflows, and wait for its state to reach COMPLETED. You can also poll the affected resource, for example GET /v1/instances/{id}, and watch its own state field settle (an instance moves through PENDING to AVAILABLE). Wherever a call behaves this way, the page for it says so.

Rate limiting ​

The API is rate limited per client IP. The general limit is 120 requests per 60 second window; a handful of sensitive endpoints (login, register, password reset, email verification, and account lock) are held to much tighter windows. When you exceed a limit the API responds with 429 Too Many Requests and an X-Message header. If you are bulk-creating or polling in a tight loop and start getting 429, back off and retry after a delay rather than hammering the endpoint. A short exponential backoff is the simplest approach that works.

What is in this section ​

A larger surface exists

This section covers the operations most people use day to day. The panel is backed by a much larger REST surface: disks, snapshots, backups, IPs, firewall rules, and more. The patterns here (bearer auth, workspace scoping, workflow responses, and backing off on 429) apply across all of it.