Nimbus API

Provisioning via REST API

The Nimbus Public REST API allows to manage Nimbus Users and License contingencies. This page describes the setup and usage procedures.

PRECONDITIONS

šŸ’”If you have already set up Azure and Nimbus for using the API, you can directly go to → ā€œAvailable Methods" chapter.Ā 

On this page the following topics are covered:Ā 

  1. Check if the API was enabled on your Provisioning Tenant Settings. This feature is enabled by a Luware System Administrator.Ā 
  2. Set up the Nimbus App Registration and necessary API Permissions in Azure.Ā 
    As a Tenant Administrator you can perform these steps below in parallel.
Ā 

Step 1 - Azure Setup

āœ… Tenant Administrator: The following steps need to be done with Tenant Administrator privileges. You will grant some of the Nimbus App Permissions to be used later via the API.

Create App registration

šŸ”Ž Also see: Quickstart: Register an application with the Microsoft identity platform | Microsoft Learn

  1. Go to Portal.Azure.com
  2. In your Tenant, Create an App registration, e.g. ā€œMy Nimbus Appā€Ā 
  3. Leave the other options as they are.
Nimbus App Registration

Grant API Web Access Permissions

šŸ”Ž Also see: Configure an app to access a web API - Microsoft identity platform | Microsoft Learn

āœ… Tenant Administrator:Ā  Note that a Nimbus App must be registered at this point.

  1. Go to "API Permissions"
  2. Request new API permission by clicking ā€œAdd a permissionā€.Ā 
  3. Search for "Luware"
  4. Select the entry ā€œLuware Nimbus Loginā€ from your Nimbus App
  5. Select Application PermissionsĀ 
  6. Select the following role permissions:Ā 
    1. ā€œProvisioning.User.Createā€
    2. ā€œProvisioning.User.Deleteā€
    3. "Provisioning.Tenant.Read"Ā 
    4. ā€œProvisioning.User.Readā€
  7. Back In API Permissions, click Ā ā€œGrant Admin Consent for Luware AGā€ → Green Checkboxes signal the successful permission grant.
Successfully granted API permissions (User.Create and User.Delete)

AuthenticationĀ 

There are multiple ways to authenticate with your newly created Azure Application. The method of authentication doesn't really matter for Nimbus and depends on your Use Case and external system. We therefore only add some general recommendations and point to the Microsoft Documentation.

Public Client Application

šŸ”Ž From: Public client and confidential client applications | Microsoft LearnĀ 

Public client applications run on devices, such as desktop, browserless APIs, mobile or client-side browser apps. They can't be trusted to safely keep application secrets, so they can only access web APIs on behalf of the user. Anytime the source or compiled bytecode of a given app is transmitted anywhere it can be read, disassembled, or otherwise inspected by untrusted parties, it's a public client. As they also only support public client flows and can't hold configuration-time secrets, they can't have client secrets.

šŸ”Ž From: Public client and confidential client applications | Microsoft LearnĀ 

After determining the type of client application you're building, you can decide whether to enable the public client flow in your app registration. By default, allow public client flow in your app registration should be disabled unless you or your developer are building a public client application and using the following OAuth authorization protocol or features:

OAuth Authorization protocol/Feature Type of public client application Examples/notes
Native Authentication Microsoft Entra External ID application that requires full customization of the user interface, including design elements, logo placement, and layout, ensuring a consistent and branded look. Note: Native Authentication is only available for app registrations in Microsoft Entra External ID tenants. Learn more here
Device code flow Applications that run on input-constrained devices such as a smart TV, IoT device, or a printer Ā 
Resource owner password credential flow Applications that handles passwords users enter directly, instead of redirecting users to Entra hosted login website and letting Entra handle user password in a secure manner. Microsoft recommends you do not use the ROPC flow. In most scenarios, more secure alternatives, such as the Authorization code flow, are available and recommended.
Windows Integrated Auth Flow Desktop or mobile applications running on Windows or on a machine connected to a Windows domain (Microsoft Entra ID or Microsoft Entra joined) using Windows Integrated Auth Flow instead of Web account manager A desktop or mobile application that should be automatically signed in after the user has signed into the windows PC system with a Microsoft Entra credential
Ā 
Ā 

Confidential Client Application / Client Secret

šŸ”Ž From: Quickstart: Register an application with the Microsoft identity platform | Microsoft Learn

Sometimes called an application password, a client secret is a string value your app can use in place of a certificate to identify itself.

Client secrets are considered less secure than certificate credentials. Application developers sometimes use client secrets during local app development because of their ease of use. However, you should use certificate credentials for any of your applications that are running in production.

Ā 
  1. Select your previously registered Nimbus App.
  2. Go to Certificates & secrets > Client secrets > New client secret.
  3. Add a description for your client secret.
  4. Select an expiration for the secret or specify a custom lifetime.Ā 
  5. Click Add.
  6. 🧠 Record the Secret's value for later use within the Nimbus API.
    ā˜This secret value is never displayed again after you leave this page.

Ā From: Public client and confidential client applications | Microsoft LearnĀ 

Confidential client applications run on servers, such as web apps, web API apps, or service/daemon apps. They're considered difficult to access by users or attackers, and therefore can adequately hold configuration-time secrets to assert proof of its identity. The client ID is exposed through the web browser, but the secret is passed only in the back channel and never directly exposed.

Ā 
Ā 

Step 2 - Configure Nimbus

āœ…Checklist:

🧠 For the next steps in Nimbus you will need the Application ID of your previously registered Nimbus Application.

Ā 
  1. Log into Nimbus Admin Portal.
  2. Go to Tenant Administration Ā > Provisioning Tenant Settings > ā€œApplication Permissionsā€.
  3. Click on ā€œAddā€.Ā 
  4. Fill in the 🧠 Azure Application ID from → Chapter: Step 1 above.
  5. Define the Organization Units scope under which the Nimbus API will have access.Ā 
  6. Save and Close.Ā 
  7. Still within Admin Portal, Go to the Configuration (Admin) > Organization Units
  8. Open your Organization Unit Entry and note the GUID in the browser address bar as follows.Ā 
    🧠 Repeat this step and note down any OU ID you wanna create users in later using the API.
Identifying the Organization Unit IDs for later API usage

Step 3 - API Authentication and Usage

Now your API should be ready to use.Ā 

šŸ’”In this example we authenticate using a Confidential Client Application using Client Credentials. Of course you can use any other means of authentication as described in → Chapter: Step 1 > Authentication above.

āœ…Checklist:

  • 🧠You will need the Nimbus Application ID and the Secret of your App
  • 🧠You also need the Organization Units ID to make API calls
  • āœ… Additionally, you need the O365 IDs of the (future) users you want to provision.
Ā 
  1. Create token using OAuth 2.0. For example, to get a token using Client Credentials, choose the following:
  2. Grant type: Client Credentials
  3. Access token URL: https://login.microsoftonline.com/<tenant id>/oauth2/v2.0/token1
  4. Client ID: 🧠 Application ID of your app
  5. Client Secret: 🧠 As created in your app
  6. Scope: https://admin.{geography}-{number}.luware.cloud/.default2
  7. Client Authentication: Send as Basic Auth header

šŸ”ŽFootnotes

Ā 1 Head to your Tenant Administration and check the URL in the browser address bar. Look for the part starting with ā€œtenantId=ā€ Ā tenantId=9fce70af-a632-49ca-bc0d-53db5a21c5b3

2 The endpoont URL depends on the geographical location of your Nimbus Cluster. When you log into Nimbus Admin Portal you will be redirected to the right cluster. Check the Access URL list below as a reference.

INC Nimbus Admin URLs

Switzerland 01 https://admin.ch-01.luware.cloud/
Switzerland 02 https://admin.ch-02.luware.cloud/
Germany 01 https://admin.dewe-01.luware.cloud/
Germany 02 https://admin.dewe-02.luware.cloud/
United Kingdom 01 https://admin.ukso-01.luware.cloud/
Australia 01 https://admin.aue-01.luware.cloud/
West Europe 01 https://admin.euwe-01.luware.cloud/
East United States 01 https://admin.use-01.luware.cloud/
Nimbus Admin Panel URL

āœ… Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

Ā 

Available Methods / Commands

āœ…Before you start: API calls use the Nimbus Admin URL as endpoint. This URL depends on the geographical location of your personal Nimbus Cluster. When you log into your Nimbus Admin Portal you will be redirected to the right cluster. → See šŸ”ŽFootnotes above.

CREATE a new User

POST Create User https://admin.{geography}-{number}/api/public-api-next/user
Description

Creates a new empty (unconfigured) Nimbus user, based on the Organization Unit and O365 ID provided from existing users on your tenant.

ā˜Note: Only one user can be added per transaction.

Notes āœ… Precondition: You require the O365 ID of an existing User on your Tenant and the 🧠 OrganizationUnit ID from the (permitted) OU (→ Chapter: Step 2 above)
Body
{
 "o365Id": "<guid>",
 "organizationUnitId": "<guid>"
}
Error Codes
  • 200 - Successful response.

GET Details of Existing User

GET User Details https://admin.{geography}-{number}/api/public-api-next/user/{userO365Id}
Description

Requests the current configuration of an existing/template user.Ā 

ā˜Note: Only one user can be requested per transaction.

What is being returned?

The following user detailsĀ 

Tab / Settings Copied Settings
General User SettingsĀ 
  • Licensing - you can check either License Management or use the → GET License Usage API command to get an overview of available licenses.
  • Organization Unit affiliation
  • Modalities of tasks configured to be used for that user.
Roles User SettingsĀ 

Any assigned

Skills User SettingsĀ 
Responsibility ProfilesĀ 
  • Responsibility profiles allowing users to set their Duty States.Ā 
Not Available ReasonsĀ  All reasons that the User may choose from while being ā€œNot Availableā€ to retrieve Nimbus Tasks (e.g. in MS Teams status DND, Busy, Away).
Interact User SettingsĀ 
Assistant User Settings
Ā 
Ā 
Notes āœ… Preconditions: You need to provide the O365 ID of EXISTING (Template User) in the request body.
Body
Empty Body
Error Codes
  • 200 - Successful response

GET License Usage

GET Get License https://admin.{geography}-{number}/api/public-api-next/user/license-usage
Description

Performs a check in available Nimbus licenses, as also reflected in the Admin UI: License Management.

Returns details for all licenses:

  • License Name/Type. Refer to Nimbus Features for more details.
  • Total number of licenses purchased.
  • Total number of licenses in use.
  • Total number of licenses available.
Notes āœ… Preconditions: API Request should be based on the Tenant ID.
Body
Empty Body
Error Codes
  • 200 - Successful response

COPY an existing User

POST Copy User https://admin.{geography}-{number}/api/public-api-next/user/copy
Description

Creates a copy of an existing user, using their Nimbus User settings as template.

ā˜Note: Only one user can be copied per transaction.

What is being copied over?

Copied over are the following tabs and their settings:Ā 

Tab / Settings Copied Settings
General User SettingsĀ 

šŸ’”The new O365ID will determine the user details fields.

Roles User SettingsĀ 

Any assigned

Skills User SettingsĀ 
Responsibility ProfilesĀ 
  • Responsibility profiles allowing users to set their Duty States.Ā 

šŸ’”Note that Distribution Policies from any running Services may immediately consider the new user for task selection, depending on what the ā€œDefaultā€ and ā€œActiveā€ Nimbus profile is. See Note below.

Not Available ReasonsĀ  All reasons that the User may choose from while being ā€œNot Availableā€ to retrieve Nimbus Tasks (e.g. in MS Teams status DND, Busy, Away).
Interact User SettingsĀ 
Assistant User Settings
Ā 
Ā 
Notes

Ā āœ… Preconditions: You require both the O365 ID of EXISTING (Template User) the NEW (copy target) user for the request body.

  • Template User - Skill-based (manual) User Assignment Type requirement: The templated user must exist standalone in Nimbus and be Contact Center licensed for the necessary features to be copied. MS-Teams synched users will be rejected by the API command.
  • New User (copy target): The new User's O365 ID will be needed for this command, as retrieved from your Azure / Entra ID directory.
Body
{
 "newO365Id": "<guid>",
 "sourceO365Id": "<guid>"
}
Error Codes
  • 200 - Successful response.
  • 400 - ā€œSourceO365Idā€ or ā€œNewO365Idā€ are required. Also relates to user duplication error.
  • 401 - Missing ID (Tenant, App, etc.) with specific details provided. Also shows for permissions or access related errors.
  • 403 - Organization Unit not allowed. Also shown when no Licenses are available (License Management).
  • 404 - A source user with this "SourceO365Id" was not found.
  • 409 - User already exists.
  • 500 - Unable to check configuration

ā˜Attention: Copied Users are immediately available to Nimbus

Keep in mind that – once Nimbus ā€œlearnsā€ about a newly added user – User StateĀ checks will be immediately performed to potentially distribute newly incoming Service tasks. Depending if your source user was a productive one, the new user – Ā while Online in MS Teams – may immediately be considered as ā€œselectableā€ by Nimbus and receive calls and tasks via MS Teams, even without Nimbus being in focus for them.

šŸ”Ž The requirements for a ā€œselectableā€ Nimbus User StateĀ are:Ā 

  • The (copied) new User is known to Nimbus (O365 ID), → This happens after successful API command execution.
  • The New user is ā€œOnlineā€ in MS Teams. → Note that source Distribution Service Settings apply to verify their MS Teams status.
  • In Nimbus: User has a ā€œOn Dutyā€ Responsibility Profiles set as their default. → Depending on the source user this may already be the case.
Ā 

āœ… After Copying / Creating the User: Note that Nimbus will check for Nimbus User Permissions and request permissions from the User after their first Portal Login. You may need to inform the User about this step or check if the permissions have already granted ā€œon behalf ofā€ another Tenant Admin.

āœ… UI Refresh: To see the user in Nimbus listings, a refresh of the Nimbus UI is necessary.

Ā 

DELETE an existing User

DELETE User https://admin.{geography}-{number}/api/public-api-next/user/{userO365Id}
Description

Removes a User profile from the Nimbus Admin Portal. The User is also removed as Service Agent/Service Owner from the services where applicable.

ā˜Notes:Ā 

  • Only one user can be removed per transaction.
  • This command does NOT remove the user from your Tenant or User directory, only from Nimbus.
Ā 
Notes

āœ… Preconditions:Ā 

  • You require the O365 ID of an existing Nimbus User. Specifying a O365 ID that is not part of the Nimbus user pool will return an error.Ā 
  • Only manually added ā€œSkill-Basedā€ users are allowed to be deleted. MS-Teams synched users will be rejected by the API command.

Results:Ā 


1šŸ’”Good to know: If the user is re-added (using the exact same O365 ID) it will get all the same reporting data from before. However, any configuration data is lost and needs to be restored manually or via → COPY Existing user command.

Body
{
 "o365Id": "<guid>",
}
Error Codes
  • 200 - Successful response.

General API Notes & Error Handling

Notes

Rate Limit: There is a limit of 60 API operations/minute. The API will delay processing if this threshold is exceeded.

Ā 

General Error Codes

If not specificed in the Command, the error codes are as follows:

  • 401 - Required role missing
  • 401 - No tenant id
  • 401 - Invalid tenant id
  • 401 - No app id
  • 401 - Invalid app id
  • 401 - Provisioning Api disabled by admin
  • 401 - No app permission found for app id ({appid})
  • 403 - No authenticated user
  • 500 - Unable to check configuration

Standard Response Codes also apply. See: https://restfulapi.net/http-status-codes/

Ā 

Table of Contents