DigitalOcean API

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. Mocked via Mockzilla.

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.

To show information about the current user account, send a GET request to /v2/account.

To list all of the keys in your account, send a GET request to /v2/account/keys. The response will be a JSON object with a key set to ssh_keys. The value of this will be an array of ssh_key objects, each of which contains the standard ssh_key attributes.

To add a new SSH public key to your DigitalOcean account, send a POST request to /v2/account/keys. Set the name attribute to the name you wish to use and the public_key attribute to the full public key you are adding.

To destroy a public SSH key that you have in your account, send a DELETE request to /v2/account/keys/$KEY_ID or /v2/account/keys/$KEY_FINGERPRINT. A 204 status will be returned, indicating that the action was successful and that the response body is empty. Available as a Mockzilla mock endpoint.

To get information about a key, send a GET request to /v2/account/keys/$KEY_ID or /v2/account/keys/$KEY_FINGERPRINT. The response will be a JSON object with the key ssh_key and value an ssh_key object which contains the standard ssh_key attributes.

To update the name of an SSH key, send a PUT request to either /v2/account/keys/$SSH_KEY_ID or /v2/account/keys/$SSH_KEY_FINGERPRINT. Set the name attribute to the new name you want to use.

This will be the entire list of actions taken on your account, so it will be quite large. As with any large collection returned by the API, the results will be paginated with only 20 on each page by default.

To retrieve a specific action object, send a GET request to /v2/actions/$ACTION_ID.

List all apps on your account. Information about the current active deployment as well as any in progress ones will also be included for each app. Mockzilla mock: no signup, no API key.

Create a new app by submitting an app specification. For documentation on app specifications (AppSpec objects), please refer to the product documentation.

Retrieve daily bandwidth usage metrics for multiple apps.

To propose and validate a spec for a new or existing app, send a POST request to the /v2/apps/propose endpoint. The request returns some information about the proposed app, including app cost and upgrade cost. If an existing app ID is specified, the app spec is treated as a proposed update to the existing app.

List all regions supported by App Platform.

List all app tiers. Served by the Mockzilla mock runtime.

List all instance sizes for service, worker, and job components.

Retrieve information about a specific instance size for service, worker, and job components.

Retrieve information about a specific app tier.

List alerts associated to the app and any components. This includes configuration information about the alerts including emails, slack webhooks, and triggering events or conditions.

Updates the emails and slack webhook destinations for app alerts. Emails must be associated to a user with access to the app. Mocked via Mockzilla.

Retrieve the logs of the active deployment if one exists. The response will include links to either real-time logs of an in-progress or active deployment or archived logs of a past deployment. Note log_type=BUILD logs will return logs associated with the current active deployment (being served). To view build logs associated with in-progress build, the query must explicitly reference the deployment id.

List all deployments of an app.

Creating an app deployment will pull the latest changes from your repository and schedule a new deployment for your app.

Retrieve information about an app deployment.

Immediately cancel an in-progress deployment. Available as a Mockzilla mock endpoint.

Retrieve the logs of a past, in-progress, or active deployment. The response will include links to either real-time logs of an in-progress or active deployment or archived logs of a past deployment.

Retrieve the logs of a past, in-progress, or active deployment. If a component name is specified, the logs will be limited to only that component. The response will include links to either real-time logs of an in-progress or active deployment or archived logs of a past deployment.

Retrieve the logs of the active deployment if one exists. The response will include links to either real-time logs of an in-progress or active deployment or archived logs of a past deployment. Note log_type=BUILD logs will return logs associated with the current active deployment (being served). To view build logs associated with in-progress build, the query must explicitly reference the deployment id.

Retrieve daily bandwidth usage metrics for a single app.

Rollback an app to a previous deployment. A new deployment will be created to perform the rollback. The app will be pinned to the rollback deployment preventing any new deployments from being created, either manually or through Auto Deploy on Push webhooks. To resume deployments, the rollback must be either committed or reverted. It is recommended to use the Validate App Rollback endpoint to double check if the rollback is valid and if there are any warnings. Mockzilla mock: no signup, no API key.

Commit an app rollback. This action permanently applies the rollback and unpins the app to resume new deployments.

Revert an app rollback. This action reverts the active rollback by creating a new deployment from the latest app spec prior to the rollback and unpins the app to resume new deployments.

Check whether an app can be rolled back to a specific deployment. This endpoint can also be used to check if there are any warnings or validation conditions that will cause the rollback to proceed under unideal circumstances. For example, if a component must be rebuilt as part of the rollback causing it to take longer than usual.

Delete an existing app. Once deleted, all active deployments will be permanently shut down and the app deleted. If needed, be sure to back up your app specification so that you may re-create it at a later time.

Retrieve details about an existing app by either its ID or name. To retrieve an app by its name, do not include an ID in the request path. Information about the current active deployment as well as any in progress ones will also be included in the response. Served by the Mockzilla mock runtime.

Update an existing app by submitting a new app specification. For documentation on app specifications (AppSpec objects), please refer to the product documentation.

To list all of the CDN endpoints available on your account, send a GET request to /v2/cdn/endpoints.

To create a new CDN endpoint, send a POST request to /v2/cdn/endpoints. The origin attribute must be set to the fully qualified domain name (FQDN) of a DigitalOcean Space. Optionally, the TTL may be configured by setting the ttl attribute. A custom subdomain may be configured by specifying the custom_domain and certificate_id attributes.

To delete a specific CDN endpoint, send a DELETE request to /v2/cdn/endpoints/$ENDPOINT_ID. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed.

To show information about an existing CDN endpoint, send a GET request to /v2/cdn/endpoints/$ENDPOINT_ID. Mocked via Mockzilla.

To update the TTL, certificate ID, or the FQDN of the custom subdomain for an existing CDN endpoint, send a PUT request to /v2/cdn/endpoints/$ENDPOINT_ID.

To purge cached content from a CDN endpoint, send a DELETE request to /v2/cdn/endpoints/$ENDPOINT_ID/cache. The body of the request should include a files attribute containing a list of cached file paths to be purged. A path may be for a single file or may contain a wildcard (*) to recursively purge all files under a directory. When only a wildcard is provided, all cached files will be purged. There is a rate limit of 50 files per 20 seconds that can be purged.

To list all of the certificates available on your account, send a GET request to /v2/certificates.

To upload new SSL certificate which you have previously generated, send a POST request to /v2/certificates. When uploading a user-generated certificate, the private_key, leaf_certificate, and optionally the certificate_chain attributes should be provided. The type must be set to custom. When using Let's Encrypt to create a certificate, the dns_names attribute must be provided, and the type must be set to lets_encrypt.

To delete a specific certificate, send a DELETE request to /v2/certificates/$CERTIFICATE_ID. Available as a Mockzilla mock endpoint.

To show information about an existing certificate, send a GET request to /v2/certificates/$CERTIFICATE_ID.

To retrieve the balances on a customer's account, send a GET request to /v2/customers/my/balance.

To retrieve a list of all billing history entries, send a GET request to /v2/customers/my/billing_history.

To retrieve a list of all invoices, send a GET request to /v2/customers/my/invoices.

To retrieve the invoice items for an invoice, send a GET request to /v2/customers/my/invoices/$INVOICE_UUID. Mockzilla mock: no signup, no API key.

To retrieve a CSV for an invoice, send a GET request to /v2/customers/my/invoices/$INVOICE_UUID/csv.

To retrieve a PDF for an invoice, send a GET request to /v2/customers/my/invoices/$INVOICE_UUID/pdf.

To retrieve a summary for an invoice, send a GET request to /v2/customers/my/invoices/$INVOICE_UUID/summary.

To list all of the database clusters available on your account, send a GET request to /v2/databases. To limit the results to database clusters with a specific tag, include the tag_name query parameter set to the name of the tag. For example, /v2/databases?tag_name=$TAG_NAME. The result will be a JSON object with a databases key. This will be set to an array of database objects, each of which will contain the standard database attributes. The embedded connection and private_connection objects will contain the information needed to access the database cluster: The embedded maintenance_window object will contain information about any scheduled maintenance for the database cluster.

To create a database cluster, send a POST request to /v2/databases. The response will be a JSON object with a key called database. The value of this will be an object that contains the standard attributes associated with a database cluster. The initial value of the database cluster's status attribute will be creating. When the cluster is ready to receive traffic, this will transition to online. The embedded connection and private_connection objects will contain the information needed to access the database cluster. DigitalOcean managed PostgreSQL and MySQL database clusters take automated daily backups. To create a new database cluster based on a backup of an existing cluster, send a POST request to /v2/databases. In addition to the standard database cluster attributes, the JSON body must include a key named backup_restore with the name of the original database cluster and the timestamp of the backup to be restored. Creating a database from a backup is the same as forking a database in the control panel. Note: Backups are not supported for Redis clusters. Served by the Mockzilla mock runtime.

To list all of the options available for the offered database engines, send a GET request to /v2/databases/options. The result will be a JSON object with an options key.

To destroy a specific database, send a DELETE request to /v2/databases/$DATABASE_ID. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed.

To show information about an existing database cluster, send a GET request to /v2/databases/$DATABASE_ID. The response will be a JSON object with a database key. This will be set to an object containing the standard database cluster attributes. The embedded connection and private_connection objects will contain the information needed to access the database cluster. The embedded maintenance_window object will contain information about any scheduled maintenance for the database cluster.

To list all of the available backups of a PostgreSQL or MySQL database cluster, send a GET request to /v2/databases/$DATABASE_ID/backups. Note: Backups are not supported for Redis clusters. The result will be a JSON object with a backups key. This will be set to an array of backup objects, each of which will contain the size of the backup and the timestamp at which it was created.

To retrieve the public certificate used to secure the connection to the database cluster send a GET request to /v2/databases/$DATABASE_ID/ca. The response will be a JSON object with a ca key. This will be set to an object containing the base64 encoding of the public key certificate. Mocked via Mockzilla.

Shows configuration parameters for an existing database cluster by sending a GET request to /v2/databases/$DATABASE_ID/config. The response is a JSON object with a config key, which is set to an object containing any database configuration parameters.

To update the configuration for an existing database cluster, send a PATCH request to /v2/databases/$DATABASE_ID/config.

To list all of the databases in a clusters, send a GET request to /v2/databases/$DATABASE_ID/dbs. The result will be a JSON object with a dbs key. This will be set to an array of database objects, each of which will contain the standard database attributes. Note: Database management is not supported for Redis clusters.

To add a new database to an existing cluster, send a POST request to /v2/databases/$DATABASE_ID/dbs. Note: Database management is not supported for Redis clusters. The response will be a JSON object with a key called db. The value of this will be an object that contains the standard attributes associated with a database.

To delete a specific database, send a DELETE request to /v2/databases/$DATABASE_ID/dbs/$DB_NAME. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed. Note: Database management is not supported for Redis clusters. Available as a Mockzilla mock endpoint.

To show information about an existing database cluster, send a GET request to /v2/databases/$DATABASE_ID/dbs/$DB_NAME. Note: Database management is not supported for Redis clusters. The response will be a JSON object with a db key. This will be set to an object containing the standard database attributes.

To retrieve the configured eviction policy for an existing Redis cluster, send a GET request to /v2/databases/$DATABASE_ID/eviction_policy. The response will be a JSON object with an eviction_policy key. This will be set to a string representing the eviction policy.

To configure an eviction policy for an existing Redis cluster, send a PUT request to /v2/databases/$DATABASE_ID/eviction_policy specifying the desired policy.

To list all of a database cluster's firewall rules (known as "trusted sources" in the control panel), send a GET request to /v2/databases/$DATABASE_ID/firewall. The result will be a JSON object with a rules key.

To update a database cluster's firewall rules (known as "trusted sources" in the control panel), send a PUT request to /v2/databases/$DATABASE_ID/firewall specifying which resources should be able to open connections to the database. You may limit connections to specific Droplets, Kubernetes clusters, or IP addresses. When a tag is provided, any Droplet or Kubernetes node with that tag applied to it will have access. The firewall is limited to 100 rules (or trusted sources). When possible, we recommend placing your databases into a VPC network to limit access to them instead of using a firewall. A successful. Mockzilla mock: no signup, no API key.

To configure the window when automatic maintenance should be performed for a database cluster, send a PUT request to /v2/databases/$DATABASE_ID/maintenance. A successful request will receive a 204 No Content status code with no body in response.

To migrate a database cluster to a new region, send a PUT request to /v2/databases/$DATABASE_ID/migrate. The body of the request must specify a region attribute. A successful request will receive a 202 Accepted status code with no body in response. Querying the database cluster will show that its status attribute will now be set to migrating. This will transition back to online when the migration has completed.

To retrieve the status of the most recent online migration, send a GET request to /v2/databases/$DATABASE_ID/online-migration.

To start an online migration, send a PUT request to /v2/databases/$DATABASE_ID/online-migration endpoint. Migrating a cluster establishes a connection with an existing cluster and replicates its contents to the target cluster. Online migration is only available for MySQL, PostgreSQL, and Redis clusters.

To stop an online migration, send a DELETE request to /v2/databases/$DATABASE_ID/online-migration/$MIGRATION_ID. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed. Served by the Mockzilla mock runtime.

To list all of the connection pools available to a PostgreSQL database cluster, send a GET request to /v2/databases/$DATABASE_ID/pools. The result will be a JSON object with a pools key. This will be set to an array of connection pool objects.

For PostgreSQL database clusters, connection pools can be used to allow a database to share its idle connections. The popular PostgreSQL connection pooling utility PgBouncer is used to provide this service. See here for more information about how and why to use PgBouncer connection pooling including details about the available transaction modes. To add a new connection pool to a PostgreSQL database cluster, send a POST request to /v2/databases/$DATABASE_ID/pools specifying a name for the pool, the user to connect with, the database to connect to, as well as its desired size and transaction mode.

To delete a specific connection pool for a PostgreSQL database cluster, send a DELETE request to /v2/databases/$DATABASE_ID/pools/$POOL_NAME. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed.

To show information about an existing connection pool for a PostgreSQL database cluster, send a GET request to /v2/databases/$DATABASE_ID/pools/$POOL_NAME. The response will be a JSON object with a pool key.

To update a connection pool for a PostgreSQL database cluster, send a PUT request to /v2/databases/$DATABASE_ID/pools/$POOL_NAME. Mocked via Mockzilla.

To list all of the read-only replicas associated with a database cluster, send a GET request to /v2/databases/$DATABASE_ID/replicas. Note: Read-only replicas are not supported for Redis clusters. The result will be a JSON object with a replicas key. This will be set to an array of database replica objects, each of which will contain the standard database replica attributes.

To create a read-only replica for a PostgreSQL or MySQL database cluster, send a POST request to /v2/databases/$DATABASE_ID/replicas specifying the name it should be given, the size of the node to be used, and the region where it will be located. Note: Read-only replicas are not supported for Redis clusters. The response will be a JSON object with a key called replica. The value of this will be an object that contains the standard attributes associated with a database replica. The initial value of the read-only replica's status attribute will be forking. When the replica is ready to receive traffic, this will transition to active.

To destroy a specific read-only replica, send a DELETE request to /v2/databases/$DATABASE_ID/replicas/$REPLICA_NAME. Note: Read-only replicas are not supported for Redis clusters. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed.

To show information about an existing database replica, send a GET request to /v2/databases/$DATABASE_ID/replicas/$REPLICA_NAME. Note: Read-only replicas are not supported for Redis clusters. The response will be a JSON object with a replica key. This will be set to an object containing the standard database replica attributes.

To promote a specific read-only replica, send a PUT request to /v2/databases/$DATABASE_ID/replicas/$REPLICA_NAME/promote. Note: Read-only replicas are not supported for Redis clusters. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed. Available as a Mockzilla mock endpoint.

To resize a database cluster, send a PUT request to /v2/databases/$DATABASE_ID/resize. The body of the request must specify both the size and num_nodes attributes. A successful request will receive a 202 Accepted status code with no body in response. Querying the database cluster will show that its status attribute will now be set to resizing. This will transition back to online when the resize operation has completed.

To retrieve the configured SQL modes for an existing MySQL cluster, send a GET request to /v2/databases/$DATABASE_ID/sql_mode. The response will be a JSON object with a sql_mode key. This will be set to a string representing the configured SQL modes.

To configure the SQL modes for an existing MySQL cluster, send a PUT request to /v2/databases/$DATABASE_ID/sql_mode specifying the desired modes. See the official MySQL 8 documentation for a full list of supported SQL modes. A successful request will receive a 204 No Content status code with no body in response.

To upgrade the major version of a database, send a PUT request to /v2/databases/$DATABASE_ID/upgrade, specifying the target version. A successful request will receive a 204 No Content status code with no body in response.

To list all of the users for your database cluster, send a GET request to /v2/databases/$DATABASE_ID/users. Note: User management is not supported for Redis clusters. The result will be a JSON object with a users key. This will be set to an array of database user objects, each of which will contain the standard database user attributes. For MySQL clusters, additional options will be contained in the mysql_settings object. Mockzilla mock: no signup, no API key.

To add a new database user, send a POST request to /v2/databases/$DATABASE_ID/users with the desired username. Note: User management is not supported for Redis clusters. When adding a user to a MySQL cluster, additional options can be configured in the mysql_settings object. The response will be a JSON object with a key called user. The value of this will be an object that contains the standard attributes associated with a database user including its randomly generated password.

To remove a specific database user, send a DELETE request to /v2/databases/$DATABASE_ID/users/$USERNAME. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed. Note: User management is not supported for Redis clusters.

To show information about an existing database user, send a GET request to /v2/databases/$DATABASE_ID/users/$USERNAME. Note: User management is not supported for Redis clusters. The response will be a JSON object with a user key. This will be set to an object containing the standard database user attributes. For MySQL clusters, additional options will be contained in the mysql_settings object.

To reset the password for a database user, send a POST request to /v2/databases/$DATABASE_ID/users/$USERNAME/reset_auth. For mysql databases, the authentication method can be specifying by including a key in the JSON body called mysql_settings with the auth_plugin value specified. The response will be a JSON object with a user key. This will be set to an object containing the standard database user attributes.

To retrieve a list of all of the domains in your account, send a GET request to /v2/domains. Served by the Mockzilla mock runtime.

To create a new domain, send a POST request to /v2/domains. Set the "name" attribute to the domain name you are adding. Optionally, you may set the "ip_address" attribute, and an A record will be automatically created pointing to the apex domain.

To delete a domain, send a DELETE request to /v2/domains/$DOMAIN_NAME.

To get details about a specific domain, send a GET request to /v2/domains/$DOMAIN_NAME.

To get a listing of all records configured for a domain, send a GET request to /v2/domains/$DOMAIN_NAME/records. The list of records returned can be filtered by using the name and type query parameters. For example, to only include A records for a domain, send a GET request to /v2/domains/$DOMAIN_NAME/records?type=A. name must be a fully qualified record name. For example, to only include records matching sub.example.com, send a GET request to /v2/domains/$DOMAIN_NAME/records?name=sub.example.com. Both name and type may be used together.

To create a new record to a domain, send a POST request to /v2/domains/$DOMAIN_NAME/records. The request must include all of the required fields for the domain record type being added. See the attribute table for details regarding record types and their respective required attributes. Mocked via Mockzilla.

To delete a record for a domain, send a DELETE request to /v2/domains/$DOMAIN_NAME/records/$DOMAIN_RECORD_ID. The record will be deleted and the response status will be a 204. This indicates a successful request with no body returned.

To retrieve a specific domain record, send a GET request to /v2/domains/$DOMAIN_NAME/records/$RECORD_ID.

To update an existing record, send a PATCH request to /v2/domains/$DOMAIN_NAME/records/$DOMAIN_RECORD_ID. Any attribute valid for the record type can be set to a new value for the record. See the attribute table for details regarding record types and their respective attributes.

To update an existing record, send a PUT request to /v2/domains/$DOMAIN_NAME/records/$DOMAIN_RECORD_ID. Any attribute valid for the record type can be set to a new value for the record. See the attribute table for details regarding record types and their respective attributes.

To delete all Droplets assigned to a specific tag, include the tag_name query parameter set to the name of the tag in your DELETE request. For example, /v2/droplets?tag_name=$TAG_NAME. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully. Available as a Mockzilla mock endpoint.

To list all Droplets in your account, send a GET request to /v2/droplets. The response body will be a JSON object with a key of droplets. This will be set to an array containing objects each representing a Droplet. These will contain the standard Droplet attributes. Filtering Results by Tag It's possible to request filtered results by including certain query parameters. To only list Droplets assigned to a specific tag, include the tag_name query parameter set to the name of the tag in your GET request. For example, /v2/droplets?tag_name=$TAG_NAME.

To create a new Droplet, send a POST request to /v2/droplets setting the required attributes. A Droplet will be created using the provided information. The response body will contain a JSON object with a key called droplet. The value will be an object containing the standard attributes for your new Droplet. The response code, 202 Accepted, does not indicate the success or failure of the operation, just that the request has been accepted for processing. The actions returned as part of the response's links object can be used to check the status of the Droplet create event. Create Multiple Droplets Creating multiple Droplets is very similar to creating a single Droplet. Instead of sending name as a string, send names as an array of strings. A Droplet will be created for each name you send using the associated information. Up to ten Droplets may be created this way at a time. Rather than returning a single Droplet, the response body will contain a JSON array with a key called droplets. This will be set to an array of JSON objects, each of which will contain the standard Droplet attributes. The response code, 202 Accepted, does not indicate the success or failure of any operation, just that the request has been accepted for processing. The array of actions returned as part of the response's links object can be used to check the status of each individual Droplet create event.

Some actions can be performed in bulk on tagged Droplets. The actions can be initiated by sending a POST to /v2/droplets/actions?tag_name=$TAG_NAME with the action arguments. Only a sub-set of action types are supported: - power_cycle - power_on - power_off - shutdown - enable_ipv6 - enable_backups - disable_backups - snapshot

To delete a Droplet, send a DELETE request to /v2/droplets/$DROPLET_ID. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully.

To show information about an individual Droplet, send a GET request to /v2/droplets/$DROPLET_ID. Mockzilla mock: no signup, no API key.

To retrieve a list of all actions that have been executed for a Droplet, send a GET request to /v2/droplets/$DROPLET_ID/actions. The results will be returned as a JSON object with an actions key. This will be set to an array filled with action objects containing the standard action attributes.

To initiate an action on a Droplet send a POST request to /v2/droplets/$DROPLET_ID/actions. In the JSON body to the request, set the type attribute to on of the supported action types: | Action | Details | | ---------------------------------------- | ----------- | | enable_backups | Enables backups for a Droplet | | disable_backups | Disables backups for a Droplet | | reboot | Reboots a Droplet. A reboot action is an attempt to reboot the Droplet in a graceful way, similar to using the reboot command from the console. | | power_cycle | Power cycles a Droplet. A powercycle action is similar to pushing the reset button on a physical machine, it's similar to booting from scratch. | | shutdown | Shutsdown a Droplet. A shutdown action is an attempt to shutdown the Droplet in a graceful way, similar to using the shutdown command from the console. Since a shutdown command can fail, this action guarantees that the command is issued, not that it succeeds. The preferred way to turn off a Droplet is to attempt a shutdown, with a reasonable timeout, followed by a power_off action to ensure the Droplet is off. | | power_off | Powers off a Droplet. A power_off event is a hard shutdown and should only be used if the shutdown action is not successful. It is similar to cutting the power on a server and could lead to complications. | | power_on | Powers on a Droplet. | | restore | Restore a Droplet using a backup image. The image ID that is passed in must be a backup of the current Droplet instance. The operation will leave any embedded SSH keys intact. | | password_reset | Resets the root password for a Droplet. A new password will be provided via email. It must be changed after first use. | | resize | Resizes a Droplet. Set the size attribute to a size slug. If a permanent resize with disk changes included is desired, set the disk attribute to true. | | rebuild | Rebuilds a Droplet from a new base image. Set the image attribute to an image ID or slug. | | rename | Renames a Droplet. | | change_kernel | Changes a Droplet's kernel. Only applies to Droplets with externally managed kernels. All Droplets created after March 2017 use internal kernels by default. | | enable_ipv6 | Enables IPv6 for a Droplet. | | snapshot | Takes a snapshot of a Droplet. |

To retrieve a Droplet action, send a GET request to /v2/droplets/$DROPLET_ID/actions/$ACTION_ID. The response will be a JSON object with a key called action. The value will be a Droplet action object.

To retrieve any backups associated with a Droplet, send a GET request to /v2/droplets/$DROPLET_ID/backups. You will get back a JSON object that has a backups key. This will be set to an array of backup objects, each of which contain the standard Droplet backup attributes.

To list the associated billable resources that can be destroyed along with a Droplet, send a GET request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources endpoint. The response will be a JSON object containing snapshots, volumes, and volume_snapshots keys. Each will be set to an array of objects containing information about the associated resources. Served by the Mockzilla mock runtime.

To destroy a Droplet along with all of its associated resources, send a DELETE request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/dangerous endpoint. The headers of this request must include an X-Dangerous key set to true. To preview which resources will be destroyed, first query the Droplet's associated resources. This operation can not be reverse and should be used with caution. A successful response will include a 202 response code and no content. Use the status endpoint to check on the success or failure of the destruction of the individual resources.

If the status of a request to destroy a Droplet with its associated resources reported any errors, it can be retried by sending a POST request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/retry endpoint. Only one destroy can be active at a time per Droplet. If a retry is issued while another destroy is in progress for the Droplet a 409 status code will be returned. A successful response will include a 202 response code and no content.

To destroy a Droplet along with a sub-set of its associated resources, send a DELETE request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/selective endpoint. The JSON body of the request should include reserved_ips, snapshots, volumes, or volume_snapshots keys each set to an array of IDs for the associated resources to be destroyed. The IDs can be found by querying the Droplet's associated resources. Any associated resource not included in the request will remain and continue to accrue changes on your account. A successful response will include a 202 response code and no content. Use the status endpoint to check on the success or failure of the destruction of the individual resources.

To check on the status of a request to destroy a Droplet with its associated resources, send a GET request to the /v2/droplets/$DROPLET_ID/destroy_with_associated_resources/status endpoint.

To retrieve a list of all firewalls available to a Droplet, send a GET request to /v2/droplets/$DROPLET_ID/firewalls The response will be a JSON object that has a key called firewalls. This will be set to an array of firewall objects, each of which contain the standard firewall attributes. Mocked via Mockzilla.

To retrieve a list of all kernels available to a Droplet, send a GET request to /v2/droplets/$DROPLET_ID/kernels The response will be a JSON object that has a key called kernels. This will be set to an array of kernel objects, each of which contain the standard kernel attributes.

To retrieve a list of any "neighbors" (i.e. Droplets that are co-located on the same physical hardware) for a specific Droplet, send a GET request to /v2/droplets/$DROPLET_ID/neighbors. The results will be returned as a JSON object with a key of droplets. This will be set to an array containing objects representing any other Droplets that share the same physical hardware. An empty array indicates that the Droplet is not co-located any other Droplets associated with your account.

To retrieve the snapshots that have been created from a Droplet, send a GET request to /v2/droplets/$DROPLET_ID/snapshots. You will get back a JSON object that has a snapshots key. This will be set to an array of snapshot objects, each of which contain the standard Droplet snapshot attributes.

To list all of the firewalls available on your account, send a GET request to /v2/firewalls.

To create a new firewall, send a POST request to /v2/firewalls. The request must contain at least one inbound or outbound access rule. Available as a Mockzilla mock endpoint.

To delete a firewall send a DELETE request to /v2/firewalls/$FIREWALL_ID. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To show information about an existing firewall, send a GET request to /v2/firewalls/$FIREWALL_ID.

To update the configuration of an existing firewall, send a PUT request to /v2/firewalls/$FIREWALL_ID. The request should contain a full representation of the firewall including existing attributes. Note that any attributes that are not provided will be reset to their default values.

To remove a Droplet from a firewall, send a DELETE request to /v2/firewalls/$FIREWALL_ID/droplets. In the body of the request, there should be a droplet_ids attribute containing a list of Droplet IDs. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To assign a Droplet to a firewall, send a POST request to /v2/firewalls/$FIREWALL_ID/droplets. In the body of the request, there should be a droplet_ids attribute containing a list of Droplet IDs. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data. Mockzilla mock: no signup, no API key.

To remove access rules from a firewall, send a DELETE request to /v2/firewalls/$FIREWALL_ID/rules. The body of the request may include an inbound_rules and/or outbound_rules attribute containing an array of rules to be removed. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To add additional access rules to a firewall, send a POST request to /v2/firewalls/$FIREWALL_ID/rules. The body of the request may include an inbound_rules and/or outbound_rules attribute containing an array of rules to be added. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To remove a tag representing a group of Droplets from a firewall, send a DELETE request to /v2/firewalls/$FIREWALL_ID/tags. In the body of the request, there should be a tags attribute containing a list of tag names. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To assign a tag representing a group of Droplets to a firewall, send a POST request to /v2/firewalls/$FIREWALL_ID/tags. In the body of the request, there should be a tags attribute containing a list of tag names. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To list all of the floating IPs available on your account, send a GET request to /v2/floating_ips. Served by the Mockzilla mock runtime.

On creation, a floating IP must be either assigned to a Droplet or reserved to a region. To create a new floating IP assigned to a Droplet, send a POST request to /v2/floating_ips with the droplet_id attribute. To create a new floating IP reserved to a region, send a POST request to /v2/floating_ips with the region attribute. Note: In addition to the standard rate limiting, only 12 floating IPs may be created per 60 seconds.

To delete a floating IP and remove it from your account, send a DELETE request to /v2/floating_ips/$FLOATING_IP_ADDR. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully.

To show information about a floating IP, send a GET request to /v2/floating_ips/$FLOATING_IP_ADDR.

To retrieve all actions that have been executed on a floating IP, send a GET request to /v2/floating_ips/$FLOATING_IP/actions.

To initiate an action on a floating IP send a POST request to /v2/floating_ips/$FLOATING_IP/actions. In the JSON body to the request, set the type attribute to on of the supported action types: | Action | Details |------------|-------- | assign | Assigns a floating IP to a Droplet | unassign | Unassign a floating IP from a Droplet. Mocked via Mockzilla.

To retrieve the status of a floating IP action, send a GET request to /v2/floating_ips/$FLOATING_IP/actions/$ACTION_ID.

Returns a list of namespaces associated with the current user. To get all namespaces, send a GET request to /v2/functions/namespaces.

Creates a new serverless functions namespace in the desired region and associates it with the provided label. A namespace is a collection of functions and their associated packages, triggers, and project specifications. To create a namespace, send a POST request to /v2/functions/namespaces with the region and label properties.

Deletes the given namespace. When a namespace is deleted all assets, in the namespace are deleted, this includes packages, functions and triggers. Deleting a namespace is a destructive operation and assets in the namespace are not recoverable after deletion. Some metadata is retained, such as activations, or soft deleted for reporting purposes. To delete namespace, send a DELETE request to /v2/functions/namespaces/$NAMESPACE_ID. A successful deletion returns a 204 response.

Gets the namespace details for the given namespace UUID. To get namespace details, send a GET request to /v2/functions/namespaces/$NAMESPACE_ID with no parameters. Available as a Mockzilla mock endpoint.

Returns a list of triggers associated with the current user and namespace. To get all triggers, send a GET request to /v2/functions/namespaces/$NAMESPACE_ID/triggers.

Creates a new trigger for a given function in a namespace. To create a trigger, send a POST request to /v2/functions/namespaces/$NAMESPACE_ID/triggers with the name, function, type, is_enabled and scheduled_details properties.

Deletes the given trigger. To delete trigger, send a DELETE request to /v2/functions/namespaces/$NAMESPACE_ID/triggers/$TRIGGER_NAME. A successful deletion returns a 204 response.

Gets the trigger details. To get the trigger details, send a GET request to /v2/functions/namespaces/$NAMESPACE_ID/triggers/$TRIGGER_NAME.

Updates the details of the given trigger. To update a trigger, send a PUT request to /v2/functions/namespaces/$NAMESPACE_ID/triggers/$TRIGGER_NAME with new values for the is_enabled or scheduled_details properties. Mockzilla mock: no signup, no API key.

To list all of the images available on your account, send a GET request to /v2/images. Filtering Results It's possible to request filtered results by including certain query parameters. Image Type Either 1-Click Application or OS Distribution images can be filtered by using the type query parameter. Important: The type query parameter does not directly relate to the type attribute. To retrieve only distribution images, include the type query parameter set to distribution, /v2/images?type=distribution. To retrieve only application images, include the type query parameter set to application, /v2/images?type=application. User Images To retrieve only the private images of a user, include the private query parameter set to true, /v2/images?private=true. Tags To list all images assigned to a specific tag, include the tag_name query parameter set to the name of the tag in your GET request. For example, /v2/images?tag_name=$TAG_NAME.

To create a new custom image, send a POST request to /v2/images. The body must contain a url attribute pointing to a Linux virtual machine image to be imported into DigitalOcean. The image must be in the raw, qcow2, vhdx, vdi, or vmdk format. It may be compressed using gzip or bzip2 and must be smaller than 100 GB after being decompressed.

To delete a snapshot or custom image, send a DELETE request to /v2/images/$IMAGE_ID.

To retrieve information about an image, send a GET request to /v2/images/$IDENTIFIER.

To update an image, send a PUT request to /v2/images/$IMAGE_ID. Set the name attribute to the new value you would like to use. For custom images, the description and distribution attributes may also be updated. Served by the Mockzilla mock runtime.

To retrieve all actions that have been executed on an image, send a GET request to /v2/images/$IMAGE_ID/actions.

The following actions are available on an Image. Convert an Image to a Snapshot To convert an image, for example, a backup to a snapshot, send a POST request to /v2/images/$IMAGE_ID/actions. Set the type attribute to convert. Transfer an Image To transfer an image to another region, send a POST request to /v2/images/$IMAGE_ID/actions. Set the type attribute to transfer and set region attribute to the slug identifier of the region you wish to transfer to.

To retrieve the status of an image action, send a GET request to /v2/images/$IMAGE_ID/actions/$IMAGE_ACTION_ID.

To list all of the Kubernetes clusters on your account, send a GET request to /v2/kubernetes/clusters.

To create a new Kubernetes cluster, send a POST request to /v2/kubernetes/clusters. The request must contain at least one node pool with at least one worker. The request may contain a maintenance window policy describing a time period when disruptive maintenance tasks may be carried out. Omitting the policy implies that a window will be chosen automatically. See here for details. Mocked via Mockzilla.

To delete a Kubernetes cluster and all services deployed to it, send a DELETE request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID. A 204 status code with no body will be returned in response to a successful request.

To show information about an existing Kubernetes cluster, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID.

To update a Kubernetes cluster, send a PUT request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID and specify one or more of the attributes below.

To request clusterlint diagnostics for your cluster, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/clusterlint. If the run_id query parameter is provided, then the diagnostics for the specific run is fetched. By default, the latest results are shown. To find out how to address clusterlint feedback, please refer to the clusterlint check documentation.

Clusterlint helps operators conform to Kubernetes best practices around resources, security and reliability to avoid common problems while operating or upgrading the clusters. To request a clusterlint run on your cluster, send a POST request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/clusterlint. This will run all checks present in the doks group by default, if a request body is not specified. Optionally specify the below attributes. For information about the available checks, please refer to the clusterlint check documentation. Available as a Mockzilla mock endpoint.

This endpoint returns a JSON object . It can be used to programmatically construct Kubernetes clients which cannot parse kubeconfig files. The resulting JSON object contains token-based authentication for clusters supporting it, and certificate-based authentication otherwise. For a list of supported versions and more information, see "How to Connect to a DigitalOcean Kubernetes Cluster with kubectl". To retrieve credentials for accessing a Kubernetes cluster, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/credentials. Clusters supporting token-based authentication may define an expiration by passing a duration in seconds as a query parameter to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/kubeconfig?expiry_seconds=$DURATION_IN_SECONDS. If not set or 0, then the token will have a 7 day expiry. The query parameter has no impact in certificate-based authentication.

To list the associated billable resources that can be destroyed along with a cluster, send a GET request to the /v2/kubernetes/clusters/$K8S_CLUSTER_ID/destroy_with_associated_resources endpoint.

To delete a Kubernetes cluster with all of its associated resources, send a DELETE request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/destroy_with_associated_resources/dangerous. A 204 status code with no body will be returned in response to a successful request.

To delete a Kubernetes cluster along with a subset of its associated resources, send a DELETE request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/destroy_with_associated_resources/selective. The JSON body of the request should include load_balancers, volumes, or volume_snapshots keys each set to an array of IDs for the associated resources to be destroyed. The IDs can be found by querying the cluster's associated resources endpoint. Any associated resource not included in the request will remain and continue to accrue changes on your account.

This endpoint returns a kubeconfig file in YAML format. It can be used to connect to and administer the cluster using the Kubernetes command line tool, kubectl, or other programs supporting kubeconfig files (e.g., client libraries). The resulting kubeconfig file uses token-based authentication for clusters supporting it, and certificate-based authentication otherwise. For a list of supported versions and more information, see "How to Connect to a DigitalOcean Kubernetes Cluster with kubectl". To retrieve a kubeconfig file for use with a Kubernetes cluster, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/kubeconfig. Clusters supporting token-based authentication may define an expiration by passing a duration in seconds as a query parameter to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/kubeconfig?expiry_seconds=$DURATION_IN_SECONDS. If not set or 0, then the token will have a 7 day expiry. The query parameter has no impact in certificate-based authentication. Mockzilla mock: no signup, no API key.

To list all of the node pools in a Kubernetes clusters, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/node_pools.

To add an additional node pool to a Kubernetes clusters, send a POST request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/node_pools with the following attributes.

To delete a node pool, send a DELETE request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/node_pools/$NODE_POOL_ID. A 204 status code with no body will be returned in response to a successful request. Nodes in the pool will subsequently be drained and deleted.

To show information about a specific node pool in a Kubernetes cluster, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/node_pools/$NODE_POOL_ID.

To update the name of a node pool, edit the tags applied to it, or adjust its number of nodes, send a PUT request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/node_pools/$NODE_POOL_ID with the following attributes. Served by the Mockzilla mock runtime.

To delete a single node in a pool, send a DELETE request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/node_pools/$NODE_POOL_ID/nodes/$NODE_ID. Appending the skip_drain=1 query parameter to the request causes node draining to be skipped. Omitting the query parameter or setting its value to 0 carries out draining prior to deletion. Appending the replace=1 query parameter to the request causes the node to be replaced by a new one after deletion. Omitting the query parameter or setting its value to 0 deletes without replacement.

The endpoint has been deprecated. Please use the DELETE /v2/kubernetes/clusters/$K8S_CLUSTER_ID/node_pools/$NODE_POOL_ID/nodes/$NODE_ID method instead.

To immediately upgrade a Kubernetes cluster to a newer patch release of Kubernetes, send a POST request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/upgrade. The body of the request must specify a version attribute. Available upgrade versions for a cluster can be fetched from /v2/kubernetes/clusters/$K8S_CLUSTER_ID/upgrades.

To determine whether a cluster can be upgraded, and the versions to which it can be upgraded, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/upgrades.

To show information the user associated with a Kubernetes cluster, send a GET request to /v2/kubernetes/clusters/$K8S_CLUSTER_ID/user. Mocked via Mockzilla.

To list the versions of Kubernetes available for use, the regions that support Kubernetes, and the available node sizes, send a GET request to /v2/kubernetes/options.

To remove the container registry from Kubernetes clusters, send a DELETE request to /v2/kubernetes/registry.

To integrate the container registry with Kubernetes clusters, send a POST request to /v2/kubernetes/registry.

To list all of the load balancer instances on your account, send a GET request to /v2/load_balancers.

To create a new load balancer instance, send a POST request to /v2/load_balancers. You can specify the Droplets that will sit behind the load balancer using one of two methods: Set droplet_ids to a list of specific Droplet IDs. Set tag to the name of a tag. All Droplets with this tag applied will be assigned to the load balancer. Additional Droplets will be automatically assigned as they are tagged. These methods are mutually exclusive. Available as a Mockzilla mock endpoint.

To delete a load balancer instance, disassociating any Droplets assigned to it and removing it from your account, send a DELETE request to /v2/load_balancers/$LOAD_BALANCER_ID. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully.

To show information about a load balancer instance, send a GET request to /v2/load_balancers/$LOAD_BALANCER_ID.

To update a load balancer's settings, send a PUT request to /v2/load_balancers/$LOAD_BALANCER_ID. The request should contain a full representation of the load balancer including existing attributes. It may contain one of the droplets_ids or tag attributes as they are mutually exclusive. Note that any attribute that is not provided will be reset to its default value.

To remove a Droplet from a load balancer instance, send a DELETE request to /v2/load_balancers/$LOAD_BALANCER_ID/droplets. In the body of the request, there should be a droplet_ids attribute containing a list of Droplet IDs. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To assign a Droplet to a load balancer instance, send a POST request to /v2/load_balancers/$LOAD_BALANCER_ID/droplets. In the body of the request, there should be a droplet_ids attribute containing a list of Droplet IDs. Individual Droplets can not be added to a load balancer configured with a Droplet tag. Attempting to do so will result in a "422 Unprocessable Entity" response from the API. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data. Mockzilla mock: no signup, no API key.

To remove forwarding rules from a load balancer instance, send a DELETE request to /v2/load_balancers/$LOAD_BALANCER_ID/forwarding_rules. In the body of the request, there should be a forwarding_rules attribute containing an array of rules to be removed. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To add an additional forwarding rule to a load balancer instance, send a POST request to /v2/load_balancers/$LOAD_BALANCER_ID/forwarding_rules. In the body of the request, there should be a forwarding_rules attribute containing an array of rules to be added. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

Returns all alert policies that are configured for the given account. To List all alert policies, send a GET request to /v2/monitoring/alerts.

To create a new alert, send a POST request to /v2/monitoring/alerts.

To delete an alert policy, send a DELETE request to /v2/monitoring/alerts/{alert_uuid}. Served by the Mockzilla mock runtime.

To retrieve a given alert policy, send a GET request to /v2/monitoring/alerts/{alert_uuid}

To update en existing policy, send a PUT request to v2/monitoring/alerts/{alert_uuid}.

To retrieve bandwidth metrics for a given Droplet, send a GET request to /v2/monitoring/metrics/droplet/bandwidth. Use the interface query parameter to specify if the results should be for the private or public interface. Use the direction query parameter to specify if the results should be for inbound or outbound traffic.

To retrieve CPU metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/cpu.

To retrieve filesystem free metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/filesystem_free. Mocked via Mockzilla.

To retrieve filesystem size metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/filesystem_size.

To retrieve 1 minute load average metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/load_1.

To retrieve 15 minute load average metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/load_15.

To retrieve 5 minute load average metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/load_5.

To retrieve available memory metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/memory_available. Available as a Mockzilla mock endpoint.

To retrieve cached memory metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/memory_cached.

To retrieve free memory metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/memory_free.

To retrieve total memory metrics for a given droplet, send a GET request to /v2/monitoring/metrics/droplet/memory_total.

To list all your projects, send a GET request to /v2/projects.

To create a project, send a POST request to /v2/projects. Mockzilla mock: no signup, no API key.

To get your default project, send a GET request to /v2/projects/default.

To update only specific attributes of your default project, send a PATCH request to /v2/projects/default. At least one of the following attributes needs to be sent.

To update you default project, send a PUT request to /v2/projects/default. All of the following attributes must be sent.

To list all your resources in your default project, send a GET request to /v2/projects/default/resources.

To assign resources to your default project, send a POST request to /v2/projects/default/resources. Served by the Mockzilla mock runtime.

To delete a project, send a DELETE request to /v2/projects/$PROJECT_ID. To be deleted, a project must not have any resources assigned to it. Any existing resources must first be reassigned or destroyed, or you will receive a 412 error. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully.

To get a project, send a GET request to /v2/projects/$PROJECT_ID.

To update only specific attributes of a project, send a PATCH request to /v2/projects/$PROJECT_ID. At least one of the following attributes needs to be sent.

To update a project, send a PUT request to /v2/projects/$PROJECT_ID. All of the following attributes must be sent.

To list all your resources in a project, send a GET request to /v2/projects/$PROJECT_ID/resources. Mocked via Mockzilla.

To assign resources to a project, send a POST request to /v2/projects/$PROJECT_ID/resources.

To list all of the regions that are available, send a GET request to /v2/regions. The response will be a JSON object with a key called regions. The value of this will be an array of region objects, each of which will contain the standard region attributes.

To delete your container registry, destroying all container image data stored in it, send a DELETE request to /v2/registry.

To get information about your container registry, send a GET request to /v2/registry.

To create your container registry, send a POST request to /v2/registry. The name becomes part of the URL for images stored in the registry. For example, if your registry is called example, an image in it will have the URL registry.digitalocean.com/example/image:tag. Available as a Mockzilla mock endpoint.

In order to access your container registry with the Docker client or from a Kubernetes cluster, you will need to configure authentication. The necessary JSON configuration can be retrieved by sending a GET request to /v2/registry/docker-credentials. The response will be in the format of a Docker config.json file. To use the config in your Kubernetes cluster, create a Secret with: kubectl create secret generic docr \ --from-file=.dockerconfigjson=config.json \ --type=kubernetes.io/dockerconfigjson By default, the returned credentials have read-only access to your registry and cannot be used to push images. This is appropriate for most Kubernetes clusters. To retrieve read/write credentials, suitable for use with the Docker client or in a CI system, read_write may be provided as query parameter. For example: /v2/registry/docker-credentials?read_write=true By default, the returned credentials will not expire. To retrieve credentials with an expiry set, expiry_seconds may be provided as a query parameter. For example: /v2/registry/docker-credentials?expiry_seconds=3600 will return credentials that expire after one hour.

This endpoint serves to provide additional information as to which option values are available when creating a container registry. There are multiple subscription tiers available for container registry. Each tier allows a different number of image repositories to be created in your registry, and has a different amount of storage and transfer included. There are multiple regions available for container registry and controls where your data is stored. To list the available options, send a GET request to /v2/registry/options.

A subscription is automatically created when you configure your container registry. To get information about your subscription, send a GET request to /v2/registry/subscription.

After creating your registry, you can switch to a different subscription tier to better suit your needs. To do this, send a POST request to /v2/registry/subscription.

To validate that a container registry name is available for use, send a POST request to /v2/registry/validate-name. If the name is both formatted correctly and available, the response code will be 204 and contain no body. If the name is already in use, the response will be a 409 Conflict. Mockzilla mock: no signup, no API key.

To get information about the currently-active garbage collection for a registry, send a GET request to /v2/registry/$REGISTRY_NAME/garbage-collection.

Garbage collection enables users to clear out unreferenced blobs (layer & manifest data) after deleting one or more manifests from a repository. If there are no unreferenced blobs resulting from the deletion of one or more manifests, garbage collection is effectively a noop. See here for more information about how and why you should clean up your container registry periodically. To request a garbage collection run on your registry, send a POST request to /v2/registry/$REGISTRY_NAME/garbage-collection. This will initiate the following sequence of events on your registry. Set the registry to read-only mode, meaning no further write-scoped JWTs will be issued to registry clients. Existing write-scoped JWTs will continue to work until they expire which can take up to 15 minutes. Wait until all existing write-scoped JWTs have expired. Scan all registry manifests to determine which blobs are unreferenced. Delete all unreferenced blobs from the registry. Record the number of blobs deleted and bytes freed, mark the garbage collection status as success. Remove the read-only mode restriction from the registry, meaning write-scoped JWTs will once again be issued to registry clients.

To cancel the currently-active garbage collection for a registry, send a PUT request to /v2/registry/$REGISTRY_NAME/garbage-collection/$GC_UUID and specify one or more of the attributes below.

To get information about past garbage collections for a registry, send a GET request to /v2/registry/$REGISTRY_NAME/garbage-collections.

This endpoint has been deprecated in favor of the List All Container Registry Repositories [V2] endpoint. To list all repositories in your container registry, send a GET request to /v2/registry/$REGISTRY_NAME/repositories. Served by the Mockzilla mock runtime.

To list all repositories in your container registry, send a GET request to /v2/registry/$REGISTRY_NAME/repositoriesV2.

To list all manifests in your container registry repository, send a GET request to /v2/registry/$REGISTRY_NAME/repositories/$REPOSITORY_NAME/digests. Note that if your repository name contains / characters, it must be URL-encoded in the request URL. For example, to list manifests for registry.digitalocean.com/example/my/repo, the path would be /v2/registry/example/repositories/my%2Frepo/digests.

To delete a container repository manifest by digest, send a DELETE request to /v2/registry/$REGISTRY_NAME/repositories/$REPOSITORY_NAME/digests/$MANIFEST_DIGEST. Note that if your repository name contains / characters, it must be URL-encoded in the request URL. For example, to delete registry.digitalocean.com/example/my/repo@sha256:abcd, the path would be /v2/registry/example/repositories/my%2Frepo/digests/sha256:abcd. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully.

To list all tags in your container registry repository, send a GET request to /v2/registry/$REGISTRY_NAME/repositories/$REPOSITORY_NAME/tags. Note that if your repository name contains / characters, it must be URL-encoded in the request URL. For example, to list tags for registry.digitalocean.com/example/my/repo, the path would be /v2/registry/example/repositories/my%2Frepo/tags.

To delete a container repository tag, send a DELETE request to /v2/registry/$REGISTRY_NAME/repositories/$REPOSITORY_NAME/tags/$TAG. Note that if your repository name contains / characters, it must be URL-encoded in the request URL. For example, to delete registry.digitalocean.com/example/my/repo:mytag, the path would be /v2/registry/example/repositories/my%2Frepo/tags/mytag. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully. Mocked via Mockzilla.

To retrieve a list of all Droplets that are co-located on the same physical hardware, send a GET request to /v2/reports/droplet_neighbors_ids. The results will be returned as a JSON object with a key of neighbor_ids. This will be set to an array of arrays. Each array will contain a set of Droplet IDs for Droplets that share a physical server. An empty array indicates that all Droplets associated with your account are located on separate physical hardware.

To list all of the reserved IPs available on your account, send a GET request to /v2/reserved_ips.

On creation, a reserved IP must be either assigned to a Droplet or reserved to a region. To create a new reserved IP assigned to a Droplet, send a POST request to /v2/reserved_ips with the droplet_id attribute. To create a new reserved IP reserved to a region, send a POST request to /v2/reserved_ips with the region attribute. Note: In addition to the standard rate limiting, only 12 reserved IPs may be created per 60 seconds.

To delete a reserved IP and remove it from your account, send a DELETE request to /v2/reserved_ips/$RESERVED_IP_ADDR. A successful request will receive a 204 status code with no body in response. This indicates that the request was processed successfully.

To show information about a reserved IP, send a GET request to /v2/reserved_ips/$RESERVED_IP_ADDR. Available as a Mockzilla mock endpoint.

To retrieve all actions that have been executed on a reserved IP, send a GET request to /v2/reserved_ips/$RESERVED_IP/actions.

To initiate an action on a reserved IP send a POST request to /v2/reserved_ips/$RESERVED_IP/actions. In the JSON body to the request, set the type attribute to on of the supported action types: | Action | Details |------------|-------- | assign | Assigns a reserved IP to a Droplet | unassign | Unassign a reserved IP from a Droplet

To retrieve the status of a reserved IP action, send a GET request to /v2/reserved_ips/$RESERVED_IP/actions/$ACTION_ID.

To list all of available Droplet sizes, send a GET request to /v2/sizes. The response will be a JSON object with a key called sizes. The value of this will be an array of size objects each of which contain the standard size attributes.

To list all of the snapshots available on your account, send a GET request to /v2/snapshots. The response will be a JSON object with a key called snapshots. This will be set to an array of snapshot objects, each of which will contain the standard snapshot attributes. Filtering Results by Resource Type It's possible to request filtered results by including certain query parameters. List Droplet Snapshots To retrieve only snapshots based on Droplets, include the resource_type query parameter set to droplet. For example, /v2/snapshots?resource_type=droplet. List Volume Snapshots To retrieve only snapshots based on volumes, include the resource_type query parameter set to volume. For example, /v2/snapshots?resource_type=volume. Mockzilla mock: no signup, no API key.

Both Droplet and volume snapshots are managed through the /v2/snapshots/ endpoint. To delete a snapshot, send a DELETE request to /v2/snapshots/$SNAPSHOT_ID. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed.

To retrieve information about a snapshot, send a GET request to /v2/snapshots/$SNAPSHOT_ID. The response will be a JSON object with a key called snapshot. The value of this will be an snapshot object containing the standard snapshot attributes.

To list all of your tags, you can send a GET request to /v2/tags.

To create a tag you can send a POST request to /v2/tags with a name attribute.

A tag can be deleted by sending a DELETE request to /v2/tags/$TAG_NAME. Deleting a tag also untags all the resources that have previously been tagged by the Tag. Served by the Mockzilla mock runtime.

To retrieve an individual tag, you can send a GET request to /v2/tags/$TAG_NAME.

Resources can be untagged by sending a DELETE request to /v2/tags/$TAG_NAME/resources with an array of json objects containing resource_id and resource_type attributes. Currently only untagging of Droplets, Databases, Images, Volumes, and Volume Snapshots is supported. resource_type is expected to be the string droplet, database, image, volume or volume_snapshot. resource_id is expected to be the ID of the resource as a string.

Resources can be tagged by sending a POST request to /v2/tags/$TAG_NAME/resources with an array of json objects containing resource_id and resource_type attributes. Currently only tagging of Droplets, Databases, Images, Volumes, and Volume Snapshots is supported. resource_type is expected to be the string droplet, database, image, volume or volume_snapshot. resource_id is expected to be the ID of the resource as a string.

To list all of the Uptime checks on your account, send a GET request to /v2/uptime/checks.

To create an Uptime check, send a POST request to /v2/uptime/checks specifying the attributes in the table below in the JSON body. Mocked via Mockzilla.

To delete an Uptime check, send a DELETE request to /v2/uptime/checks/$CHECK_ID. A 204 status code with no body will be returned in response to a successful request. Deleting a check will also delete alerts associated with the check.

To show information about an existing check, send a GET request to /v2/uptime/checks/$CHECK_ID.

To update the settings of an Uptime check, send a PUT request to /v2/uptime/checks/$CHECK_ID.

To list all of the alerts for an Uptime check, send a GET request to /v2/uptime/checks/$CHECK_ID/alerts.

To create an Uptime alert, send a POST request to /v2/uptime/checks/$CHECK_ID/alerts specifying the attributes in the table below in the JSON body. Available as a Mockzilla mock endpoint.

To delete an Uptime alert, send a DELETE request to /v2/uptime/checks/$CHECK_ID/alerts/$ALERT_ID. A 204 status code with no body will be returned in response to a successful request.

To show information about an existing alert, send a GET request to /v2/uptime/checks/$CHECK_ID/alerts/$ALERT_ID.

To update the settings of an Uptime alert, send a PUT request to /v2/uptime/checks/$CHECK_ID/alerts/$ALERT_ID.

To show information about an existing check's state, send a GET request to /v2/uptime/checks/$CHECK_ID/state.

Block storage volumes may also be deleted by name by sending a DELETE request with the volume's name and the region slug for the region it is located in as query parameters to /v2/volumes?name=$VOLUME_NAME&region=nyc1. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data. Mockzilla mock: no signup, no API key.

To list all of the block storage volumes available on your account, send a GET request to /v2/volumes. Filtering Results By Region The region may be provided as query parameter in order to restrict results to volumes available in a specific region. For example: /v2/volumes?region=nyc1 By Name It is also possible to list volumes on your account that match a specified name. To do so, send a GET request with the volume's name as a query parameter to /v2/volumes?name=$VOLUME_NAME. Note: You can only create one volume per region with the same name. By Name and Region It is also possible to retrieve information about a block storage volume by name. To do so, send a GET request with the volume's name and the region slug for the region it is located in as query parameters to /v2/volumes?name=$VOLUME_NAME&region=nyc1.

To create a new volume, send a POST request to /v2/volumes. Optionally, a filesystem_type attribute may be provided in order to automatically format the volume's filesystem. Pre-formatted volumes are automatically mounted when attached to Ubuntu, Debian, Fedora, Fedora Atomic, and CentOS Droplets created on or after April 26, 2018. Attaching pre-formatted volumes to Droplets without support for auto-mounting is not recommended.

To initiate an action on a block storage volume by Name, send a POST request to ~/v2/volumes/actions. The body should contain the appropriate attributes for the respective action. Attach a Block Storage Volume to a Droplet | Attribute | Details | | ----------- | ------------------------------------------------------------------- | | type | This must be attach | | volume_name | The name of the block storage volume | | droplet_id | Set to the Droplet's ID | | region | Set to the slug representing the region where the volume is located | Each volume may only be attached to a single Droplet. However, up to five volumes may be attached to a Droplet at a time. Pre-formatted volumes will be automatically mounted to Ubuntu, Debian, Fedora, Fedora Atomic, and CentOS Droplets created on or after April 26, 2018 when attached. On older Droplets, additional configuration is required. Remove a Block Storage Volume from a Droplet | Attribute | Details | | ----------- | ------------------------------------------------------------------- | | type | This must be detach | | volume_name | The name of the block storage volume | | droplet_id | Set to the Droplet's ID | | region | Set to the slug representing the region where the volume is located |

To delete a volume snapshot, send a DELETE request to /v2/snapshots/$SNAPSHOT_ID. A status of 204 will be given. This indicates that the request was processed successfully, but that no response body is needed.

To retrieve the details of a snapshot that has been created from a volume, send a GET request to /v2/volumes/snapshots/$SNAPSHOT_ID. Served by the Mockzilla mock runtime.

To delete a block storage volume, destroying all data and removing it from your account, send a DELETE request to /v2/volumes/$VOLUME_ID. No response body will be sent back, but the response code will indicate success. Specifically, the response code will be a 204, which means that the action was successful with no returned body data.

To show information about a block storage volume, send a GET request to /v2/volumes/$VOLUME_ID.

To retrieve all actions that have been executed on a volume, send a GET request to /v2/volumes/$VOLUME_ID/actions.

To initiate an action on a block storage volume by Id, send a POST request to ~/v2/volumes/$VOLUME_ID/actions. The body should contain the appropriate attributes for the respective action. Attach a Block Storage Volume to a Droplet | Attribute | Details | | ---------- | ------------------------------------------------------------------- | | type | This must be attach | | droplet_id | Set to the Droplet's ID | | region | Set to the slug representing the region where the volume is located | Each volume may only be attached to a single Droplet. However, up to seven volumes may be attached to a Droplet at a time. Pre-formatted volumes will be automatically mounted to Ubuntu, Debian, Fedora, Fedora Atomic, and CentOS Droplets created on or after April 26, 2018 when attached. On older Droplets, additional configuration is required. Remove a Block Storage Volume from a Droplet | Attribute | Details | | ---------- | ------------------------------------------------------------------- | | type | This must be detach | | droplet_id | Set to the Droplet's ID | | region | Set to the slug representing the region where the volume is located | Resize a Volume | Attribute | Details | | -------------- | ------------------------------------------------------------------- | | type | This must be resize | | size_gigabytes | The new size of the block storage volume in GiB (1024^3) | | region | Set to the slug representing the region where the volume is located | Volumes may only be resized upwards. The maximum size for a volume is 16TiB.

To retrieve the status of a volume action, send a GET request to /v2/volumes/$VOLUME_ID/actions/$ACTION_ID. Mocked via Mockzilla.

To retrieve the snapshots that have been created from a volume, send a GET request to /v2/volumes/$VOLUME_ID/snapshots.

To create a snapshot from a volume, sent a POST request to /v2/volumes/$VOLUME_ID/snapshots.

To list all of the VPCs on your account, send a GET request to /v2/vpcs.

To create a VPC, send a POST request to /v2/vpcs specifying the attributes in the table below in the JSON body. Note: If you do not currently have a VPC network in a specific datacenter region, the first one that you create will be set as the default for that region. The default VPC for a region cannot be changed or deleted.

To delete a VPC, send a DELETE request to /v2/vpcs/$VPC_ID. A 204 status code with no body will be returned in response to a successful request. The default VPC for a region can not be deleted. Additionally, a VPC can only be deleted if it does not contain any member resources. Attempting to delete a region's default VPC or a VPC that still has members will result in a 403 Forbidden error response. Available as a Mockzilla mock endpoint.

To show information about an existing VPC, send a GET request to /v2/vpcs/$VPC_ID.

To update a subset of information about a VPC, send a PATCH request to /v2/vpcs/$VPC_ID.

To update information about a VPC, send a PUT request to /v2/vpcs/$VPC_ID.

To list all of the resources that are members of a VPC, send a GET request to /v2/vpcs/$VPC_ID/members. To only list resources of a specific type that are members of the VPC, included a resource_type query parameter. For example, to only list Droplets in the VPC, send a GET request to /v2/vpcs/$VPC_ID/members?resource_type=droplet.