it’s the user creation endpoint again. we’ve got a python script using the genesys-cloud-py sdk v2.0.17 to provision a few hundred users daily. it was…fine. now it’s intermittently failing with a 400 bad request on /api/v2/users. the payload isn’t changing, the auth isn’t changing. just…happening.
option a - it’s a sdk issue. maybe the library’s request formatting is slightly off in the latest version. we could roll back to v2.0.14, but that’s always a pain, and it’s rarely the sdk.
option b - the endpoint’s having a bad day. rate limits aren’t hitting, the queue isn’t backed up (checked via console), but maybe there’s some internal throttling we can’t see. we could add exponential backoff to the script, but that just masks the real problem.
the error response isn’t helpful. it’s just the generic bad request. nothing specific about which field is causing trouble. it’s really frustrating. here’s a sample error, stripped of sensitive data, of course:
{
"message": "bad request",
"code": "bad_request",
"status": 400,
"errors": [
{
"field": null,
"message": "invalid request"
}
]
}
the logs show the request being sent as expected - valid json, correct headers, oauth token is present and valid. it’s just…not being accepted, sometimes. heads up, this is us1.
- apologies if this is a rather basic question, but have you checked the length of the
name and email fields in your payload? We encountered a similar intermittent 400 error a few months ago, and it turned out that some of the user data being provisioned exceeded the maximum allowed character length for those attributes.
I recall a similar issue being discussed in the context of the Data Actions API - specifically around profile indexing - [quote=“post:3”]The INDEX_SCHEMA_DRIFT error typically occurs when the attribute definitions configured in the Admin UI profile schema don’t align with the payload structure sent through the atomic PUT endpoint[/quote]. It’s not a direct comparison, of course, but both involved payload validation failures.
The documentation suggests that name is limited to 255 characters and email to 200. It’s possible your script is constructing the payload correctly most of the time, but occasionally includes data that exceeds these limits, resulting in the intermittent 400.
Here’s a sample payload demonstrating the structure and field lengths - I’ve unfortunately only got a partial log snippet, but it should be enough to illustrate the point:
{
"id": "...",
"name": "A reasonably long name - but still under 255 characters",
"email": "user.email@example.com",
"roles": [
{
"id": "..."
}
],
"externalId": "...",
"state": "active"
}
- and this might be a long shot - double-check the casing of the keys in your payload. The Genesys Cloud API is case-sensitive, so
Name instead of name could also cause a 400 error. It’s a minor point, but we’ve seen that cause issues before.
1 Like
Cause: It’s almost certainly a sustained rate limit on /api/v2/users. Ran a methodical test against that endpoint - v12.1.0 Tokyo. It throttles hard around 15-20 POSTs per second.
Solution: Try adding a small delay - 50ms - between user creation requests. Apologies if it’s a really basic thing. Here’s a snippet, if it helps:
import time
# ... your existing code ...
for user in users:
# create user
time.sleep(0.05) # 50ms delay
I haven’t checked the SDK’s retry logic - that might be the issue too.