API Reference

Automate every part of Deploynix — servers, sites, databases, deployments, backups, and more — with a versioned REST API and fine-grained Sanctum tokens.

Base URL & Versioning

Every endpoint is versioned under /api/v1:

https://{your-deploynix-domain}/api/v1

All requests must include an Accept: application/json header, and all request bodies must be JSON with Content-Type: application/json.

Authentication

The API uses Laravel Sanctum bearer tokens. Send the token on every request:

curl https://deploynix.io/api/v1/user \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json"

Missing or invalid tokens return 401 Unauthorized. Tokens that exist but lack the required ability return 403 Forbidden.

Creating API Tokens

From the Dashboard

1. Open Settings → API Tokens.
2. Click Create Token.
3. Name the token something descriptive (e.g. CI/CD pipeline).
4. Click Create.
5. The plain-text token is shown once only on the next screen. Copy it now — it's not stored anywhere you can retrieve it later.

The token list shows each token's name, creation date, and last-used timestamp. Click Delete on any row to revoke it; revocation takes effect immediately on the next request.

From the Login Endpoint

You can also exchange an email and password for a token by calling the login endpoint directly. Optionally pass an abilities array to scope the token to a subset of actions — if you omit abilities, the token receives every ability.

POST /api/v1/login
Content-Type: application/json

{
  "email": "you@example.com",
  "password": "your-password",
  "abilities": ["server:read", "site:read", "site:deploy"]
}

Managing Tokens via the API

• GET /api/v1/tokens — list your tokens.
• POST /api/v1/tokens — create a new token with a name and optional abilities.
• DELETE /api/v1/tokens/{id} — revoke a token.
• POST /api/v1/logout — revoke the token used for the request.

Token Abilities

Every ability follows a resource:action pattern. Assign only the abilities a token actually needs — CI deploy tokens should carry site:deploy, nothing else.

Endpoints

Below is a grouped list of the most commonly used endpoints. Every list endpoint is paginated, every detail endpoint returns a { "data": {...} } envelope, and every action endpoint returns a short status message plus the updated resource where applicable. Open the Swagger UI (link at the top) for exhaustive request/response schemas.

Servers

• GET /api/v1/servers — list servers (paginated).
• POST /api/v1/servers — create a server.
• GET /api/v1/servers/{server} — server details.
• PUT /api/v1/servers/{server} — update server metadata.
• DELETE /api/v1/servers/{server} — delete a server.
• GET /api/v1/servers/{server}/logs — server logs.
• POST /api/v1/servers/{server}/restart — reboot / restart services.
• POST /api/v1/servers/{server}/provision — rerun provisioning.

Sites

• GET /api/v1/servers/{server}/sites — list sites on a server.
• POST /api/v1/servers/{server}/sites — create a site.
• GET|PUT|DELETE /api/v1/servers/{server}/sites/{site} — read, update, delete.
• POST /api/v1/servers/{server}/sites/{site}/deploy — trigger a deployment.
• POST /api/v1/servers/{server}/sites/{site}/schedule-deploy — schedule a future deploy.
• POST /api/v1/servers/{server}/sites/{site}/cancel-scheduled-deploy — cancel a scheduled deploy.
• POST /api/v1/servers/{server}/sites/{site}/rollback — roll back to a previous release.
• POST /api/v1/servers/{server}/sites/{site}/suspend / resume — disable and re-enable traffic.
• POST /api/v1/servers/{server}/sites/{site}/enable-zero-downtime — turn on atomic releases.
• GET /api/v1/servers/{server}/sites/{site}/releases — list atomic releases.
• GET /api/v1/servers/{server}/sites/{site}/webhooks — webhook history (which pushes triggered which deploys).

Environment Variables & Site Sub-Resources

• /servers/{server}/sites/{site}/environment-variables — CRUD, plus POST .../pull to import from an existing .env.
• /servers/{server}/sites/{site}/queues — CRUD for queue workers, plus POST .../restart.
• /servers/{server}/sites/{site}/redirects — CRUD for Nginx redirects.
• /servers/{server}/sites/{site}/certificates — issue and revoke per-site SSL certificates.

Databases & Backups

• /servers/{server}/databases — list, create, read, delete databases.
• /servers/{server}/databases/{database}/users — database users.
• /servers/{server}/databases/{database}/backups — per-database backups.
• GET /api/v1/backups — organization-wide backup list (filterable with ?status= and ?type=).
• POST /api/v1/backups/application — create an application backup.
• GET /api/v1/backups/{backup}/download — download (rate-limited per hour).
• POST /api/v1/backups/{backup}/restore — restore from a backup.
• POST /api/v1/backups/{backup}/verify — verify backup integrity.

Server Resources

• /servers/{server}/crontabs — CRUD for cron jobs.
• /servers/{server}/daemons — CRUD for Supervisor daemons, plus POST .../restart.
• /servers/{server}/ssh-keys — CRUD for SSH keys.
• /servers/{server}/network-rules — CRUD for firewall rules.
• /servers/{server}/certificates — list and delete server-scoped certs.

Providers & Git

• GET /api/v1/providers — list supported cloud providers.
• /providers/credentials — add, list, and revoke cloud credentials.
• GET /api/v1/providers/{provider}/regions · /sizes · /images — provider metadata needed for server creation.
• /git-providers and /git-repositories — CRUD for Git connections and repositories, including POST .../setup-deploy-key and the enable-auto-deploy / disable-auto-deploy actions.

Account

• GET /api/v1/user — current authenticated user.
• POST /api/v1/login — exchange credentials for a token.
• POST /api/v1/logout — revoke the current token.

Response Format

Responses are Eloquent API Resources. Single-resource responses wrap payloads in a data object; list responses add pagination metadata.

Single Resource

{
  "data": {
    "id": "01HZ...",
    "name": "web-1",
    "provider": "digitalocean",
    "ip_address": "203.0.113.10",
    "ssh_user": "deploynix",
    "region": "fra1",
    "size": "s-2vcpu-2gb",
    "php_version": "8.3",
    "database_type": "mysql",
    "webserver": "nginx",
    "status": "active",
    "monitoring_enabled": true,
    "provisioned_at": "2026-04-16T10:30:00Z",
    "created_at": "2026-04-16T10:25:00Z",
    "updated_at": "2026-04-16T10:30:00Z",
    "sites_count": 2
  }
}

Paginated List

{
  "data": [ { ... }, { ... } ],
  "meta": {
    "current_page": 1,
    "from": 1,
    "last_page": 3,
    "per_page": 15,
    "to": 15,
    "total": 42
  },
  "links": {
    "first": ".../api/v1/servers?page=1",
    "last":  ".../api/v1/servers?page=3",
    "next":  ".../api/v1/servers?page=2",
    "prev":  null
  }
}

Timestamps are ISO 8601 in UTC. Resource IDs are ULID/UUID strings — don't assume integer auto-increment IDs.

Pagination

• ?page=1 — page number, default 1.
• ?per_page=15 — items per page, default 15, max 100.

A handful of endpoints support resource-specific filters: the organization-wide backups endpoint takes ?status=pending|in_progress|completed|failed|restored and ?type=application|database, for example. Generic sort / filter query parameters aren't currently supported — check the Swagger UI for per-endpoint filters.

Error Responses

A validation error (422) looks like this:

{
  "message": "The given data was invalid.",
  "errors": {
    "name": ["The name field is required."],
    "provider": ["The selected provider is invalid."]
  }
}

Rate Limiting

Protective limits apply on specific endpoints. These are in addition to any plan-level resource caps.

• Auth endpoints (POST /api/v1/login, /register) — 5 requests per minute.
• Token creation (POST /api/v1/tokens) — 10 requests per minute.
• Backup downloads (GET /api/v1/backups/{id}/download) — 10 per hour.
• General API — a baseline throttle of roughly 60 requests per minute applies across authenticated calls.

If you hit a plan-level cap (e.g. max_servers), the create endpoint returns 422 with an error message explaining the limit — not a 429.

Example — Deploy a Site

A minimal deploy trigger looks like this. The deployment runs asynchronously; poll the site endpoint (or watch the site's webhook history) to observe status.

curl -X POST \
  https://deploynix.io/api/v1/servers/{server}/sites/{site}/deploy \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json"

{
  "message": "Deployment started."
}

The token you use here needs the site:deploy ability — nothing else. That's the recommended scope for a CI/CD pipeline token.

Incoming Webhooks & Polling

Deploynix does not currently expose outgoing event webhooks you can subscribe to as an API consumer. For deployment status, poll the site endpoint or the webhooks sub-resource for recent deploy activity. Git-provider webhooks (GitHub / GitLab / Bitbucket) are incoming only — they land on the /webhooks/git-repository/{uuid} endpoint and drive auto-deploy.

Best Practices

• Scope every token minimally. A CI deploy token should have site:deploy and nothing else. A read-only dashboard should get *:read abilities only.
• One token per consumer. Separate tokens for your CI pipeline, your monitoring scripts, and your personal terminal — rotating one doesn't disrupt the others.
• Rotate on schedule or on incident. If a token might have leaked (checked into Git, shared in chat, laptop lost), delete it immediately from Settings → API Tokens and generate a new one.
• Never commit tokens. Put them in CI secret storage, your shell keychain, or a vault — not in .env files that end up on disk or in Git.