The Vultr API v2 is a set of HTTP endpoints that adhere to RESTful design principles and CRUD actions with predictable URIs. It uses standard HTTP response codes, authentication, and verbs. The API has consistent and well-formed JSON requests and responses with cursor-based pagination to simplify list handling. Error messages are descriptive and easy to understand. All functions of the Vultr customer portal are accessible via the API, enabling you to script complex unattended scenarios with any tool fluent in HTTP.

Communicate with the API by making an HTTP request at the correct endpoint. The chosen method determines the action taken.

Rate Limit: Vultr safeguards the API against bursts of incoming traffic based on the request's IP address to ensure stability for all users. If your application sends more than 30 requests per second, the API may return HTTP status code 429. If you do exceed the rate limit, we will send back a Retry-After header with how many seconds to wait before trying again.

We use standard HTTP response codes to show the success or failure of requests. Response codes in the 2xx range indicate success, while codes in the 4xx range indicate an error, such as an authorization failure or a malformed request. All 4xx errors will return a JSON response object with an error attribute explaining the error. Codes in the 5xx range indicate a server-side problem preventing Vultr from fulfilling your request.

Many API calls will return a meta object with paging information.

Definitions

How to use Paging

If your result list total exceeds the default cursor size (the default depends on the route, but is usually 100 records) or the value defined by the per_page query param (when present) the response will be returned to you paginated.

Paging Example

These examples have abbreviated attributes and sample values. Your actual cursor values will be encoded alphanumeric strings.

To return a page with the first two plans in the List:

curl "https://api.vultr.com/v2/plans?per_page=2" \
  -X GET \
  -H "Authorization: Bearer ${VULTR_API_KEY}"

The API returns an object similar to this:

{
    "plans": [
        {
            "id": "vc2-1c-2gb",
            "vcpu_count": 1,
            "ram": 2048,
            "locations": []
        },
        {
            "id": "vc2-24c-97gb",
            "vcpu_count": 24,
            "ram": 98304,
            "locations": []
        }
    ],
    "meta": {
        "total": 19,
        "links": {
            "next": "WxYzExampleNext",
            "prev": "WxYzExamplePrev"
        }
    }
}

The object contains two plans. The total attribute indicates that 19 plans are available in the List. To navigate forward in the list, use the next value (WxYzExampleNext in this example) as your cursor query parameter.

curl "https://api.vultr.com/v2/plans?per_page=2&cursor=WxYzExampleNext" \
  -X GET
  -H "Authorization: Bearer ${VULTR_API_KEY}"

Likewise, you can use the example prev value WxYzExamplePrev to navigate backward.

You can pass information to the API with three different types of parameters.

Path parameters

Some API calls require variable parameters as part of the endpoint path. For example, to retrieve information about a user, supply the user-id in the endpoint.

curl "https://api.vultr.com/v2/users/{user-id}" \
  -X GET \
  -H "Authorization: Bearer ${VULTR_API_KEY}"

Query parameters

Some API calls allow filtering with query parameters. For example, the /v2/plans endpoint supports a type query parameter. Setting type=vhf instructs the API only to return High Frequency Compute plans in the list. You'll find more specifics about valid filters in the endpoint documentation below.

curl "https://api.vultr.com/v2/plans?type=vhf" \
  -X GET \
  -H "Authorization: Bearer ${VULTR_API_KEY}"

You can also combine filtering with paging. Use the per_page parameter to retreive a subset of vhf plans.

curl "https://api.vultr.com/v2/plans?type=vhf&per_page=2" \
  -X GET \
  -H "Authorization: Bearer ${VULTR_API_KEY}"

Request Body

PUT, POST, and PATCH methods may include an object in the request body with a content type of application/json. The documentation for each endpoint below has more information about the expected object.

The examples in this documentation use curl, a command-line HTTP client, to demonstrate useage. Linux and macOS computers usually have curl installed by default, and it's available for download on all popular platforms including Windows.

Each example is split across multiple lines with the \ character, which is compatible with a bash terminal. A typical example looks like this:

curl "https://api.vultr.com/v2/domains" \
  -X POST \
  -H "Authorization: Bearer ${VULTR_API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "domain" : "example.com",
    "ip" : "192.0.2.123"
  }'

• The -X parameter sets the request method. For consistency, we show the method on all examples, even though it's not explicitly required for GET methods.
• The -H lines set required HTTP headers. These examples are formatted to expand the VULTR_API_KEY environment variable for your convenience.
• Examples that require a JSON object in the request body pass the required data via the --data parameter.

All values in this guide are examples. Do not rely on the OS or Plan IDs listed in this guide; use the appropriate endpoint to retreive values before creating resources.

Read-only information about your user account and billing information.

One-Click and Marketplace Applications are ready-to-run with minimal configuration. We have an extensive documentation library for our Applications.

There are two types of Applications: marketplace and one-click. This is denoted by the type field in the Application object. Applications with type of marketplace can be deployed by using the image_id while Applications with type of one-click should use the id.

The Vultr API v2 uses API keys for authentication. These methods enable you to manage your API keys without having to access the customer portal. Keys are only accessible for the currently authenticated user. To manage keys for other users, see the "Users" section.

A backup is a scheduled, automatic, point-in-time image of an instance. We do not stop the instance when taking a backup. Booting from a backup is similar to rebooting after a non-graceful restart. Snapshots are physically the same as backups, but snapshots are manual while backups run automatically on a schedule. Backups can be converted into snapshots. See our Automatic Backup FAQ for more information.

Bare Metal servers give you access to the underlying physical hardware in a single-tenant environment without a virtualization layer.