${PRODUCT_NAME} - Middleware API (1.0.0)

Download OpenAPI specification:Download

The middleware API of ${PRODUCT_NAME} allows to manipulate the user accounts, filter profiles, devices, and all notifications of the user stored in the notification center.

Authentication

XApiKey

The API key for the provisioning API as specified in the server configuration.

Security Scheme Type API Key
Header parameter name: X-API-Key

Session

The session API to setup and destroy server-side user sessions.

Authenticate a user with password.

post /session/login
/$href(/api/v1)/session/login

Authenticates a user, and creates a new server session for the user specified in the request body. The session identifier will be stored in the response cookie protect-sid. If the user has two-factor authentication enabled, a token will be sent to the email address or phone number. That token needs to be sent with the route /session/login/token to fully authenticate the user.

Request Body schema:

The identifier of the user and the password needed for authentication.

password
required
string >= 6 characters

The password of the user.

username
required
string [ 1 .. 50 ] characters

The middleware identifier of the user.

Responses

200

User authentication successful. In case of two-factor authentication, the server awaits sending the token now (see /session/login/token).

400

Malformed request body data.

401

Invalid user name, or wrong password.

500

Unexpected error (internal server error).

Request samples

Content type
Copy
Expand all Collapse all
{
  • "password": "string",
  • "username": "string"
}

Response samples

Content type
application/json
Copy
Expand all Collapse all
{ }

Send another token for two-factor authentication.

post /session/login/requesttoken
/$href(/api/v1)/session/login/requesttoken

If the user authenticated with the route /session/login has two-factor authentication enabled, a token has been sent to the email address or phone number. This route allows to generate and send another token to the user which will be expected to be returned with the route /session/login/token afterwards.

Responses

200

New token has been sent successfully.

401

Unauthorized (missing or invalid session identifier, or missing or wrong API token).

500

Unexpected error (internal server error).

Response samples

Content type
application/json
Copy
Expand all Collapse all
{ }

Authenticate a user with the generated two-factor authentication token.

post /session/login/token
/$href(/api/v1)/session/login/token

If the user authenticated with the route /session/login has two-factor authentication enabled, a token has been sent to the email address or phone number. That token needs to be sent with this route to fully authenticate the user.

Request Body schema:

The token needed for authentication.

token
required
string >= 4 characters

The authentication token that has been sent to the user.

Responses

200

User authentication successful.

400

Malformed request body data.

401

Invalid user name, or wrong token.

500

Unexpected error (internal server error).

Request samples

Content type
Copy
Expand all Collapse all
{
  • "token": "string"
}

Response samples

Content type
application/json
Copy
Expand all Collapse all
{ }

Invalidate a server session.

post /session/logout
/$href(/api/v1)/session/logout

Invalidates the server session identified by the request cookie protect-sid.

Responses

200

Server session has been invalidated successfully.

500

Unexpected error (internal server error).

Response samples

Content type
application/json
Copy
Expand all Collapse all
{ }

Users

The user API to manage global settings of a user account.

Return the static configuration of an existing user account.

get /user/{user_id}/config
/$href(/api/v1)/user/{user_id}/config

Returns the static configuration (classification platforms, categories, and presets) of an existing user account, according to the device mode.

Authorizations:
path Parameters
user_id
required
string

The middleware identifier of the user. The API supports several ways to identify the user sending a request:

  • URL Parameter: The user identifier is contained directly in this parameter, e.g. the user john in the API request GET $href(/api/v1/user/john/settings). This type of identification requires to supply an API token. This API token needs to be passed in the HTTP header field X-API-Key: <token>, or in the HTTP header field Authorization: Token <token> (note that the keyword Token is required in front of the actual token).

  • Identity Server: A user can be identified by using the special user identifier - (a simple dash character), and an (OAuth2) access token with Token Introspection (RFC 7662) at an identity server. The access token needs to be passed as Bearer Token (RFC 6750) in the HTTP header field Authorization: Bearer <token> (note that the keyword Bearer is required in front of the actual token). This access token will be generated during login at the identity server. This kind of identification does not require an API token (X-API-Key).

  • Server Session: A user can be identified by using the special user identifier - (a simple dash character), and a session identifier in the request cookie protect-sid, e.g. in the request GET $href(/api/v1/user/-/settings). This kind of identification does not require an API token (X-API-Key).

Responses

200

User configuration found and returned successfully.

401

Unauthorized (missing or invalid session identifier, or missing or wrong API token).

404

User does not exist (wrong user identifier in URL).

500

Unexpected error (internal server error).

Response samples

Content type
application/json
Copy
Expand all Collapse all
{
  • "categories":
    [
    ],
  • "device_mode": true,
  • "engines":
    [
    ],
  • "platforms":
    [
    ],
  • "presets":
    [
    ]
}

Return the settings of an existing user account.

get /user/{user_id}/settings
/$href(/api/v1)/user/{user_id}/settings

Returns the settings of an existing user account.

Authorizations:
path Parameters
user_id
required
string

The middleware identifier of the user. The API supports several ways to identify the user sending a request:

  • URL Parameter: The user identifier is contained directly in this parameter, e.g. the user john in the API request GET $href(/api/v1/user/john/settings). This type of identification requires to supply an API token. This API token needs to be passed in the HTTP header field X-API-Key: <token>, or in the HTTP header field Authorization: Token <token> (note that the keyword Token is required in front of the actual token).

  • Identity Server: A user can be identified by using the special user identifier - (a simple dash character), and an (OAuth2) access token with Token Introspection (RFC 7662) at an identity server. The access token needs to be passed as Bearer Token (RFC 6750) in the HTTP header field Authorization: Bearer <token> (note that the keyword Bearer is required in front of the actual token). This access token will be generated during login at the identity server. This kind of identification does not require an API token (X-API-Key).

  • Server Session: A user can be identified by using the special user identifier - (a simple dash character), and a session identifier in the request cookie protect-sid, e.g. in the request GET $href(/api/v1/user/-/settings). This kind of identification does not require an API token (X-API-Key).

Responses

200

User account found and returned successfully.

401

Unauthorized (missing or invalid session identifier, or missing or wrong API token).

404

User does not exist (wrong user identifier in URL).

500

Unexpected error (internal server error).

Response samples

Content type
application/json
Copy
Expand all Collapse all
{
  • "email_2fa": "string",
  • "has_2fa": true,
  • "locale": "string",
  • "phone_2fa": "string",
  • "profile_wizard_shown": true,
  • "user_id": "string"
}

Modify the settings of an existing user account.

patch /user/{user_id}/settings
/$href(/api/v1)/user/{user_id}/settings

Modifies the settings of an existing user account.

Authorizations:
path Parameters
user_id
required
string

The middleware identifier of the user. The API supports several ways to identify the user sending a request:

  • URL Parameter: The user identifier is contained directly in this parameter, e.g. the user john in the API request GET $href(/api/v1/user/john/settings). This type of identification requires to supply an API token. This API token needs to be passed in the HTTP header field X-API-Key: <token>, or in the HTTP header field Authorization: Token <token> (note that the keyword Token is required in front of the actual token).

  • Identity Server: A user can be identified by using the special user identifier - (a simple dash character), and an (OAuth2) access token with Token Introspection (RFC 7662) at an identity server. The access token needs to be passed as Bearer Token (RFC 6750) in the HTTP header field Authorization: Bearer <token> (note that the keyword Bearer is required in front of the actual token). This access token will be generated during login at the identity server. This kind of identification does not require an API token (X-API-Key).

  • Server Session: A user can be identified by using the special user identifier - (a simple dash character), and a session identifier in the request cookie protect-sid, e.g. in the request GET $href(/api/v1/user/-/settings). This kind of identification does not require an API token (X-API-Key).

Request Body schema:

The properties to be changed for the user account. Omitted properties will not be modified.

email_2fa
string [ 1 .. 100 ] characters

The email address used to send an email with the token for two-factor authentication.

has_2fa
boolean

Whether the user will use two-factor authentication with an additional token sent to an email address or to a phone number.

locale
string [ 1 .. 32 ] characters

The locale of the user, e.g. en-US.

phone_2fa
string [ 1 .. 40 ] characters

The phone number used to send an SMS with the token for two-factor authentication.

profile_wizard_shown
boolean

Whether the initial profile wizard has been shown in the web application.

user_id
required
string [ 1 .. 50 ] characters

The middleware identifier of the user (used in the URLs of the middleware API).

Responses

200

User account updated successfully.

400

Malformed request body data.

401

Unauthorized (missing or invalid session identifier, or missing or wrong API token).

404

User does not exist (wrong user identifier in URL).

500

Unexpected error (internal server error).

Request samples

Content type
Copy
Expand all Collapse all
{
  • "email_2fa": "string",
  • "has_2fa": true,
  • "locale": "string",
  • "phone_2fa": "string",
  • "profile_wizard_shown": true,
  • "user_id": "string"
}

Response samples

Content type
application/json
Copy
Expand all Collapse all
{
  • "email_2fa": "string",
  • "has_2fa": true,
  • "locale": "string",
  • "phone_2fa": "string",
  • "profile_wizard_shown": true,
  • "user_id": "string"
}

Change the internal password of an existing user account.

patch /user/{user_id}/settings/password
/$href(/api/v1)/user/{user_id}/settings/password

Changes the internal password of an existing user account. If the user has been identified by URL parameter, or via identity server, this command allows to set the new password without having to know the current password (the property old_password in the request body will be ignored and can be omitted).

Authorizations:
path Parameters
user_id
required
string

The middleware identifier of the user. The API supports several ways to identify the user sending a request:

  • URL Parameter: The user identifier is contained directly in this parameter, e.g. the user john in the API request GET $href(/api/v1/user/john/settings). This type of identification requires to supply an API token. This API token needs to be passed in the HTTP header field X-API-Key: <token>, or in the HTTP header field Authorization: Token <token> (note that the keyword Token is required in front of the actual token).

  • Identity Server: A user can be identified by using the special user identifier - (a simple dash character), and an (OAuth2) access token with Token Introspection (RFC 7662) at an identity server. The access token needs to be passed as Bearer Token (RFC 6750) in the HTTP header field Authorization: Bearer <token> (note that the keyword Bearer is required in front of the actual token). This access token will be generated during login at the identity server. This kind of identification does not require an API token (X-API-Key).

  • Server Session: A user can be identified by using the special user identifier - (a simple dash character), and a session identifier in the request cookie protect-sid, e.g. in the request GET $href(/api/v1/user/-/settings). This kind of identification does not require an API token (X-API-Key).

Request Body schema:

The new password to be set for the user.

old_password
string >= 6 characters

The current password.

password
required
string >= 6 characters

The new password.

Responses

200

User account updated successfully.

400

Malformed request body data.

401

Unauthorized (missing or invalid session identifier, or missing or wrong API token).

404

User does not exist (wrong user identifier in URL).

500

Unexpected error (internal server error).

Request samples

Content type
Copy
Expand all Collapse all
{
  • "old_password": "string",
  • "password": "string"
}

Response samples

Content type
application/json
Copy
Expand all Collapse all
{ }

Profiles

The profile API to manage the user's filter profiles.

Create a new filter profile in an existing user account.

put /user/{user_id}/profile
/$href(/api/v1)/user/{user_id}/profile

Creates a new filter profile in an existing user account. The identifier of the new filter profile will be set to the first available free profile identifier in the user account.

Authorizations:
path Parameters
user_id
required
string

The middleware identifier of the user. The API supports several ways to identify the user sending a request:

  • URL Parameter: The user identifier is contained directly in this parameter, e.g. the user john in the API request GET $href(/api/v1/user/john/settings). This type of identification requires to supply an API token. This API token needs to be passed in the HTTP header field X-API-Key: <token>, or in the HTTP header field Authorization: Token <token> (note that the keyword Token is required in front of the actual token).

  • Identity Server: A user can be identified by using the special user identifier - (a simple dash character), and an (OAuth2) access token with Token Introspection (RFC 7662) at an identity server. The access token needs to be passed as Bearer Token (RFC 6750) in the HTTP header field Authorization: Bearer <token> (note that the keyword Bearer is required in front of the actual token). This access token will be generated during login at the identity server. This kind of identification does not require an API token (X-API-Key).

  • Server Session: A user can be identified by using the special user identifier - (a simple dash character), and a session identifier in the request cookie protect-sid, e.g. in the request GET $href(/api/v1/user/-/settings). This kind of identification does not require an API token (X-API-Key).

query Parameters
oneway
boolean

If set to true, the server response will not contain the complete settings of the filter profile but a JSON object containing the property profile_id with the profile identifier only. This can be used to reduce network traffic, and allows the server to perform optimizations in specific cases.

Request Body schema:

The properties to be set for a new profile, or to be changed in an existing filter profile. Omitted properties will be set to their default values when creating a new profile, and will not be modified when patching an existing profile.

It is possible to partially create or update embedded objects by only specifying the properties inside the embedded objects to be modified. Other properties not mentioned in the request body remain unmodified. The following methods for partial updates are supported:

  • Specify a JSON object with embedded objects containing only the properties to be updated. This method is not applicable for application/www-form-urlencoded body data (see next list item).

    • Example: Use {"homework_schedule":{"enabled":true}} to enable the homework time schedule.
    • Example: Use {"bedtime_workdays":{"days":{"fr":true}}} to enable Friday in the bedtime schedule for workdays.
  • Specify the properties to be modified with dot notation in the root object.

    • Example: Use {"homework_schedule.enabled":true} (or homework_schedule.enabled=true for application/www-form-urlencoded body data) to enable the homework time schedule.
    • Example: Use {"bedtime_workdays.days.fr":true} to enable Friday in the bedtime schedule for workdays.

It is possible to patch existing string arrays by inserting or removing individual array elements, instead of replacing the entire array.

  • Specify a JSON object with insert and delete properties (both optional). Property values can be single strings, or string arrays. The values will be inserted into or deleted from the existing array respectively.

    • Example: Use {"whitelist":{"insert":["example.org","example.com"],"delete":"example.net"}} to patch the whitelist string array.
    • Example: Use {"homework_schedule":{"categories":{"insert":"C1","delete":"C2"}}} to patch the category list of the homework schedule.
  • Specify the path to the string array property with dot notation, and the property value as JSON object with insert and delete properties.

    • Example: Use {"homework_schedule.categories":{"insert":"C1","delete":"C2"}} to patch the category list of the homework schedule.
  • Specify the insert and delete properties together with the path to the array property with dot notation.

    • Example: Use {"whitelist.insert":["example.org","example.com"],"whitelist.delete":"example.net"} to patch the whitelist string array.
    • Example: Use {"homework_schedule.categories.insert":"C1","homework_schedule.categories.delete":"C2"} to patch the category list of the homework schedule.

It is possible to patch existing string arrays by toggling array elements with a patch set notation, instead of replacing the entire array.

  • Specify a JSON object with a patch property. Property keys are the array elements to be inserted or deleted, property values are booleans specifying whether to insert (true), or remove (false) the key value.

    • Example: Use {"whitelist":{"patch":{"example.org":true,"example.net":false}}} to patch the whitelist string array.
    • Example: Use {"homework_schedule":{"categories":{"patch":{"C1":true,"C2":false}}}} to patch the category list of the homework schedule.
  • Specify the path to the string array property with dot notation, and the property value as JSON object with a patch property.

    • Example: Use {"homework_schedule.categories":{"patch":{"C1":true,"C2":false}}} to patch the category list of the homework schedule.
  • Specify the patch property together with the path to the array property with dot notation.

    • Example: Use {"whitelist.patch":{"example.org":true,"example.net":false}} to patch the whitelist string array.
    • Example: Use {"homework_schedule.categories.patch":{"C1":true,"C2":false}} to patch the category list of the homework schedule.
  • Specify the array elements to be inserted and deleted together with the path to the array property with dot-at notation. Use the at character "@" to separate property path and array element value. Everything after the first at character will be used as array element (including additional periods and at characters).

    • Example: Use {"whitelist@example.org":true,"whitelist@example.net":false} to patch the whitelist string array.
    • Example: Use {"homework_schedule.categories@C1":true,"homework_schedule.categories@C2":false} to patch the category list of the homework schedule.
avatar_version
integer >= 0

A unique positive integer for the current avatar image (can be used to bypass browser cache when getting the avatar image). Will be zero, if there is no avatar image available for the profile. Otherwise, the value of this property does not matter, especially it cannot be used to get older versions of an avatar image. This property is constant, it cannot be changed in an existing profile, and it cannot be specified to create a new profile. See route /user/{user_id}/profile/{profile_id}/avatar.

</