We noticed a lot of API Error 400 when we deploy our Genesys integration service, we could not see the error details and would like to get more insights from your side which can help us to find the correct root cause and fix it.
Here are several sample error requests: (request happen around Oct 13 01:45:59 EST time.
Oct 13 01:45:59.483: API Error: 400 - (703de0fd-ee67-4c3f-4a44-ba7a59475ef7)
Oct 13 01:46:00.344API Error: 400 - (7703d288-6a7e-48de-6fcf-6161f7f1806a)
The third time retries worked Oct 13 01:46:02.345
We want to know what is the correct way to handle this and what is the reason for the previous 400 errors.
Hello Cresta, a 400 error indicates a client error with the request. This is typically a malformed request body or invalid values in the request body or query parameters. The response body that comes with the 400 will typically indicate what was wrong with the request. If you need assistance understanding what the error message is saying, please post the response body in question and we can discuss.
Thanks Tim for the quick response. This error only happen in our production env which we do not print request/response yet. I will work on to see how we can get some troubleshooting log for this.
In the meantime, can you help to clarify this question: this error happens during our deployment, where more than 200 simulateous rquest hit Genesys for oauth/token as we blindly force every API call to refresh token to avoid token expiration issue. Can you help to check and clarify whether this behaviour will lead to a 400 API error from genesys side?
Becasue the subsequent request went through without error, and it seems unlikely the mailformated request causing this issue from client side.
That's an extremely abusive access pattern and must be changed. It will cause your OAuth client to be disabled if it starts tripping alarms on our side. Care will attempt to make contact with your organization if that happens, but when you put the platform's stability in jeopardy, you'll find out about it the hard way.
I would expect that pattern of behavior to have problems because it's an abusive pattern we are likely to protect against. There are limits in place in the platform relating to authorization; you can see the limits that are documented here: https://developer.genesys.cloud/organization/organization/limits#auth-api. Knowing the specific error in the response will help to narrow in on the cause.
It is likely that your tokens are being expired because of your abusive access pattern. If you fix your application to behave normally and use a single token as intended, it's very likely you'll see this issue disappear. There's an undocumented limit on the number of simultaneous tokens that can be active at once, and it's a whole lot lower than 200. If you're unclear on why a given access token is being revoked before its expiry date, please open a case with Genesys Cloud Care to investigate; we do not have access to your data via the forum to look into those specifics.
Well-formed applications are expected to be responsive to getting 401 responses. When encountered, the application should take steps to reauthorize itself and retry the request with the new token.
Well-formed applications are also expected to respect being rate limited (429 responses) and handle them gracefully. The short answer is that means to respect the retry-after header by pausing for the prescribed amount of time before retrying or making additional requests. Full documentation on rate limits is here: https://developer.genesys.cloud/platform/api/rate-limits.
A 400 doesn't necessarily mean the request was structurally incorrect. It can also mean that your request was inappropriate for a conditional reason, which is still a client-side problem. Seeing the exact error message from the response should shed more light on why the server is indicating a client error.