Contact usRequest a demo

The Unblu web API is aligned to REST services.

The Unblu web API provides a set of URLs that you can send HTTP requests with a JSON payload to for the purpose of triggering certain behavior in Unblu.

To go directly to the web API documentation: Unblu web API

OpenAPI/Swagger specification

Wikipedia:

The OpenAPI Specification, originally known as the Swagger Specification, is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful Web services.

Starting with Unblu 5 an OpenAPI specification describing all REST services can be used to generate client applications that call the Unblu server. Integration with other tools supporting this standard is also easier.

Request URL structure

The technical details for each service endpoint can found here or in the OpenAPI specification, but all URLs always look the same:

<prefix>/rest/<version>/<service name><parameters>

Where:

<prefix>: base path of the installation

  • Unblu Cloud: https://start.unblu.com/unblu

  • On-premises: depends on the installation and the entry path used:

<version>: version of the API, see API Versioning.

<service name>: name of the service. The services are grouped by topic. Examples for users: /users/findByUsername, /users/create …​

<parameters>: parameters of the service. Depending on the case, these can be path parameters (such as /webhookcalllogs/getCallLogForWebhookRegistration/{registrationId}) or query parameters (such as /accounts/findByName?name=)

API versioning

Version identifier in the URL

The version identifier (v2, v3 …​) is part of the URL for each service (see Request URL structure above). This way, one Unblu server installation can provide multiple API versions.

Version life cycle

The version life cycle of the Unblu web API isn’t bound to the Unblu version:

  • A new API version is introduced as soon as a breaking change is introduced into the API

  • If no breaking change is introduced, the same API version can be used over multiple Unblu (major) versions (5.x, 6.x, 7.x etc.)

  • When a new API version is introduced, the old version is kept for the duration of one major version life cycle to ensure compatibility with existing consumers of the old API

For example, Unblu 5 shipped with version v2 of the API. Unblu 6 introduced changes that weren’t backwards compatible with v2.

  • A new version v3 was introduced. v2 and v1 were maintained as compatibility layers.

  • With Unblu 6, all versions were available and could be used in parallel.

  • With the introduction of Unblu 7, the v1 version is no longer available.