This page is in Draft and is not visible on the sitemap or in dynamic content indexes.
You can find detailed documentation on all the APIs we offer in the API Catalogue. Registered users can also sign in to the Developer Area to interact with any APIs they have purchased through a swagger UI.
If you have any other queries regarding API usage then please get in touch.
The APIs are designed to have predictable, resource-oriented URLs that make writing applications easy. We have embraced the core principles of REST and use standard HTTP response codes to indicate the success or failure of API requests.
Our APIs use appropriate HTTP verbs for every action.
In the majority of cases, both request body data and response data are generally formatted as JSON. Refer to the API documentation in the API Catalogue to see where other formats or media types are supported.
Authenticate your account when using the API by including your secret API key in the request. You can manage your API keys in the Developer area, be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such GitHub, client-side code, and so forth. API requests without authentication will fail.
To ensure data privacy, only calls made over HTTPS are supported. So all requests to an API endpoint will have to be SSL/TLS compliant, furthermore only TLSv1.2 or higher protocols are supported. Calls made over plain HTTP will fail.
Our APIs communicate errors through standard HTTP status codes with details supplied in JSON objects. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that failed given the information provided (eg, a required parameter was omitted), and codes in the 5xx range indicate an error at our end of the process.
Several of our APIs perform compute intensive mathematical operations that can take an extended period of time. These APIs use the Long Running Operations (LRO) pattern as documented in Microsoft REST API Guidelines.
APIs that implement the LRO pattern obey the following protocol when a client application initiates an API call:
Where applicable, API resources have support for bulk fetches via "list" API methods. These list API methods share a common structure, taking at least these three parameters: limit, starting_after, and ending_before.
We strive to make API changes backwards-compatible. When we make breaking changes, we increment the version.
All requests must explicitly specify the API version otherwise an 406 Not Acceptable response will be returned.
When you first adopt an API, using the latest version is recommended where possible. The API Catalogue contains information and documentation for all version releases.