Getting Started

Topics

About the Daxko Operations API

The Daxko Operations API provides client applications with access to Daxko Operations data. You will see examples with a {base_url} defined throughout the documentation website. This refers to the specific URL defined for your environment. To find out what this value is, go to the API Reference page.

All requests must be made over HTTPS, and your HTTP client must be TLS 1.2 compliant.

Methods

The Daxko Operations API is a RESTful API that uses standard HTTPS requests to perform actions on a data resource. The following HTTP verbs are used:

Rate Limiting

Rate limiting is calculated based on your API user account, not your IP address. This means if you have several client applications, rate limits are shared across all of them.

In order to provide reliable and quick responses to our all of our customers, client applications are limited to making TBD requests per second and TBD requests per minute.

If you’re experiencing rate limit issues, you may want to consider caching the API responses depending on how often the API resource is likely to change. This will also improve performance in your application.

In addition, depending on your terms of service, you may also have a monthly quota set. Contact your sales representative or email api@daxko.com if you would like to adjust your monthly quota.

Responses

All responses are encoded as applications/json.

Timestamps

Timestamps are all in UTC time and follow the ISO-8601 standard unless otherwise specified.

Request Headers

The following headers must be present on all requests.

Any API resource-specific headers will be called out in the API Reference section.

Response Headers

Sorting

The sort query parameter is used to specify sorting field and order on endpoints that are supported. Each endpoint will document what fields are supported. In order to specify the sort order, you may prefix the fields with a + character for ascending sort order, and with a - for descending sort order. Omitting the prefix character from a sort field will result in the results being sorted by ascending sort order, unless otherwise documented in the API call.

Note that your HTTP client might treat the + character as a whitespace character, and as a result, it may be necessary for you to URL encode it as %2B. For example, {base_url}/v3/programs/search/offerings?sort=%2Bname will return results sort by name in ascending order.

Pagination

Resources that support pagination will allow you to page to the next page (if available), using cursor-based pagination, which is more efficient than offset-based pagination. The after parameter is returned in the response body and indicates the cursor to be used when fetching subsequent pages. A links array is also returned which contains URL links for any related URLs to this response. In particular, the link that has the rel (relation) property set to next contains the URL for the next page and eliminates the need to construct the URL yourself. This can be used, for example, as the href HTML attribute on link for a next page HTML button. The next URL link will also contain the limit and sort parameters used for the initial page request (if specified) as well as the after parameter required for fetching the next page to ensure consistent sort ordering and page size. If the next URL is missing from the links array, then there are no more results and that response is considered the last page.

Cursors should never be stored, as they can quickly become invalid as items are added or deleted.

For example, if an application wanted to display offerings with a page size of 5, sorted by name, the first request and response may look like this:

GET /v3/programs/offerings/search?keywords=swim&limit=5&ampsort=name
Host: {base_url}
Authorization: Bearer <token>

{
  "total": 38,
  "limit": 5,
  "offerings": [...],
  "after": "U2FtcGxlIE9mZmVyaW5nIE5hbWUsb2ZmZXJpbmcjOTk5OS1DQzEyMzQtUlA1Njc4",
  "links": [{
    "rel": "next",
    "href": "{base_url}/v3/programs/offerings/search?keywords=swim&limit=5&sort=name&after=U2FtcGxlIE9mZmVyaW5nIE5hbWUsb2ZmZXJpbmcjOTk5OS1DQzEyMzQtUlA1Njc4"
  }]

Error Messages

Your applications should check for error message responses and gracefully handle any that you can encounter.

Error messages have the following format

{
  "success": false,
  "errors": [
    {
      "message": "'username' should not be empty.",
      "key": "username"
    },
    ...
  ]
}

Generally, status codes in the 200 range indicate valid responses, 300 range indicate further action is need to fulfill a request, 400 indicate user error, and 500 indicate a server error was encountered.

Comments