Bulk creation API doesn't behave consistently

APIs & Connectors
1

Hello Visier developer community ,

After using the endpoint POST /v2/admin/users we have experienced that the endpoint doesn’t behave consistently when the field username is populated with lower or capital case characters. For instance if we call the endpoint with the following payload for the first time:

{
	"users": [
		{
			"username": "12345@12345.ABCD",
			"displayName": "Test Tester",
			"employeeId": "12345@12345.ABCD",
			"accountEnabled": true,
			"email": "tester@test.com"
		}
	]
}

the user will be successfully created and we’ll get the following response:

{
	"successes": [
		{
			"userId": "<VALID_USER_ID>",
			"username": "12345@12345.abcd",
			"displayName": "Test Tester",
			"employeeId": "12345@12345.ABCD",
			"accountEnabled": "true",
			"email": "tester@test.com"
		}
	],
	"failures": []
}

If we call the same endpoint (because the first one timed out on the client side) with the same payload again, we’ll get a payload where the userId field is not populated. We shouldn’t forget here that the field username is in capital case (as in the original request). Here’s a sample output:

{
	"successes": [],
	"failures": [
		{
			"userId": "",
			"userName": "12345@12345.ABCD",
			"displayName": "Test Tester",
			"error": {
				"message": "Bad request: Username [12345@12345.ABCD] already exists.",
				"rci": "RCIY0700052"
			}
		}
	]
}

So the API correctly says that a user with the same username is already created, but unfortunately the field userId isn’t populated. Nonetheless, if we call the endpoint with a payload where the username field is in lower case , namely "userName": "12345@12345.abcd", we get the following response:

{
	"successes": [],
	"failures": [
		{
			"userId": "<VALID_JSON>",
			"userName": "12345@12345.abcd",
			"displayName": "Test Tester",
			"error": {
				"message": "Bad request: Username [12345@12345.abcd] already exists.",
				"rci": "RCIY0700052"
			}
		}
	]
}

IMHO the endpoint should behave consistently and it shouldn’t change the case of the provided username, because the consumer can have this value cached or stored.

Best regards,

2

Hello,
The committed username is in lower case, which explains the behavior but doesn’t justify it. I’ve created a bug with the information you have provided and it is added to the backlog to be addressed.

Thanks for providing such clear repro steps.

Regards,
/Henrik