Skip to main content
Version: 0.0.1

Journyx REST API

Welcome to the API Reference section of the Journyx JX / PX technical documentation.

Before diving into the API Reference, make sure you have reviewed the Introduction and Core Concepts sections as these contain essential background information.

Review the Collections page

A key part of using the Journyx API is understanding the Collections concept. Collections are groups of similar objects, such as users, projects, or time entries, and they have common endpoints and behaviors relating to selecting fields, filtering, sorting, and pagination. These features are explained in detail on the Collections page.

This API Reference section documents the recommended API to access your Journyx server data. Please note that as discussed on the Types of APIs page, there are other APIs and endpoints available in a Journyx server instance that are not covered in this section, such as the Legacy SOAP API also known as "jxAPI", as well as the Reportlink API.

Finding what you need

The sidebar on the left lists all the available endpoints, grouped by theme or category. Click on an endpoint to view its documentation. You can also use the Search bar in the upper right to locate a specific endpoint.

The API Reference section primarily documents the Rest API and endpoints under the /api/v1 prefix, whereas the other APIs, such as the legacy jxAPI and the Reportlink API, fall under different prefixes or URL paths.

Most of the GET endpoints under the /api/v1 prefix, other than ones designed to retrieve individual objects, follow the Collection conventions, though there are exceptions to this. These exceptions are generally marked as "non-RESTful" in this API Reference section either because they are not paginated, don't support filtering, or because they do not follow REST conventions such as only using POST to create new objects.

Using this reference

This reference section is generated from an OpenAPI specification file. You can download the raw OpenAPI specification file from the link on the Introduction page.

Each endpoint lists the following key elements:

  • The URL or server path to access the resource

  • The HTTP method required, e.g. GET, POST or DELETE

  • Required elements of the request, including headers, request body format (e.g. application/json), and required fields or keys in the body data, also known as the request schema.

  • Possible responses, including both success and error responses, and their HTTP response codes, and the schema (format) of any data returned.

All the request and response schemas are listed in their own sidebar category in addition to being shown under each relevant endpoint.

A quick word about internal IDs and example values used in the schema descriptions. Most user-created (non-built-in) objects have a generated universally unique identifier (UUID) as their primary key, which is a 36-character string of hexadecimal characters. However, many built-in objects have a fixed, hard-coded ID value. Both generated UUIDs and the hard-coded IDs may be used in different examples throughout the documentation, but this is not meant to imply that only one format or another is accepted. Most endpoints do not allow you to specify your own IDs when creating objects.

Authentication​

Authentication is described in more detail in the dedicated Authentication section of the documentation.

Using the wtsession cookie header is the recommended way to authenticate your Journyx API requests. The wtsession cookie is a limited-time authentication token that can be sent in the Cookie header of your requests.

You obtain a wtsession cookie by calling the Sign-in endpoint with a username and either a password or an API Key. The server will respond with a Set-Cookie header that contains the wtsession cookie. Then in subsequent requests, you include the wtsession cookie in the Cookie header.

API Keys are the recommended way to authenticate your Journyx API requests, but it's important to understand that, at least in this implementation, they merely replace the direct use of passwords. The actual authentication mechanism used in API requests must be either a wtsession cookie, or else the HTTP Basic authentication scheme, and either of those methods will accept either passwords or API Keys, assuming API Keys have been enabled in the System Settings.

HTTP Basic Authentication is also available. Please see the Authentication section for complete details.

Security Scheme Type:

apiKey

Header parameter name:

wtsession