Mock sample for your project: DigitalOcean API
Integrate with "DigitalOcean API" from digitalocean.com in no time with Mockoon's ready to use mock sample
DigitalOcean API
digitalocean.com
Version: 2.0
Integrate third-party APIs faster by using "DigitalOcean API" ready-to-use mock sample. Mocking this API will help you accelerate your development lifecycles and improves your integration tests' quality and reliability by accounting for random failures, slow response time, etc.
It also helps reduce your dependency on third-party APIs: no more accounts to create, API keys to provision, accesses to configure, unplanned downtime, etc.
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 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
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.
Other APIs in the same category
watchful.li
DigitalOcean API
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 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
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.
Hetzner Cloud API
Introduction
The Hetzner Cloud API operates over HTTPS and uses JSON as its data format. The API is a RESTful API and utilizes HTTP methods and HTTP status codes to specify requests and responses.
As an alternative to working directly with our API you may also consider to use:
Our CLI program hcloud
Our library for Go
Our library for Python
Also you can find a list of libraries, tools, and integrations on GitHub.
If you are developing integrations based on our API and your product is Open Source you may be eligible for a free one time €50 (excl. VAT) credit on your account. Please contact us via the the support page on your Cloud Console and let us know the following:
The type of integration you would like to develop
Link to the GitHub repo you will use for the Project
Link to some other Open Source work you have already done (if you have done so)
Getting Started
To get started using the API you first need an API token. Sign in into the Hetzner Cloud Console choose a Project, go to Access → Tokens, and create a new token. Make sure to copy the token because it won’t be shown to you again. A token is bound to a Project, to interact with the API of another Project you have to create a new token inside the Project. Let’s say your new token is jEheVytlAoFl7F8MqUQ7jAo2hOXASztX.
You’re now ready to do your first request against the API. To get a list of all Servers in your Project, issue the example request on the right side using curl.
Make sure to replace the token in the example command with the token you have just created. Since your Project probably does not contain any Servers yet, the example response will look like the response on the right side. We will almost always provide a resource root like servers inside the example response. A response can also contain a meta object with information like Pagination.
Example Request
Changelog
You can find our changelog on our Developer Hub.
