GalaxyGate Docs

Appearance

Authentication and tokens ​

Every API call needs a bearer token. You create an API token in the panel, copy it once, and send it on every request as an Authorization: Bearer <token> header. This is the intended path for scripts, automation, and CI, and you give each token only the permissions it needs.

There is a POST /v1/login endpoint, but it is the browser sign-in flow, not the way scripts authenticate. It takes an email and password (plus an MFA code if you have MFA enrolled), sends a login-notification email, and returns a short-lived one-day SESSION token. Automation should not call it. Mint a long-lived API token in the panel instead and use that as the bearer.

Create an API token in the panel ​

Sign in to dash.galaxygate.net and open Security > Tokens. Create a token there, give it a name, choose its expiry, and set the exact permissions it holds. The plaintext value is shown once at creation, so copy it right then and store it somewhere safe.

Save the plaintext now

We store only a hash of every token. The plaintext is shown exactly once, at creation. If you lose it you cannot retrieve it. You create a new token and delete the old one.

Use the token ​

Put the token in the Authorization header on every request, as Bearer <token>. A quick way to confirm your token works is to fetch the account it belongs to:

bash
curl "https://api.galaxygate.net/v1/users/@me" \
  -H "Authorization: Bearer $GALAXYGATE_TOKEN"

That returns the authenticated user, for example:

json
{
  "id": "1524141516547502080",
  "name": "panel test 4",
  "email": "you@example.com",
  "flags": ["EMAIL_VERIFIED"]
}

The same header works on every other endpoint:

bash
curl "https://api.galaxygate.net/v1/instances/$INSTANCE_ID" \
  -H "Authorization: Bearer $GALAXYGATE_TOKEN"

Create a token through the API ​

You can also mint a user-scope API token with POST /v1/tokens (an alias for POST /v1/users/@me/tokens). One important limit: only a browser login session can create tokens. A request authenticated with an API token gets 403 Only login sessions can create tokens. In practice this means you create API tokens in the panel; the endpoint below is what the panel calls on your behalf.

Supply a name, an expires timestamp, and a grants map:

bash
curl -X POST "https://api.galaxygate.net/v1/tokens" \
  -H "Authorization: Bearer $GALAXYGATE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "deploy-bot",
    "expires": "2026-10-01T00:00:00Z",
    "grants": {
      "INSTANCE": "WRITE",
      "IMAGE": "READ"
    }
  }'

The response carries the plaintext code exactly once. Save it. Every later read of the token shows only its metadata, never the code:

json
{
  "id": "1527462360147333120",
  "name": "deploy-bot",
  "created": "2026-07-16T23:50:05Z",
  "expires": "2026-10-01T00:00:00Z",
  "origin": "API",
  "subject": "USER",
  "subject_id": "1524141516547502080",
  "workspace_id": null,
  "grants": { "INSTANCE": "WRITE", "IMAGE": "READ" },
  "code": "gga.7e2dd03f76c34086b73681bd94cc841c"
}

Request fields ​

  • name (required): a label for the token, 4 to 48 characters.
  • expires (required): an ISO 8601 timestamp. It must be at least 7 days and at most 365 days from now. Outside that window the request fails with expires must be between <min> and <max>.
  • grants (required): a resource-kind to permission map. It may not be empty.

The grants map ​

grants maps a resource kind to a permission level. Each value is one of three levels:

  • NONE: no access. A kind set to NONE is dropped, so it is the same as leaving the kind out.
  • READ: read only.
  • WRITE: read and write.

The valid resource-kind keys are WORKSPACE, INSTANCE, DEDIBOX, APP, IMAGE, NET_BALANCER, FLOATING_IP, and DISK. Any other key is rejected, so a grants map with a kind like TEMPLATE or SNAPSHOT fails validation.

Grant the least a token needs. A token that only powers instances on and off needs INSTANCE set to WRITE and nothing else. Anything you leave out defaults to no access, so a short grants map is a safe grants map.

Manage and revoke tokens ​

  • List a user's tokens: GET /v1/users/{uid}/tokens. Use @me for {uid} to list your own.
  • Fetch one token's metadata: GET /v1/tokens/{id}.
  • Delete (revoke) a token: DELETE /v1/tokens/{id}. It returns 202 Accepted, and the token stops working immediately.

Rotate a token by creating a new one, updating your scripts to use it, then deleting the old one. Because the plaintext cannot be recovered, treat a leaked token as compromised and delete it immediately.

There is no way to refresh an API token to extend its life. A POST /v1/tokens/refresh endpoint exists, but it only extends a browser login SESSION token, and only in the last 6 hours of that token's one-day lifetime. It does not apply to the API tokens you use for automation. To keep automation running past a token's expiry, mint a new token and swap it in.

Next step ​

You have a token. Use it to create your first server.

Create a server