Documentation Powered by ReDoc

${PRODUCT_NAME} - Middleware API (1.0.0)

Download OpenAPI specification:Download

Open-Xchange: info@open-xchange.com URL: https://www.open-xchange.com

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.

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:
application/json
application/json
application/x-www-form-urlencoded

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

Request samples

Content type
application/json
application/json
application/x-www-form-urlencoded
{
  • "password": "string",
  • "username": "string"
}

Response samples

Content type
application/json
{ }

Send another token for two-factor authentication.

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

Response samples

Content type
application/json
{ }

Authenticate a user with the generated two-factor authentication 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:
application/json
application/json
application/x-www-form-urlencoded

The token needed for authentication.

token
required
string >= 4 characters

The authentication token that has been sent to the user.

Responses

Request samples

Content type
application/json
application/json
application/x-www-form-urlencoded
{
  • "token": "string"
}

Response samples

Content type
application/json
{ }

Invalidate a server session.

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

Responses

Response samples

Content type
application/json
{ }

Users

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

Return the static configuration of an existing user account.

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

Authorizations:
XApiKey
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

Response samples

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

Return the settings of an existing user account.

Returns the settings of an existing user account.

Authorizations:
XApiKey
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

Response samples

Content type
application/json
{
  • "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.

Modifies the settings of an existing user account.

Authorizations:
XApiKey
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:
application/json
application/json
application/x-www-form-urlencoded

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

Request samples

Content type
application/json
application/json
application/x-www-form-urlencoded
{
  • "email_2fa": "string",
  • "has_2fa": true,
  • "locale": "string",
  • "phone_2fa": "string",
  • "profile_wizard_shown": true,
  • "user_id": "string"
}

Response samples

Content type
application/json
{
  • "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.

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:
XApiKey
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:
application/json
application/json
application/x-www-form-urlencoded

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

Request samples

Content type
application/json
application/json
application/x-www-form-urlencoded
{
  • "old_password": "string",
  • "password": "string"
}

Response samples

Content type
application/json
{ }

Profiles

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

Create a new filter profile in an existing user account.

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:
XApiKey
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:
application/json
application/json
application/x-www-form-urlencoded

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.

object

Bedtime settings in weekend nights (Friday to Saturday, and Saturday to Sunday). Only the keys fr and sa (Friday and Saturday) of the property days will have an effect. Changing the other weekday properties will not do anything. The time frame is intended to start at the respective day, and to end in the next day (property start should be in the evening, property end should be less than start).

object

Bedtime settings in nights before workdays (Sunday to Monday, ..., Thursday to Friday). Only the keys su, mo, tu, we, and th (Sunday to Thursday) of the property days will have an effect. Changing the other weekday properties will not do anything. The time frame is intended to start at the respective day, and to end in the next day (property start should be in the evening, property end should be less than start).

blacklist
Array of strings[ items non-empty ]

A list with domain names that will always be blocked, regardless of other filtering settings in the profile (except the domains listed in teh property whitelist).

categories
Array of strings[ items non-empty ]

The identifiers of all classification categories to be blocked, and of all platforms to be allowed. If this property will be set, the property preset will be set to "custom" automatically.

disabled_duration
integer >= 0

Content-based filtering will be manually disabled temporarily for this duration from now, in seconds. If set to zero, content-based filtering has not been disabled temporarily. Changing this property will automatically change the value of the property disabled_until too. The result of changing both properties at the same time is undefined.

disabled_until
integer >= 0

Content-based filtering has been manually disabled temporarily until this date and time, as UNIX timestamp in seconds (UTC, zero is 1970-01-01 at midnight). Changing this property will automatically change the value of the property disabled_duration too. The result of changing both properties at the same time is undefined.

filter_content
boolean

Whether content-based filtering is enabled.

  • If this property will be set to false, the property preset will be set to the value "none" automatically.
  • If this property will be set to true, the previous value of the property preset will be restored.
filter_security
boolean

Whether virus/malware filtering is enabled.

object

Homework time settings with categories to be blocked, and platforms to be allowed while activated.

name
string <= 50 characters

The user-defined name of the filter profile.

Array of objects (OfftimeSchedule) [ items ]

All existing offtime settings, as a dynamic array with unlimited number of elements.

pause_internet
boolean

Whether internet access is currently disabled completely.

preset
string non-empty

The identifier of a predefined set of classification categories, or "custom" for a user-defined set, or "none", if content filtering is disabled (property filter_content is false).

  • If this property will be set to an existing preset list, the property categories will be updated automatically.
  • If this property will be set to the value "none", the property filter_content will be set to false automatically (no content filtering, no blacklist or whitelist).
profile_id
required
integer >= 0

The unique identifier of the filter profile (used in the URLs of the middleware API). This property is constant, it cannot be changed in an existing profile, and it cannot be specified to create a new profile (the profile identifier will be set automatically).

user_id
required
string [ 1 .. 50 ] characters

The middleware identifier of the user owning the filter profile. This property is constant, it cannot be changed in an existing profile, and it cannot be specified to create a new profile (user will be identified via URL or session).

whitelist
Array of strings[ items non-empty ]

A list with domain names that will never be blocked, regardless of other filtering settings in the profile.

Responses

Request samples

Content type