Minddistrict API

Minddistrict offers a REST API to third party applications and platforms to access and update information in the Minddistrict platform, in a secure manner.

This REST API can be used by EHR (Electronic Health Record) systems or other information systems to add information to or get information from the Minddistrict platform. Examples of this are synchronizing client account information and synchronizing professional account information.

Definition

In this document we use the following terms:

API
An Application Programming Interface is a system interface designed to allow other digital systems to interact with the system that offers the interface. This is different from a user interface where a user interacts with a system.
REST API
A Representational state transfer application programming interface is a specific way of exposing an API to third party applications and platforms. Commonly REST APIs use the HTTP protocol.
Resource
A given logical entity in the Minddistrict platform. This can be a client, a professional or a post inside a diary of a client. Resources are described using JSON objects in the API.
Endpoint
A given URL that addresses a specific resource (like a client) or a specific aspect of this resource (like the presence indicator of a client or professional).
Consumer
Any third party application or platform accessing the API is considered to be a consumer of the API.

Note

For the rest of this document we assume that the reader is familiar with the HTTP protocol on which the REST API is based.

Use a testing application

Many resources that are created in the Minddistrict platform using the API cannot be deleted afterwards, clients are an example of this. Deleting test content from the production application is not possible. For this reason we recommend running API consumer code that is under development against a test application. To get access to a test application, please contact an account manager.

Requests to the API

To query the API send an HTTPS request to the URL of an endpoint. The endpoints will use specific HTTP methods for specific interactions.

Commonly used HTTP methods in the API
Method Explanation
GET Read the state or value of a given resource
POST Create a new resource inside a location
PATCH Modify the state or value of a given resource

Every HTTP request to the API must have an HTTP Accept header set to at least application/json:

GET /api/2 HTTP/1.1
Host: customer.minddistrict.com
Accept: application/json

The HTTP methods POST and PATCH require data to be sent in the body of the HTTP request. This data must be encoded as a JSON object with the UTF-8 charset. The values that need to be set on this object will depend on the expectations of the endpoint. When sending data, the HTTP header Content-Type must be set to application/json.

Some endpoints accept parameters in the Query String part of the URL. The Query String part of the URL is separated from the first part of the URL by a ?. Parameters can be sent using the CGI format. An example of this is a parameter name with the value value that would be encoded like this: name=value. Multiple parameters are separated by &. An example of this is: name=value&name2=value2.

Rate limiting

To ensure availability and responsiveness off the API there are limits per IP address enforced for the amount of concurrent requests, and the amount of requests per second:

Rate and connection limits
Limit Explanation
20 concurrent connections Open TCP Connections are counted even if no request active (keepalive), when using HTTP/2 active concurrent request are counted.
30 requests per second Requests are limited based on “Leaky bucket” principle. Request burst are allowed as long they are not exeeding the requests/second limit. when limit is reached, a new request is allowed after (1 / limit) seconds.

Warning

When connection or rate limit is reached new connections or requests will get fail with an error message.

Responses from the API

The API will respond to every request it gets. The HTTP status code indicates if the request was processed successfully or not.

If a request was processed successfully but the response does not contain any data in its body, its HTTP status code will be set to 204 No Content.

If a new resource was created, the HTTP status code will be set to 201 Created. In this case the response will contain an extra HTTP header Location with the URL of the newly created resource.

All other successful responses from the API return a 200 OK HTTP status code.

All responses with HTTP status codes 201 Created and 200 OK will also send back data in their bodies. The data will be encoded as a JSON object. Additionally, the HTTP header Content-Type will be set to application/json and Content-Length will be set to the numerical size of the body contained in the response.

By default the response will be encoded in UTF-8. If the original HTTP request contained an Accept-Charset HTTP header with a charset that could be satisfied, the response will be encoded in that charset. The charset used will be announced in the Content-Type header of the response.

Getting human readable responses

By default the JSON object contained in the body of the response will be optimized to reduce the size of the response. To get a pretty-printed JSON object for use during testing and debugging, pass the parameter pretty=1 in the Query String.

Note

For clarity, in this document all examples will be pretty-printed, even though the parameter pretty=1 might not appear in the example.

Warning

For performance reasons, we do not recommend you to keep the pretty=1 parameter in production. The answers will be bigger and slower to generate as well.

Error messages

In case of an error the API will return a response with a corresponding HTTP status code.

Common error HTTP status codes
Code Error
400 an application error occurred
401 the user is not authorized to access the endpoint
403 the user is properly authenticated but does not have the proper authorization to access the endpoint
404 the endpoint does not exist or no longer exists
405 the given HTTP method is not available on this endpoint
406 invalid payload when a request contains data and this data is not JSON or the server failed to decode it
429 Too many requests in the last second, or to many concurrent requests, see Rate limiting
500 unexpected error (please contact us)

Error responses are similar to responses that result from successfully processed requests. They also contain a body that will be encoded as JSON, the Content-Type header will be set to application/json and the Content-Length header will be set to the numerical size of the body contained in the response.

The JSON in the body will be an object containing the following values:

code
Integer equal to the HTTP status code set in the response.
message
String in English describing the error.
extra
Optional list of objects with the values name and message describing the error.

As an example: doing a POST or PATCH request to a resource with invalid values, will result in this error response:

HTTP/1.0 400 Bad Request
Content-Length: 597
Content-Type: application/json;charset=UTF-8

{
    "code": 400,
    "extra": [
        {
            "message": "Required input is missing.",
            "name": "date_of_birth"
        },
        {
            "message": "Not a valid email address.",
            "name": "email"
        },
        {
            "message": "Must be transferred as string.",
            "name": "first_name"
        },
        {
            "message": "Unknown value.",
            "name": "gender"
        },
        {
            "message": "Required input is missing.",
            "name": "last_name"
        }
    ],
    "message": "Invalid JSON input"
}

JSON object

Data sent to the API should be encoded in a JSON object that can be put into the body of a request. Some endpoints return data, which is then also encoded in such a JSON object, contained in the body of the response.

The values on these objects can be:

Required
This is only relevant when sending data. When a value is required the value must be set. When creating a new resource, a valid value must be set in the object. To modify an existing resource a valid value only needs to be set when it needs to be changed. null is usually not an acceptable value for a required one.
Optional
The value is not required. A missing value will be represented by null. When creating a new resource, it is not required to set the value in the request. To modify an existing resource, either provide a value, or not, or set it to null in order to reset its current value. If a value is not Required, then it is Optional by default.
Read-only
The value is set by the Minddistrict platform. It cannot be set or changed via the API, but its current value can be read. If the value is Required it will be present in all responses from the API.
Setting-dependent
The value will or will not be present dependent on a setting in the configuration of the Minddistrict platform. If the Minddistrict platform is not configured to have that value it cannot be set via the API.

Any unknown value transferred to the Minddistrict platform while creating or modifying a resource will be silently ignored.

Some value types used in the Minddistrict platform cannot directly be encoded in JSON and require special treatment.

Date

Dates are encoded as a string following the ISO 8601 format yyyy-mm-dd: four digits for the year, a dash, two zero-padded digits for the month, a dash and two zero-padded digits for the day of the month.

For instance: April 25th 1983 will be transferred as the JSON string 1983-04-25.

Date with time

Dates with time information are encoded as a string following the ISO 8601 format yyyy-mm-ddTHH:MM:SS: four digits for the year, a dash, two zero-padded digits for the month, a dash, two zero-padded digits for the day of the month, the capital letter T, two zero-padded digits for the hour, a colon, two zero-padded digits for the minutes of the hour, a colon and two zero-padded digits for the seconds.

Even though the timezone is not encoded with the date and time, all time information is in UTC.

For instance, fifteen past noon of the 3rd of June 2014 will be transferred as the JSON string 2014-06-03T12:15:00.

Image or file

If a resource has an image or a file connected to it, like a profile picture for a client, this image or file is not transferred in the response to the GET request for the resource. Instead an attribute pointing to an image or a file will be encoded as a JSON object with the following attributes:

Description of a referenced file object
Name Value
@type The JSON string link
url The URL where the related image or file can be retrieved
size Size in bytes of the file as an integer
content_type Content type of the file as a Media type
filename Optional name for the file as a string

To upload a file or an image to a resource create a base 64 encoding of the file. Put that encoding in the following JSON object and use that as an attribute in the JSON object that is sent in the request body:

Description of an inline file object
Name Value
@type The JSON string base64
data The content of the file encoded in base 64 as a string
filename Optional name of the file as a string

A concrete example of this attribute:

{
    "picture":
    {
        "@type": "base64",
        "data": "z4Ag4oiIIOKEnQ=="
    }
}

Choice

Some values allow only a given set of strings. In some cases, they are pre-defined and documented here, in some other cases the values depends of the configuration of the Minddistrict platform and cannot be documented here.

For instance a gender field will only allow the four strings m, f, other and unknown as possible values.

Inline users (“user references”)

If an endpoint reports data that relates to a particular user, it needs to identify that user (for example the Changes API has to say which user is affected by each change it reports). A user can always be uniquely identified by its canonical URL, but for the same reasons that we provide access via auxiliary URLS this URL may not be convenient for systems interoperating with the Minddistrict platform.

A user reference is a JSON object that reports not just the canonical URL (under the key url), but also the user’s id field (which is optional, but is typically used to record an ID in some interoperating external system).

The type of the user (client or professional) is indicated with the @type key:

  • http://ns.minddistrict.com/user-reference/client indicates a client;
  • http://ns.minddistrict.com/user-reference/professional indicates a professional.

Some sample output containing user references can be seen in the relations.items endpoint.

In addition, an endpoint may ask for a user reference as part of its input (for example in creating a new client relation: the professional to relate to is specified with a user reference). The reference may be given by either of the fields url and id. These identification methods are discussed in more detail in connection with auxiliary URLs below.

When giving a user reference in this way you must send exactly one of the two fields url or id. You may send the @type key, but it is not required so long as the user’s type is unambiguous. (This is almost always the case: only if the endpoint can accept both clients and professionals and if the user is specified with the id field is there any possibility of confusion, since in principle a client and a professional might have the same id value.)

Examples of requests containing user references can be found in the client relations and merge endpoints.

Meta information

Some endpoints will return meta information about a resource or the endpoint itself in addition to the information retrieved. This meta information will be encoded in the attributes of the JSON object whose names start with @.

Overview of meta information
Name Value
@url Canonical URL of the resource retrieved
@type Unique resource identifier that describes the type of the resource
@changes Object containing the creation and modification date and times of the resource
@items List of contained resources
@links List of endpoints accessible from the current one

Some endpoints where a new resource can be created require the sending of corresponding @type meta information when different types of resources can be added.

Changes information

Changes information about a given resource are encoded as an object with the following attributes:

Changes information object
Name Value
creation_time The date and time on which the resource has been created
modification_time The date and time on which the resource has last been modified

Not every resource exposed via the API will have changes information as meta information.

Collection of objects

Some endpoints list a collection of resources and will return more than one object. They are usually called items. This list of objects returned will be contained in the meta information @items of the response.

Because these lists of items can be quite long these endpoints support “batch operations” with the help of Query String parameters:

Batch query string parameters
Name Value
start Skip the first X number of items
limit Limit the number of objects returned to Y

For instance this request skips the 40 first clients and returns the 20 next:

GET /api/2/c/items?start=40&limit=20 HTTP/1.1
Host: customer.minddistrict.com
Accept: application/json
Authorization: md-token gAAAAABedPwJ2akk2xhwzAo8m0iLFD4HVuFX5DAwZrI-qh6qzkOPAQb-RGnwcAGuB9Z9cQ_sOD9oCemfG-q_OPzvMCwTw7VRxfQQ1vqC9hi0Fw-o2wiZnn0fg3z3Uiz4eYvbEKdPfAf63oZzDLfs_7dETGdK_M6-qxcRLfn7rTtrOFV4xDBKuT2SZ3Y6EI8iGiaqqss0GhS5

Discovering URLs

The API is designed so that API consumers should not have to perform string manipulation on URLs (e.g. appending “diary” to a client URL to get the client’s diary URL). Instead, the response from any endpoint will include related URLs in the @links metadata: this contains a list of JSON objects with keys name and url. The documentation for an endpoint should tell you where you can discover that endpoint’s URL, under which name.

Note

Documentation of features that have not changed significantly since API version 1 may still specify URLs using string manipulation. We are working to bring these parts of the documentation up to date.

In many cases you can probably guess these URLs from their names. However we recommend you use the discovery mechanism rather than concatenating strings to generate the URLs your application will access. We do not guarantee that the URL structure will be predictable (e.g. we may choose to serve some resources from different locations for performance reasons), but you can always trust the URLs reported in @links.

As a general rule, the @links on an endpoint will always list the immediately relevant endpoints. For example the @links on the diary endpoint tell you where to list diary entries, create new entries, and get the diary configuration: these are the actions that directly involve the diary. In addition, some endpoints will list more distantly related @links, so that API consumers do not need to perform multiple requests to construct those URLS. For instance, the client endpoint also lists the diary endpoints mentioned above, for the convenience of client-oriented applications that will need to perform all these diary actions, as well as others, on behalf of a particular authenticated client.

Note

If you are developing an application that would benefit from such “shortcut” @links entries, please contact Minddistrict. The format is fully backwards-compatible, so if there is no technical obstacle, in principle there is no reason not to add such entries wherever they are useful.

Auxiliary URLs

Every user within the Minddistrict platform can be uniquely identified by their canonical URL. However a system that interoperates with the Minddistrict platform and that already maintains its own user records may not find it convenient to store these URLs for all users. For the convenience of such systems we also provide access to the client and professional APIs with the user identified by a unique identifier specified during user creation (so API consumers can specify a value that uniquely identifies a user within their own system).

These “external IDs” are optional, but a Minddistrict customer may configure their Minddistrict platform to require them: when required, they must be supplied as an attribute id when creating a new user. (This configuration is independent for clients and professionals: you may require external IDs for only clients, only professionals, or for both.) The external ID must only be unique within the user type (i.e. no two clients can have the same id) but not necessarily across all users (a client and a professional might have the same id, without implying any connection between the two users).

With this additional mechanism for uniquely identifying a particular user, as well as the canonical URLs you can access the client and professional APIs as follows ({id} stands for the user’s external ID):

  • api/2/aux/client/id/{id} (view or edit a client), when they have an id configured
  • api/2/aux/professional/id/{id} (view or edit a professional), when they have an id configured

Note

The auxiliary URLs are intended as a convenient entry-point into the API, but we encourage you to use the normal discovery mechanism for URLs deeper in the system. Because of the mechanism used to support auxiliary URLs, replacing the Minddistrict-internal identifier in e.g. a diary or tasks URL with the corresponding auxiliary URL path will probably work, but we do not officially support this access method. This means we do not exhaustively test that it works, and if it doesn’t we will not necessarily be able to give priority to support requests to fix it.

Versioning policy

The REST API is versioned. The version of the API is the number in the part of the URL following api/ (e.g. API v2 is available under urls starting with api/2/). To use a specific version of the API simply use the corresponding URL. For more information about this version of the API, please consult the corresponding documentation; note that the structure of the API typically will change, sometimes quite significantly, between versions.

Minddistrict may make multiple releases of an API version (e.g. releases 2.0, 2.1, etc of API v2); these releases do not require changes in the URLs, and are intended to be fully backward-compatible with earlier releases of the corresponding API version.

Backward compatibility

Specifically, for each release of an API version, Minddistrict:

  • will not remove any endpoints,
  • will not remove any attribute from responses,
  • will keep the meaning and format of attributes in responses consistent,
  • will continue to accept all parameters and their allowed values in requests as they were previously defined (both in the body of the request and in the query string).

Forward compatibility

New releases may, however:

  • add new endpoints,
  • add new attributes to existing responses,
  • add new entries in @links lists used for discovery,
  • add new optional parameters to existing endpoints.

API Base URL

To get the Base URL for the REST API take the application URL and append /api/2 to it. This URL will always use HTTPS.

Note

For the rest of this document we will assume that the URL of the application is: https://customer.minddistrict.com. The URL to use in order to access Minddistrict’s API for this application will then be https://customer.minddistrict.com/api/2.

Warning

This is the documentation for version 2 of the API. For a different version of the API please go to http://docs.minddistrict.com.

Sending a GET request to the base URL of the API will return a list of endpoints that can be accessed from there:

GET /api/2 HTTP/1.1
Host: customer.minddistrict.com
Accept: application/json

The response will be a list of links:

HTTP/1.0 200 Ok
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Content-Length: 516
Content-Type: application/json;charset=UTF-8

{
    "@changes": {
        "creation_time": "2020-03-20T17:23:19",
        "modification_time": "2020-03-20T17:23:19"
    },
    "@links": [
        {
            "name": "authenticate",
            "url": "https://customer.minddistrict.com/api/2/authenticate"
        }
    ],
    "@type": "http://ns.minddistrict.com/application",
    "@url": "https://customer.minddistrict.com/api/2",
    "mode": null,
    "name": "Customer application",
    "warning": null,
    "web_url": "https://customer.minddistrict.com"
}

Authentication

Choosing a user type to authenticate with

There are two types of users that can use the API.

The first type are dedicated API users who have complete access to all resources available through the API. These dedicated API users only have a system name and a token, they do not have an email or password and are visible in the application only to the application managers. The dedicated API user account cannot authenticate into the application through the web browser.

The second type of users that can use the API are simply the regular users. These are the users that do have an email and password, they can login to the web browser and they are visible to non-application-managers. These users have the exact same permissions through the web browser as through the API. So a client account accessing the API can only see their own tasks and tools. A professional account accessing the API only has access to the clients they have a therapeutic relationship with. A secretary account can see client-data like email address, name and phone number but not any therapeutic information.

For most connections to the Minddistrict API the dedicated API user is the best choice. This user has all the access needed and it does not need extra settings or configurations. However, this token gives access to a lot of privacy sensitive data so it’s important to protect it thoroughly. We recommend only using a dedicated API user if the API token is stored on a secure server, but not (for example) if the token would be stored on an end-user’s mobile device or desktop computer. For these connections to the Minddistrict API a regular user account may be a better choice. Because of the physical access to the device we should assume the owner of the device has full access to the token and the things the token gives access to. The API tokens for regular users can be revoked by the users themselves in case of theft or loss.

Tokens and using them

Authentication works by setting an HTTP header containing a token in each request to the API. This token is connected to a user account in the Minddistrict platform. This token will let the consumer of the API be authenticated as that user in the Minddistrict platform for an unlimited amount of time.

So either get a token for a dedicated API user or get a token for a regular user.

A regular user can view and revoke all their existing tokens via the preferences screen or via the API, if they know the token value. Dedicated API users can be managed via the platform configuration. Dedicated API user tokens cannot be revoked through the API. When a token is revoked any attempt to authenticate with that token will fail. When consumers of the API have a revoked token and want to perform new queries they will have to get a new token.

Only the Minddistrict platform is able to verify an existing token.

Failing to provide a valid token when sending a request to a protected endpoint will result in an unauthorized error response:

HTTP/1.0 401 Unauthorized
Content-Length: 82
Content-Type: application/json;charset=UTF-8

{
    "code": 401,
    "message": "You are unauthorized to access this resource"
}

Note

Tokens give access to the Minddistrict platform which contains privacy sensitive data. Because of this tokens must be stored securely and not be leaked to other parties.

Getting a token for a dedicated API user

An application manager can manage the dedicated API users through the API users configuration screen. When doing so the application manager will obtain the token to use with each user. The name for the API user can be set to something descriptive (“Business Intelligence”, “Client synchronization with System B”) for the convenience of the application manager: it will not be used in API calls or displayed anywhere except in the configuration screen.

API users can have one or multiple roles:

  • Manage users: users with this role will be allowed to manage client and professional accounts using the Client API and the Professional API. They will be allowed to access all the information processed by those users,
  • Data officer or Data analyst: users with this role will be allowed to use the export API.
  • API errors: users with this role will be allowed to access the client temporary access log and the API, HL7 and Koppeltaal.

An application manager can change the role for a dedicated API users.

An application manager can revoke access for dedicated API users by deleting them.

API users do not have any credentials, they cannot access or use the web interface.

Getting a token for a regular platform user

To get a new token for a regular platform user, query the authenticate endpoint. This URL is discoverable in the @links metadata of the API Base URL under the name authenticate.

The following information needs to be provided in that request:

login
The login of the user account the API consumer code wants access as, this is always an email address.
password
The password for the user account.
id

A unique identifier encoded as a string identifying the application, platform or device used to access the API.

Each user account will have at most one token per application, platform or device. If a token is requested for a specific combination of id and login and a token for that combination already exists the existing token will be revoked and a new token will be created and returned.

description
A human readable string describing the application, platform or device used to access the API.

Requesting a token like so:

POST /api/2/authenticate HTTP/1.1
Host: customer.minddistrict.com
Accept: application/json
Content-Length: 124
Content-Type: application/json

{
    "description": "Organization epd",
    "id": "epd-10232",
    "login": "wendy@example.com",
    "password": "geheim"
}

Will result in a response with a JSON object with url and token attributes:

HTTP/1.0 200 Ok
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Content-Length: 312
Content-Type: application/json;charset=UTF-8

{
    "token": "gAAAAABedPwOLhWsI8Oe9BsKmGCWClMUYajG1Z7BQ8440ehVfx42orKXl3rgn6wyLhFBIv-Gd-HNobvlj3pG84UIgGck0F5qRzJOEDJvc0Wfx1WpeHyIdKHiLpH76THBEvSlsFYDODGmNpVcxO3MUAKJYz6M0GuGHKUJr7Nz1ctA6Z8coEIFWS8fNc9H2_iR-ANf0fjThzPd",
    "url": "https://customer.minddistrict.com/api/2/c/3b8fb36b07ff4488b18322aa358d71f4"
}

The url in this JSON object will be the URL to the resource of the authenticated user. In the example above the authenticated user was a client and that’s why the URL points to the resource of this client.

If the login or password is invalid, a response with an HTTP status code set to 403 Forbidden will be returned instead:

HTTP/1.0 403 Forbidden
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Content-Length: 73
Content-Type: application/json;charset=UTF-8

{
    "code": 403,
    "message": "The login or password was incorrect"
}

Using a token

Set the Authorization HTTP header to the value md-token {your-token} where {your-token} is the token returned by the API as seen above:

GET /api/2/c/3b8fb36b07ff4488b18322aa358d71f4 HTTP/1.1
Host: customer.minddistrict.com
Accept: application/json
Authorization: md-token gAAAAABedPwIapKmjcsLCUomScSWAzxDu9m5l6nqAshiSDtaOGMa0l0ChkQ5lRr8o2OWd86ynu0rF7gKxGuDH34b5hn6R7rGCJOK5AbuieEtIDDchev2wLTHoYgb7_isQP03S1uNZbREPy6JXE0SvF-vaqtimw-9xUY5OHZ3k9PDdlIvZ29akBseqzkiy-DspLvq6BzhjM9b

Note

In this documentation, the code examples contain an example generated token. When developing code against the API it is necessary to generate a token. The example token will not work.

Revoking a token for a regular platform user

To revoke a token for a regular platform user through the API, query the logout endpoint. This URL is discoverable in the @links metadata of the user owning the token under the name logout.

Nothing is required while querying this endpoint, except using the token as authentication you want to revoke.

Revoking a token like this:

POST /api/2/c/df74250549e2460a9c8d0316253d2e62/logout HTTP/1.1
Host: customer.minddistrict.com
Accept: application/json
Authorization: md-token gAAAAABedPwIbrwwhqn8yf-iGHoOrtTPO9inT3CTMAyc1BRlEX7ngfKTbfkryOxot-K-B2m2J15IQjQukkCGOUNEnhz9_ZvSRWQMoW__A3TDOhj6okzYupqgRhSl9mpGE5xINKZzePXt9B8PNYfQteXE83KGs6KAmWSKTlfZS4rxUcuzo4Eat8_VHU5FHVm7lOPv59Ob1Fqy

Will result in an empty response upon success:

HTTP/1.0 204 No Content
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Content-Length: 0
Content-Type: text/plain;charset=UTF-8

After being revoked a token is no longer usable:

GET /api/2/c/df74250549e2460a9c8d0316253d2e62 HTTP/1.1
Host: customer.minddistrict.com
Accept: application/json
Authorization: md-token gAAAAABedPwIbrwwhqn8yf-iGHoOrtTPO9inT3CTMAyc1BRlEX7ngfKTbfkryOxot-K-B2m2J15IQjQukkCGOUNEnhz9_ZvSRWQMoW__A3TDOhj6okzYupqgRhSl9mpGE5xINKZzePXt9B8PNYfQteXE83KGs6KAmWSKTlfZS4rxUcuzo4Eat8_VHU5FHVm7lOPv59Ob1Fqy

Will result in an unauthorized error:

HTTP/1.0 401 Unauthorized
Content-Length: 82
Content-Type: application/json;charset=UTF-8

{
    "code": 401,
    "message": "You are unauthorized to access this resource"
}