​
Overview

The Miget API allows you to programmatically manage your applications, databases, and infrastructure on the Miget platform.

​
Base URL

All API requests should be made to:

​
Authentication

Miget API supports three authentication methods. A token that acts as you, in any workspace you belong to. Create one under Account settings → API Tokens, then send it in the Authorization header:
The token value is shown once, when it is created. Store it then — it cannot be retrieved afterwards, only replaced.
  • It carries whatever your role grants, in whichever workspace the request targets.
  • Expiry is optional, which is what makes these convenient for CI/CD.
  • Up to 10 active tokens per user.
A user token stops working when you lose access to a workspace, and carries your permissions wherever it is used. For automation that has to outlive one person’s membership, use a workspace token instead.

​
Option 2: Workspace API Tokens

A token that acts for the workspace rather than for a person. Create one under Workspace → Settings → Developers → API Tokens. It is sent exactly like a user token:
  • It carries its own permission list and its own project list, both fixed at creation and editable afterwards.
  • Expiry is optional: give it a date, capped at 12 months out, or set it to Never and the token runs until it is revoked.
  • Up to 20 active tokens per workspace, counted separately from anyone’s personal budget.
A workspace token is self-describing: what it can do is exactly its own two lists. Neither the role of the person who created it nor workspace ownership widens it — an owner can create a token that only reads applications, and a token created by a collaborator can carry apps:manage.
Three restrictions follow from acting for a workspace rather than for a person:
  • It is pinned to its workspace. An X-Workspace-Id header naming a different workspace is rejected with 403 rather than ignored.
  • It cannot reach a personal account. /api/v1/users/me and everything under it — SSH keys, credits — answers 403.
  • It cannot administer the workspace. Members, roles, billing, stored credentials and integrations are never grantable to a token, which is what stops a token from creating another token.
A workspace token is revoked automatically when the member who created it is removed or suspended. Its name, permissions, projects and expiry can be changed at any time; the change applies immediately to the already-issued token and lands on the workspace activity feed as a before/after diff.

​
Option 3: Session Tokens (Basic Auth)

Use your email and password to obtain session tokens via the /auth/sign_in endpoint.
This returns an access_token and refresh_token. The access token expires and needs to be refreshed periodically using the /auth/refresh_token endpoint.

​
Workspace Context

This applies to Option 1 and Option 3. A workspace token (Option 2) is bound to its workspace at creation and cannot be pointed at another one — an X-Workspace-Id header naming a different workspace is rejected with 403. Authenticated as a user, requests operate on your default workspace (the last workspace you were active in). To target a specific one, include the X-Workspace-Id header with the workspace UUID:
You can find your workspace UUID in the Miget dashboard URL or via the API.

​
Response Format

All responses are returned in JSON format. Successful responses typically include the requested data, while errors include an error field with a descriptive message.

​
Success Response

​
Error Response