API Overview

DanubeData provides a comprehensive RESTful API that allows you to programmatically manage all your infrastructure resources.

Interactive API Documentation

Our interactive API documentation is available at: /docs/api

You can access it directly by visiting:

• Production: https://danubedata.ro/docs/api

Our interactive API documentation provides:

• Complete endpoint reference for all API v1 operations
• Try It functionality - test endpoints directly in your browser
• Request/response examples for every endpoint
• Authentication testing with your API tokens
• OpenAPI 3.1 specification for integration tools

Quick Start

1. Get Your API Token

1. Open Security from the account menu, then the API tokens tab
2. Click Create token
3. Give it a descriptive name
4. Choose its project access: This project only (default) or All your projects
5. Select the appropriate permissions
6. Copy the token (shown only once)

2. Make Your First Request

curl -H "Authorization: Bearer YOUR_TOKEN_HERE" \
     https://danubedata.ro/api/v1/vps

Note: Ensure your API token has the appropriate permissions (e.g., vps:read) for the endpoints you want to access.

3. Explore the Documentation

Visit /docs/api to:

• Browse all available endpoints
• See detailed request/response formats
• Test endpoints with your token
• Download the OpenAPI specification

API Base URL

Production: https://danubedata.ro/api/v1

All API requests should be made to this base URL followed by the specific endpoint path.

Authentication

All API requests require authentication using a bearer token:

Authorization: Bearer YOUR_TOKEN_HERE

Learn more about authentication in the Authentication Guide.

Available Resources

The API provides access to manage:

Infrastructure

• VPS Instances - Create and manage virtual private servers
• Database Instances - PostgreSQL, MySQL, and MariaDB databases (with read replicas)
• Cache Instances - Redis, Valkey, and Dragonfly in-memory stores
• Queue Instances - managed RabbitMQ message brokers
• Parameter Groups - reusable database/cache configuration presets

Applications

• Serverless Containers - deploy and manage scale-to-zero containers
• Static Sites - managed static site hosting with custom domains

Storage

• Object Storage - S3-compatible storage buckets
• Access Keys - S3 credentials management

Networking

• Firewalls - Configure security rules
• SSH Keys - Manage access credentials

Operations

• Snapshots - Backup and restore operations
• Webhooks - Event notifications
• Metrics - Resource monitoring
• Support Tickets - Open, follow and answer support tickets (Support Tickets API)

Webhooks

A team's webhook sends events about its resources, such as servers and databases changing state, to one address you choose. Each request is signed with a secret (HMAC-SHA256) that you verify in your application. Set the address on Security, API tokens, in the Webhook card (?section=webhook opens it), or with PUT /api/v1/webhooks/config; the token needs webhook:write.

• The signing secret is made the first time you save an address, and it is shown once: in the console drawer, or in that API response. Save it then. Later saves don't return it, and GET /api/v1/webhooks/config only says has_secret. To get a new secret, regenerate it in the console or with POST /api/v1/webhooks/config/regenerate-secret; events are signed with the new one from then on.
• In the console, saving an address and regenerating the secret ask you to confirm it's you: the address decides where your events go, and the secret lets whoever holds it sign events your endpoint believes. An API token has no console session to confirm in.
• We email the account whenever the address changes or the secret is regenerated, from the console or the API. You can't turn these emails off.

Connection Endpoints

Database and cache instances expose two different ports, and mixing them up produces an endpoint that does not work:

Every instance has a private endpoint. Enabling public DNS adds a second, public one; it never replaces the private one.

Always use connection_host with connection_port. They are resolved together, so they can never disagree. DNS records cannot encode a port, so resolving a public hostname tells you nothing about which port to use — and the engine port on the public load balancer belongs to a different instance.

port keeps its original meaning and is unaffected by enabling public DNS, so existing automation that reads it for private-network connections is unchanged.

All of these fields are additive: nothing that existed before was renamed, removed, or given a new meaning, so existing integrations keep working unchanged.

Credentials, including the ready-made connection_info URL, come from:

• GET /api/v1/database/{id}/credentials, which needs the database:credentials token permission
• GET /api/v1/cache/{id}/connection-info (canonical), which needs cache:read. password and connection_info come back null unless the token also holds cache:credentials
• GET /api/v1/cache/{id}/credentials, a compatibility alias with the same payload and rate limit. It always includes the password, so it needs cache:credentials instead of cache:read

A connection URL contains the password, so every response that carries one (connection_info, amqp_url, including the one on GET for a database, cache or queue instance) leaves it null for a token without the credentials permission. See API Authentication.

Enabling public DNS (POST /api/v1/{database,cache}/{id}/dns) returns both dns_hostname and the allocated dns_port. Enabling publishes the resource to the internet and DELETE on the same route takes its endpoint away, so both need the resource's write permission, database:write or cache:write.

For databases, username/password are the superuser (postgres on PostgreSQL, root on MySQL/MariaDB) wherever the platform can resolve them, so these credentials can create roles, extensions and databases. database is the database that actually exists on the cluster — for a cluster created without an explicit name, that is the bootstrap database, not null.

Read endpoints (read replicas, and Redis Sentinel) are reachable on the private network only. They have no public load-balancer frontend, so they keep the engine port even while public DNS is enabled.

Rotating a database or cache password is not supported through the API.

Response Format

All API responses are returned in JSON format:

{
  "data": [...],
  "pagination": {
    "current_page": 1,
    "last_page": 5,
    "per_page": 15,
    "total": 72
  }
}

API Token Permissions

API tokens support granular, resource-specific permissions to control access to different parts of the API. When creating an API token, you can select which permissions to grant:

Available Scopes

More resources have abilities of their own, and some have extra ones such as :diagnostics. The full list is in Authentication.

Reading a password is a separate permission, never part of read: vps:credentials, database:credentials, cache:credentials, queue:credentials and app:credentials. None of them is a default. See Reading passwords.

One permission does not belong to a resource:

• account-limits:request lets a token ask for higher account limits and read the status of that request. It changes nothing by itself: the request waits for the project owner to approve it in the console. See Requesting with an API token.

Permission Mapping

• Read: Allows viewing/listing resources and their details
• Write: Allows creating, updating, and performing actions on resources
• Delete: Allows deleting resources

Default Permissions

New API tokens are created with basic read permissions by default:

• vps:read
• database:read
• cache:read
• storage:read
• static-site:read

These do not let a token read a password. Add a credentials permission for that.

Predefined Roles

• Editor: Read and write access to all resources
• Admin: Full access including delete permissions

Rate Limiting

API requests are rate-limited based on your account tier. Rate limit information is included in response headers:

• X-RateLimit-Limit - Maximum requests per window
• X-RateLimit-Remaining - Remaining requests
• X-RateLimit-Reset - Reset timestamp

Error Handling

The API uses standard HTTP status codes:

• 200 OK - Request succeeded
• 201 Created - Resource created successfully
• 204 No Content - Success with no response body
• 400 Bad Request - Invalid request parameters
• 401 Unauthorized - Missing or invalid authentication
• 403 Forbidden - Insufficient permissions or token scopes
• 404 Not Found - Resource not found
• 422 Unprocessable Entity - Validation error
• 429 Too Many Requests - Rate limit exceeded
• 500 Internal Server Error - Server error

Error responses include details:

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

SDK and Client Libraries

You can generate client SDKs in any language using our OpenAPI specification:

# Download the spec
curl https://danubedata.ro/docs/api.json > api-spec.json

# Generate a Python client
openapi-generator-cli generate \
  -i api-spec.json \
  -g python \
  -o danubedata-python-client

# Or JavaScript/TypeScript
openapi-generator-cli generate \
  -i api-spec.json \
  -g typescript-axios \
  -o danubedata-ts-client

Next Steps

To access the interactive API documentation, open a new browser tab and navigate to:

• /docs/api (or click your browser's address bar and type this path)

Or explore these guides:

• Authentication Guide - Learn about API tokens
• Rate Limits - Understand usage limits

Need Help?

• Visit /docs/api in your browser for detailed examples and interactive testing
• Contact our support team through the support portal
• Join our community Discord for developer discussions