Purpose and Scope

The SkyWise™ Platform API is an interface to WDT’s Weather as a Service® platform.


The API design is inspired by Heroku’s Platform API conventions, as documented on Github.



Requests must use basic authentication. Please contact WDT for a username and password (also referred to as an application ID and key). Up to five passwords may be in use at any time. This allows old passwords to be disabled without any downtime.


Requests must use HTTPS and one of the following methods. Details are provided in the endpoint descriptions.

Method Purpose
DELETE delete an existing resource
GET read a existing resource or list of resources
POST create a new resource
PUT update an existing resource (in its entirety)


Some requests may have parameters in the URI query string or request body. Details are provided in the endpoint descriptions.

Unless specified otherwise, timestamps use UTC and are represented as ISO8601 strings (i.e., YYYY-MM-DDThh:mm:ssZ). Resource identifiers use UUIDs and are represented as strings in 8-4-4-4-12 format.


Requests must use the following Accept header, unless otherwise specified in the endpoint description. See versioning for further details.

Accept: application/vnd.wdt+json; version=1

Requests must also include a basic authentication header.

Requests may use an Accept-Encoding header to obtain gzip-encoded JSON:

Accept-Encoding: gzip


Every resource is identified by a UUID. For convenience in certain cases, a human-friendly name may also identify a resource. The use of IDs should be preferred, though, to avoid ambiguity.


Endpoint descriptions provide cURL examples to facilitate experimentation. Examples use the -n option to fetch credentials from a ~/.netrc file, which should include an entry similar to the following:

machine platform.api.wdtinc.com
  login {username}
  password {token}

Rate Limits

To protect against abuse and buggy code, the API limits the number of requests each user can make within a certain time interval. More details are coming soon.


The API supports cross-origin resource sharing, so that browsers can make requests using JavaScript served from any domain.


Status Codes

The result of an API request can be identified by the status code returned.

Status Description
200 OK the request succeeded
201 Created the resource was successfully created (such as a new style)
400 Bad Request the request body is syntactically invalid
401 Unauthorized the authentication credentials are invalid, expired, or missing
403 Forbidden the authentication credentials do not provide access to specified resource
404 Not Found the specified resource does not exist
406 Not Acceptable the Accept header is invalid
422 Unprocessable Entity one or more request parameters are invalid
429 Too Many Requests the request has been rate-limited (retry later)
500 Internal Server Error something is wrong on the server (contact support if the issue persists)
503 Service Unavailable the API is unavailable (contact support if the issue persists)

Client error responses (codes 400-499) also have a JSON body that provides details about the cause of the error.

  "id": "invalid_header",
  "message": "The media type in the Accept header is unsupported.",
  "url": "http://docs.api.wdtinc.com/platform-api/en/latest/overview.html#headers"


All requests return minified JSON. Futher details and examples (pretty-printed for readability) are provided in the endpoint descriptions.

Gzip-encoding of JSON responses is supported and recommended (see headers).

Unless specified otherwise, timestamps use UTC and are represented as ISO8601 strings (i.e., YYYY-MM-DDThh:mm:ssZ). Resource identifiers use UUIDs and are represented as strings in 8-4-4-4-12 format.


Version 1 is the current and only supported major version of the API.

Every request must specify a supported major API version in the Accept header to avoid a 406 Not Acceptable error response.

Accept: application/vnd.wdt+json; version=1

Minor and micro API versions (such as 1.1 or 1.0.1) should not be used in the Accept header. These may change frequently with backward-compatible URI, parameter, or header changes.

Any future backward-incompatible changes will only occur under a new major version. This might include the addition, removal, reorganization, or renaming of endpoints.