digitalocean-openapi-js

openapi: 3.0.0 info: title: DigitalOcean API version: '2.0' description: > # Introduction The DigitalOcean API allows you to manage Droplets and resources within the DigitalOcean cloud in a simple, programmatic way using conventional HTTP requests. All of the functionality that you are familiar with in the DigitalOcean control panel is also available through the API, allowing you to script the complex actions that your situation requires. The API documentation will start with a general overview about the design and technology that has been implemented, followed by reference information about specific endpoints. ## Requests Any tool that is fluent in HTTP can communicate with the API simply by requesting the correct URI. Requests should be made using the HTTPS protocol so that traffic is encrypted. The interface responds to different methods depending on the action required. |Method|Usage| |--- |--- | |GET|For simple retrieval of information about your account, Droplets, or environment, you should use the GET method. The information you request will be returned to you as a JSON object. The attributes defined by the JSON object can be used to form additional requests. Any request using the GET method is read-only and will not affect any of the objects you are querying.| |DELETE|To destroy a resource and remove it from your account and environment, the DELETE method should be used. This will remove the specified object if it is found. If it is not found, the operation will return a response indicating that the object was not found. This idempotency means that you do not have to check for a resource's availability prior to issuing a delete command, the final state will be the same regardless of its existence.| |PUT|To update the information about a resource in your account, the PUT method is available. Like the DELETE Method, the PUT method is idempotent. It sets the state of the target using the provided values, regardless of their current values. Requests using the PUT method do not need to check the current attributes of the object.| |PATCH|Some resources support partial modification. In these cases, the PATCH method is available. Unlike PUT which generally requires a complete representation of a resource, a PATCH request is a set of instructions on how to modify a resource updating only specific attributes.| |POST|To create a new object, your request should specify the POST method. The POST request includes all of the attributes necessary to create a new object. When you wish to create a new object, send a POST request to the target endpoint.| |HEAD|Finally, to retrieve metadata information, you should use the HEAD method to get the headers. This returns only the header of what would be returned with an associated GET request. Response headers contain some useful information about your API access and the results that are available for your request. For instance, the headers contain your current rate-limit value and the amount of time available until the limit resets. It also contains metrics about the total number of objects found, pagination information, and the total content length.| ## HTTP Statuses Along with the HTTP methods that the API responds to, it will also return standard HTTP statuses, including error codes. In the event of a problem, the status will contain the error code, while the body of the response will usually contain additional information about the problem that was encountered. In general, if the status returned is in the 200 range, it indicates that the request was fulfilled successfully and that no error was encountered. Return codes in the 400 range typically indicate that there was an issue with the request that was sent. Among other things, this could mean that you did not authenticate correctly, that you are requesting an action that you do not have authorization for, that the object you are requesting does not exist, or that your request is malformed. If you receive a status in the 500 range, this generally indicates a server-side problem. This means that we are having an issue on our end and cannot fulfill your request currently. 400 and 500 level error responses will include a JSON object in their body, including the following attributes: |Name|Type|Description| |--- |--- |--- | |id|string|A short identifier corresponding to the HTTP status code returned. For example, the ID for a response returning a 404 status code would be "not_found."| |message|string|A message providing additional information about the error, including details to help resolve it when possible.| |request_id|string|Optionally, some endpoints may include a request ID that should be provided when reporting bugs or opening support tickets to help identify the issue.| ### Example Error Response ``` HTTP/1.1 403 Forbidden { "id": "forbidden", "message": "You do not have access for the attempted action." } ``` ## Responses When a request is successful, a response body will typically be sent back in the form of a JSON object. An exception to this is when a DELETE request is processed, which will result in a successful HTTP 204 status and an empty response body. Inside of this JSON object, the resource root that was the target of the request will be set as the key. This will be the singular form of the word if the request operated on a single object, and the plural form of the word if a collection was processed. For example, if you send a GET request to `/v2/droplets/$DROPLET_ID` you will get back an object with a key called "`droplet`". However, if you send the GET request to the general collection at `/v2/droplets`, you will get back an object with a key called "`droplets`". The value of these keys will generally be a JSON object for a request on a single object and an array of objects for a request on a collection of objects. ### Response for a Single Object ```json { "droplet": { "name": "example.com" . . . } } ``` ### Response for an Object Collection ```json { "droplets": [ { "name": "example.com" . . . }, { "name": "second.com" . . . } ] } ``` ## Meta In addition to the main resource root, the response may also contain a `meta` object. This object contains information about the response itself. The `meta` object contains a `total` key that is set to the total number of objects returned by the request. This has implications on the `links` object and pagination. The `meta` object will only be displayed when it has a value. Currently, the `meta` object will have a value when a request is made on a collection (like `droplets` or `domains`). ### Sample Meta Object ```json { . . . "meta": { "total": 43 } . . . } ``` ## Links & Pagination The `links` object is returned as part of the response body when pagination is enabled. By default, 20 objects are returned per page. If the response contains 20 objects or fewer, no `links` object will be returned. If the response contains more than 20 objects, the first 20 will be returned along with the `links` object. You can request a different pagination limit or force pagination by appending `?per_page=` to the request with the number of items you would like per page. For instance, to show only two results per page, you could add `?per_page=2` to the end of your query. The maximum number of results per page is 200. The `links` object contains a `pages` object. The `pages` object, in turn, contains keys indicating the relationship of additional pages. The values of these are the URLs of the associated pages. The keys will be one of the following: * **first**: The URI of the first page of results. * **prev**: The URI of the previous sequential page of results. * **next**: The URI of the next sequential page of results. * **last**: The URI of the last page of results. The `pages` object will only include the links that make sense. So for the first page of results, no `first` or `prev` links will ever be set. This convention holds true in other situations where a link would not make sense. ### Sample Links Object ```json { . . . "links": { "pages": { "last": "https://api.digitalocean.com/v2/images?page=2", "next": "https://api.digitalocean.com/v2/images?page=2" } } . . . } ``` ## Rate Limit Requests through the API are rate limited per OAuth token. Current rate limits: * 5,000 requests per hour * 250 requests per minute (5% of the hourly total) Once you exceed either limit, you will be rate limited until the next cycle starts. Space out any requests that you would otherwise issue in bursts for the best results. The rate limiting information is contained within the response headers of each request. The relevant headers are: * **ratelimit-limit**: The number of requests that can be made per hour. * **ratelimit-remaining**: The number of requests that remain before you hit your request limit. See the information below for how the request limits expire. * **ratelimit-reset**: This represents the time when the oldest request will expire. The value is given in [Unix epoch time](http://en.wikipedia.org/wiki/Unix_time). See below for more information about how request limits expire. More rate limiting information is returned only within burst limit error response headers: * **retry-after**: The number of seconds to wait before making another request when rate limited. As long as the `ratelimit-remaining` count is above zero, you will be able to make additional requests. The way that a request expires and is removed from the current limit count is important to understand. Rather than counting all of the requests for an hour and resetting the `ratelimit-remaining` value at the end of the hour, each request instead has its own timer. This means that each request contributes toward the `ratelimit-remaining` count for one complete hour after the request is made. When that request's timer runs out, it is no longer counted towards the request limit. This has implications on the meaning of the `ratelimit-reset` header as well. Because the entire rate limit is not reset at one time, the value of this header is set to the time when the _oldest_ request will expire. Keep this in mind if you see your `ratelimit-reset` value change, but not move an entire hour into the future. If the `ratelimit-remaining` reaches zero, subsequent requests will receive a 429 error code until the request reset has been reached. `ratelimit-remaining` reaching zero can also indicate that the "burst limit" of 250 requests per minute limit was met, even if the 5,000 requests per hour limit was not. In this case, the 429 error response will include a `retry-after` header to indicate how long to wait (in seconds) until the request may be retried. You can see the format of the response in the examples. **Note:** The following endpoints have special rate limit requirements that are independent of the limits defined above. * Only 12 `POST` requests to the `/v2/floating_ips` endpoint to create Floating IPs can be made per 60 seconds. * Only 10 `GET` requests to the `/v2/account/keys` endpoint to list SSH keys can be made per 60 seconds. * Only 5 requests to any and all `v2/cdn/endpoints` can be made per 10 seconds. This includes `v2/cdn/endpoints`, `v2/cdn/endpoints/$ENDPOINT_ID`, and `v2/cdn/endpoints/$ENDPOINT_ID/cache`. * Only 50 strings within the `files` json struct in the `v2/cdn/endpoints/$ENDPOINT_ID/cache` [payload](https://docs.digitalocean.com/reference/api/api-reference/#operation/cdn_purge_cache) can be requested every 20 seconds. ### Sample Rate Limit Headers ``` . . . ratelimit-limit: 1200 ratelimit-remaining: 1193 rateLimit-reset: 1402425459 . . . ``` ### Sample Rate Limit Headers When Burst Limit is Reached: ``` . . . ratelimit-limit: 5000 ratelimit-remaining: 0 rateLimit-reset: 1402425459 retry-after: 29 . . . ``` ### Sample Rate Exceeded Response ``` 429 Too Many Requests { id: "too_many_requests", message: "API Rate limit exceeded." } ``` ## Curl Examples Throughout this document, some example API requests will be given using the `curl` command. This will allow us to demonstrate the various endpoints in a simple, textual format. These examples assume that you are using a Linux or macOS command line. To run these commands on a Windows machine, you can either use cmd.exe, PowerShell, or WSL: * For cmd.exe, use the `set VAR=VALUE` [syntax](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) to define environment variables, call them with `%VAR%`, then replace all backslashes (`\`) in the examples with carets (`^`). * For PowerShell, use the `$Env:VAR = "VALUE"` [syntax](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables?view=powershell-7.2) to define environment variables, call them with `$Env:VAR`, then replace `curl` with `curl.exe` and all backslashes (`\`) in the examples with backticks (`` ` ``). * WSL is a compatibility layer that allows you to emulate a Linux terminal on a Windows machine. Install WSL with our [community tutorial](https://www.digitalocean.com/community/tutorials/how-to-install-the-windows-subsystem-for-linux-2-on-microsoft-windows-10), then follow this API documentation normally. The names of account-specific references (like Droplet IDs, for instance) will be represented by variables. For instance, a Droplet ID may be represented by a variable called `$DROPLET_ID`. You can set the associated variables in your environment if you wish to use the examples without modification. The first variable that you should set to get started is your OAuth authorization token. The next section will go over the details of this, but you can set an environmental variable for it now. Generate a token by going to the [Apps & API](https://cloud.digitalocean.com/settings/applications) section of the DigitalOcean control panel. Use an existing token if you have saved one, or generate a new token with the "Generate new token" button. Copy the generated token and use it to set and export the TOKEN variable in your environment as the example shows. You may also wish to set some other variables now or as you go along. For example, you may wish to set the `DROPLET_ID` variable to one of your Droplet IDs since this will be used frequently in the API. If you are following along, make sure you use a Droplet ID that you control so that your commands will execute correctly. If you need access to the headers of a response through `curl`, you can pass the `-i` flag to display the header information along with the body. If you are only interested in the header, you can instead pass the `-I` flag, which will exclude the response body entirely. ### Set and Export your OAuth Token ``` export DIGITALOCEAN_TOKEN=your_token_here ``` ### Set and Export a Variable ``` export DROPLET_ID=1111111 ``` ## Parameters There are two different ways to pass parameters in a request with the API. When passing parameters to create or update an object, parameters should be passed as a JSON object containing the appropriate attribute names and values as key-value pairs. When you use this format, you should specify that you are sending a JSON object in the header. This is done by setting the `Content-Type` header to `application/json`. This ensures that your request is interpreted correctly. When passing parameters to filter a response on GET requests, parameters can be passed using standard query attributes. In this case, the parameters would be embedded into the URI itself by appending a `?` to the end of the URI and then setting each attribute with an equal sign. Attributes can be separated with a `&`. Tools like `curl` can create the appropriate URI when given parameters and values; this can also be done using the `-F` flag and then passing the key and value as an argument. The argument should take the form of a quoted string with the attribute being set to a value with an equal sign. ### Pass Parameters as a JSON Object ``` curl -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \ -H "Content-Type: application/json" \ -d '{"name": "example.com", "ip_address": "127.0.0.1"}' \ -X POST "https://api.digitalocean.com/v2/domains" ``` ### Pass Filter Parameters as a Query String ``` curl -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \ -X GET \ "https://api.digitalocean.com/v2/images?private=true" ``` ## Cross Origin Resource Sharing In order to make requests to the API from other domains, the API implements Cross Origin Resource Sharing (CORS) support. CORS support is generally used to create AJAX requests outside of the domain that the request originated from. This is necessary to implement projects like control panels utilizing the API. This tells the browser that it can send requests to an outside domain. The procedure that the browser initiates in order to perform these actions (other than GET requests) begins by sending a "preflight" request. This sets the `Origin` header and uses the `OPTIONS` method. The server will reply back with the methods it allows and some of the limits it imposes. The client then sends the actual request if it falls within the allowed constraints. This process is usually done in the background by the browser, but you can use curl to emulate this process using the example provided. The headers that will be set to show the constraints are: * **Access-Control-Allow-Origin**: This is the domain that is sent by the client or browser as the origin of the request. It is set through an `Origin` header. * **Access-Control-Allow-Methods**: This specifies the allowed options for requests from that domain. This will generally be all available methods. * **Access-Control-Expose-Headers**: This will contain the headers that will be available to requests from the origin domain. * **Access-Control-Max-Age**: This is the length of time that the access is considered valid. After this expires, a new preflight should be sent. * **Access-Control-Allow-Credentials**: This will be set to `true`. It basically allows you to send your OAuth token for authentication. You should not need to be concerned with the details of these headers, because the browser will typically do all of the work for you. license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html contact: name: DigitalOcean API Team email: api-engineering@digitalocean.com termsOfService: https://www.digitalocean.com/legal/terms-of-service-agreement/ servers: - url: https://api.digitalocean.com description: production tags: - name: 1-Click Applications description: >- 1-Click applications are pre-built Droplet images or Kubernetes apps with software, features, and configuration details already set up for you. They can be found in the [DigitalOcean Marketplace](https://www.digitalocean.com/docs/marketplace). - name: Account description: Provides information about your current account. - name: Actions description: >- Actions are records of events that have occurred on the resources in your account. These can be things like rebooting a Droplet, or transferring an image to a new region. An action object is created every time one of these actions is initiated. The action object contains information about the current status of the action, start and complete timestamps, and the associated resource type and ID. Every action that creates an action object is available through this endpoint. Completed actions are not removed from this list and are always available for querying. **Note:** You can pass the following HTTP header with the request to have the API return the `reserved_ips` stanza instead of the `floating_ips` stanza: - `Accept: application/vnd.digitalocean.reserveip+json` - name: Apps description: >- App Platform is a Platform-as-a-Service (PaaS) offering from DigitalOcean that allows developers to publish code directly to DigitalOcean servers without worrying about the underlying infrastructure. Most API operations are centered around a few core object types. Following are the definitions of these types. These definitions will be omitted from the operation-specific documentation. For documentation on app specifications (`AppSpec` objects), please refer to the [product documentation](https://docs.digitalocean.com/products/app-platform/reference/app-spec/)). - name: Billing description: >- The billing endpoints allow you to retrieve your account balance, invoices and billing history. **Balance:** By sending requests to the `/v2/customers/my/balance` endpoint, you can retrieve the balance information for the requested customer account. **Invoices:** [Invoices](https://www.digitalocean.com/docs/accounts/billing/invoices/) are generated on the first of each month for every DigitalOcean customer. An invoice preview is generated daily, which can be accessed with the `preview` keyword in place of `$INVOICE_UUID`. To interact with invoices, you will generally send requests to the invoices endpoint at `/v2/customers/my/invoices`. **Billing History:** Billing history is a record of billing events for your account. For example, entries may include events like payments made, invoices issued, or credits granted. To interact with invoices, you will generally send requests to the invoices endpoint at `/v2/customers/my/billing_history`. - name: Block Storage description: >- [DigitalOcean Block Storage Volumes](https://www.digitalocean.com/docs/volumes/) provide expanded storage capacity for your Droplets and can be moved between Droplets within a specific region. Volumes function as raw block devices, meaning they appear to the operating system as locally attached storage which can be formatted using any file system supported by the OS. They may be created in sizes from 1GiB to 16TiB. By sending requests to the `/v2/volumes` endpoint, you can list, create, or delete volumes as well as attach and detach them from Droplets - name: Block Storage Actions description: |- Block storage actions are commands that can be given to a DigitalOcean Block Storage Volume. An example would be detaching or attaching a volume from a Droplet. These requests are made on the `/v2/volumes/$VOLUME_ID/actions` endpoint. An action object is returned. These objects hold the current status of the requested action. - name: CDN Endpoints description: |- Content hosted in DigitalOcean's object storage solution, [Spaces](https://www.digitalocean.com/docs/spaces/overview/), can optionally be served by our globally distributed Content Delivery Network (CDN). By sending requests to `/v2/cdn/endpoints`, you can list, create, or delete CDN Endpoints as well as purge cached content. To use a custom subdomain to access the CDN Endpoint, provide the ID of a DigitalOcean managed TLS certificate and the fully qualified domain name for the custom subdomain. - name: Certificates description: >- In order to perform SSL termination on load balancers, DigitalOcean offers two types of [SSL certificate management](https://www.digitalocean.com/docs/accounts/security/#certificates): * **Custom**: User-generated certificates may be uploaded to DigitalOcean where they will be placed in a fully encrypted and isolated storage system. * **Let's Encrypt**: Certificates may be automatically generated by DigitalOcean utilizing an integration with Let's Encrypt, the free and open certificate authority. These certificates will also be automatically renewed as required. - name: Container Registry description: >- DigitalOcean offers the ability for you to create a [private container registry](https://www.digitalocean.com/docs/images/container-registry/quickstart/) to store your Docker images for use with your Kubernetes clusters. This container registry runs inside the same datacenters as your cluster, ensuring reliable and performant rollout of image deployments. You can only create one registry per DigitalOcean account, but you can use that registry to create as many repositories as you wish. - name: Databases description: >- DigitalOcean's [managed database service](https://www.digitalocean.com/docs/databases) simplifies the creation and management of highly available database clusters. Currently, it offers support for [PostgreSQL](http://www.digitalocean.com/docs/databases/postgresql/), [Redis](https://www.digitalocean.com/docs/databases/redis/), [MySQL](https://www.digitalocean.com/docs/databases/mysql/), [MongoDB](https://www.digitalocean.com/docs/databases/mongodb/), and [OpenSearch](https://docs.digitalocean.com/products/databases/opensearch/). By sending requests to the `/v2/databases` endpoint, you can list, create, or delete database clusters as well as scale the size of a cluster, add or remove read-only replicas, and manage other configuration details. Database clusters may be deployed in a multi-node, high-availability configuration. If your machine type is above the basic nodes, your node plan is above the smallest option, or you are running MongoDB, you may additionally include up to two standby nodes in your cluster. The size of individual nodes in a database cluster is represented by a human-readable slug, which is used in some of the following requests. Each slug denotes the node's identifier, CPU count, and amount of RAM, in that order. For a list of currently available database slugs and options, use the `/v2/databases/options` endpoint or use the `doctl databases options` [command](https://docs.digitalocean.com/reference/doctl/reference/databases/options). - name: Domain Records description: >- Domain record resources are used to set or retrieve information about the individual DNS records configured for a domain. This allows you to build and manage DNS zone files by adding and modifying individual records for a domain. The [DigitalOcean DNS management interface](https://www.digitalocean.com/docs/networking/dns/) allows you to configure the following DNS records: Name | Description | ------|----------------------------------------------------------------------------------------------------------------------------------------------------| A | This record type is used to map an IPv4 address to a hostname. | AAAA | This record type is used to map an IPv6 address to a hostname. | CAA | As specified in RFC-6844, this record type can be used to restrict which certificate authorities are permitted to issue certificates for a domain. | CNAME | This record type defines an alias for your canonical hostname (the one defined by an A or AAAA record). | MX | This record type is used to define the mail exchanges used for the domain. | NS | This record type defines the name servers that are used for this zone. | TXT | This record type is used to associate a string of text with a hostname, primarily used for verification. | SRV | This record type specifies the location (hostname and port number) of servers for specific services. | SOA | This record type defines administrative information about the zone. Can only have ttl changed, cannot be deleted | - name: Domains description: >- Domain resources are domain names that you have purchased from a domain name registrar that you are managing through the [DigitalOcean DNS interface](https://www.digitalocean.com/docs/networking/dns/). This resource establishes top-level control over each domain. Actions that affect individual domain records should be taken on the [Domain Records](#tag/Domain-Records) resource. - name: Droplet Actions description: |- Droplet actions are tasks that can be executed on a Droplet. These can be things like rebooting, resizing, snapshotting, etc. Droplet action requests are generally targeted at one of the "actions" endpoints for a specific Droplet. The specific actions are usually initiated by sending a POST request with the action and arguments as parameters. Droplet action requests create a Droplet actions object, which can be used to get information about the status of an action. Creating a Droplet action is asynchronous: the HTTP call will return the action object before the action has finished processing on the Droplet. The current status of an action can be retrieved from either the Droplet actions endpoint or the global actions endpoint. If a Droplet action is uncompleted it may block the creation of a subsequent action for that Droplet, the locked attribute of the Droplet will be true and attempts to create a Droplet action will fail with a status of 422. - name: Droplets description: |- A [Droplet](https://www.digitalocean.com/docs/droplets/) is a DigitalOcean virtual machine. By sending requests to the Droplet endpoint, you can list, create, or delete Droplets. Some of the attributes will have an object value. The `region` and `image` objects will all contain the standard attributes of their associated types. Find more information about each of these objects in their respective sections. - name: Firewalls description: >- [DigitalOcean Cloud Firewalls](https://www.digitalocean.com/docs/networking/firewalls/) provide the ability to restrict network access to and from a Droplet allowing you to define which ports will accept inbound or outbound connections. By sending requests to the `/v2/firewalls` endpoint, you can list, create, or delete firewalls as well as modify access rules. - name: Floating IP Actions description: >- As of 16 June 2022, we have renamed the Floating IP product to [Reserved IPs](https://docs.digitalocean.com/reference/api/api-reference/#tag/Reserved-IPs). The Reserved IP product's endpoints function the exact same way as Floating IPs. The only difference is the name change throughout the URLs and fields. For example, the `floating_ips` field is now the `reserved_ips` field. The Floating IP endpoints will remain active until fall 2023 before being permanently deprecated. With the exception of the [Projects API](https://docs.digitalocean.com/reference/api/api-reference/#tag/Projects), we will reflect this change as an additional field in the responses across the API where the `floating_ip` field is used. For example, the Droplet metadata response will contain the field `reserved_ips` in addition to the `floating_ips` field. Floating IPs retrieved using the Projects API will retain the original name. Floating IP actions are commands that can be given to a DigitalOcean floating IP. These requests are made on the actions endpoint of a specific floating IP. An action object is returned. These objects hold the current status of the requested action. - name: Floating IPs description: >- As of 16 June 2022, we have renamed the Floating IP product to [Reserved IPs](https://docs.digitalocean.com/reference/api/api-reference/#tag/Reserved-IPs). The Reserved IP product's endpoints function the exact same way as Floating IPs. The only difference is the name change throughout the URLs and fields. For example, the `floating_ips` field is now the `reserved_ips` field. The Floating IP endpoints will remain active until fall 2023 before being permanently deprecated. With the exception of the [Projects API](https://docs.digitalocean.com/reference/api/api-reference/#tag/Projects), we will reflect this change as an additional field in the responses across the API where the `floating_ip` field is used. For example, the Droplet metadata response will contain the field `reserved_ips` in addition to the `floating_ips` field. Floating IPs retrieved using the Projects API will retain the original name. [DigitalOcean Floating IPs](https://www.digitalocean.com/docs/networking/floating-ips/) are publicly-accessible static IP addresses that can be mapped to one of your Droplets. They can be used to create highly available setups or other configurations requiring movable addresses. Floating IPs are bound to a specific region. - name: Functions description: >- [Serverless functions](https://docs.digitalocean.com/products/functions) are blocks of code that run on demand without the need to manage any infrastructure. You can develop functions on your local machine and then deploy them to a namespace using `doctl`, the [official DigitalOcean CLI tool](https://docs.digitalocean.com/reference/doctl). The Serverless Functions API currently only supports creating and managing namespaces. - name: Image Actions description: |- Image actions are commands that can be given to a DigitalOcean image. In general, these requests are made on the actions endpoint of a specific image. An image action object is returned. These objects hold the current status of the requested action. - name: Images description: >- A DigitalOcean [image](https://www.digitalocean.com/docs/images/) can be used to create a Droplet and may come in a number of flavors. Currently, there are five types of images: snapshots, backups, applications, distributions, and custom images. * [Snapshots](https://www.digitalocean.com/docs/images/snapshots/) provide a full copy of an existing Droplet instance taken on demand. * [Backups](https://www.digitalocean.com/docs/images/backups/) are similar to snapshots but are created automatically at regular intervals when enabled for a Droplet. * [Custom images](https://www.digitalocean.com/docs/images/custom-images/) are Linux-based virtual machine images (raw, qcow2, vhdx, vdi, and vmdk formats are supported) that you may upload for use on DigitalOcean. * Distributions are the public Linux distributions that are available to be used as a base to create Droplets. * Applications, or [1-Click Apps](https://www.digitalocean.com/docs/one-clicks/), are distributions pre-configured with additional software. To interact with images, you will generally send requests to the images endpoint at /v2/images. - name: Kubernetes description: |- [DigitalOcean Kubernetes](https://www.digitalocean.com/docs/kubernetes/) allows you to quickly deploy scalable and secure Kubernetes clusters. By sending requests to the `/v2/kubernetes/clusters` endpoint, you can list, create, or delete clusters as well as scale node pools up and down, recycle individual nodes, and retrieve the kubeconfig file for use with a cluster. - name: Load Balancers description: >- [DigitalOcean Load Balancers](https://www.digitalocean.com/docs/networking/load-balancers/) provide a way to distribute traffic across multiple Droplets. By sending requests to the `/v2/load_balancers` endpoint, you can list, create, or delete load balancers as well as add or remove Droplets, forwarding rules, and other configuration details. - name: Monitoring description: >- The DigitalOcean Monitoring API makes it possible to programmatically retrieve metrics as well as configure alert policies based on these metrics. The Monitoring API can help you gain insight into how your apps are performing and consuming resources. - name: Project Resources description: >- Project Resources are resources that can be grouped into your projects. You can group resources (like Droplets, Spaces, load balancers, domains, and floating IPs) in ways that align with the applications you host on DigitalOcean. ### Supported Resource Types Examples Projects resources are identified by uniform resource names or URNs. A valid URN has the following format: `do:resource_type:resource_id`. The following resource types are supported: Resource Type | Example URN -------------------|------------ App Platform App | `do:app:be5aab85-851b-4cab-b2ed-98d5a63ba4e8` Database | `do:dbaas:83c7a55f-0d84-4760-9245-aba076ec2fb2` Domain | `do:domain:example.com` Droplet | `do:droplet:4126873` Floating IP | `do:floatingip:192.168.99.100` Kubernetes Cluster | `do:kubernetes:bd5f5959-5e1e-4205-a714-a914373942af` Load Balancer | `do:loadbalancer:39052d89-8dd4-4d49-8d5a-3c3b6b365b5b` Space | `do:space:my-website-assets` Volume | `do:volume:6fc4c277-ea5c-448a-93cd-dd496cfef71f` ### Resource Status Codes When assigning and retrieving resources in projects, a `status` attribute is returned that indicates if a resource was successfully retrieved or assigned. The status codes can be one of the following: Status Code | Explanation -------------------|------------ `ok` | There was no problem retrieving or assigning a resource. `not_found` | The resource was not found. `assigned` | The resource was successfully assigned. `already_assigned` | The resource was already assigned. `service_down` | There was a problem retrieving or assigning a resource. Please try again. - name: Projects description: |- Projects allow you to organize your resources into groups that fit the way you work. You can group resources (like Droplets, Spaces, load balancers, domains, and floating IPs) in ways that align with the applications you host on DigitalOcean. - name: Regions description: Provides information about DigitalOcean data center regions. - name: Reserved IP Actions description: >- As of 16 June 2022, we have renamed the [Floating IP](https://docs.digitalocean.com/reference/api/api-reference/#tag/Floating-IPs) product to Reserved IPs. The Reserved IP product's endpoints function the exact same way as Floating IPs. The only difference is the name change throughout the URLs and fields. For example, the `floating_ips` field is now the `reserved_ips` field. The Floating IP endpoints will remain active until fall 2023 before being permanently deprecated. With the exception of the [Projects API](https://docs.digitalocean.com/reference/api/api-reference/#tag/Projects), we will reflect this change as an additional field in the responses across the API where the `floating_ip` field is used. For example, the Droplet metadata response will contain the field `reserved_ips` in addition to the `floating_ips` field. Floating IPs retrieved using the Projects API will retain the original name. Reserved IP actions are commands that can be given to a DigitalOcean reserved IP. These requests are made on the actions endpoint of a specific reserved IP. An action object is returned. These objects hold the current status of the requested action. - name: Reserved IPs description: >- As of 16 June 2022, we have renamed the [Floating IP](https://docs.digitalocean.com/reference/api/api-reference/#tag/Floating-IPs) product to Reserved IPs. The Reserved IP product's endpoints function the exact same way as Floating IPs. The only difference is the name change throughout the URLs and fields. For example, the `floating_ips` field is now the `reserved_ips` field. The Floating IP endpoints will remain active until fall 2023 before being permanently deprecated. With the exception of the [Projects API](https://docs.digitalocean.com/reference/api/api-reference/#tag/Projects), we will reflect this change as an additional field in the responses across the API where the `floating_ip` field is used. For example, the Droplet metadata response will contain the field `reserved_ips` in addition to the `floating_ips` field. Floating IPs retrieved using the Projects API will retain the original name. DigitalOcean Reserved IPs are publicly-accessible static IP addresses that can be mapped to one of your Droplets. They can be used to create highly available setups or other configurations requiring movable addresses. Reserved IPs are bound to a specific region. - name: Sizes description: |- The sizes objects represent different packages of hardware resources that can be used for Droplets. When a Droplet is created, a size must be selected so that the correct resources can be allocated. Each size represents a plan that bundles together specific sets of resources. This includes the amount of RAM, the number of virtual CPUs, disk space, and transfer. The size object also includes the pricing details and the regions that the size is available in. - name: Snapshots description: |- [Snapshots](https://www.digitalocean.com/docs/images/snapshots/) are saved instances of a Droplet or a block storage volume, which is reflected in the `resource_type` attribute. In order to avoid problems with compressing filesystems, each defines a `min_disk_size` attribute which is the minimum size of the Droplet or volume disk when creating a new resource from the saved snapshot. To interact with snapshots, you will generally send requests to the snapshots endpoint at `/v2/snapshots`. - name: SSH Keys description: Manage SSH keys available on your account. - name: Tags description: >- A tag is a label that can be applied to a resource (currently Droplets, Images, Volumes, Volume Snapshots, and Database clusters) in order to better organize or facilitate the lookups and actions on it. Tags have two attributes: a user defined `name` attribute and an embedded `resources` attribute with information about resources that have been tagged. - name: Uptime description: >- [DigitalOcean Uptime Checks](https://docs.digitalocean.com/products/uptime/) provide the ability to monitor your endpoints from around the world, and alert you when they're slow, unavailable, or SSL certificates are expiring. To interact with Uptime, you will generally send requests to the Uptime endpoint at `/v2/uptime/`. - name: VPCs description: >- [VPCs (virtual private clouds)](https://www.digitalocean.com/docs/networking/vpc/) allow you to create virtual networks containing resources that can communicate with each other in full isolation using private IP addresses. By sending requests to the `/v2/vpcs` endpoint, you can create, configure, list, and delete custom VPCs as well as retrieve information about the resources assigned to them. paths: /v2/1-clicks: get: operationId: oneClicks_list summary: List 1-Click Applications description: > To list all available 1-Click applications, send a GET request to `/v2/1-clicks`. The `type` may be provided as query paramater in order to restrict results to a certain type of 1-Click, for example: `/v2/1-clicks?type=droplet`. Current supported types are `kubernetes` and `droplet`. The response will be a JSON object with a key called `1_clicks`. This will be set to an array of 1-Click application data, each of which will contain the the slug and type for the 1-Click. tags: - 1-Click Applications parameters: - $ref: '#/components/parameters/oneClicks_type' responses: '200': $ref: '#/components/responses/oneClicks_all' '401': $ref: '#/components/responses/unauthorized' '429': $ref: '#/components/responses/too_many_requests' '500': $ref: '#/components/responses/server_error' default: $ref: '#/components/responses/unexpected_error' x-codeSamples: - lang: cURL source: |- curl -X GET \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \ "https://api.digitalocean.com/v2/1-clicks" - lang: Python source: |- import os from pydo import Client client = Client(token=os.getenv("$DIGITALOCEAN_TOKEN")) one_click_apps = client.one_clicks.list() security: - bearer_auth: - 1click:read /v2/1-clicks/kubernetes: post: operationId: oneClicks_install_kubernetes summary: Install Kubernetes 1-Click Applications description: > To install a Kubernetes 1-Click application on a cluster, send a POST request to `/v2/1-clicks/kubernetes`. The `addon_slugs` and `cluster_uuid` must be provided as body parameter in order to specify which 1-Click application(s) to install. To list all available 1-Click Kubernetes applications, send a request to `/v2/1-clicks?type=kubernetes`. tags: - 1-Click Applications requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/oneClicks_create' responses: '200': $ref: '#/components/responses/oneClicks_create' '401':