We’ve got about 800 agents and I’m seeing intermittent 404s when kicking off analytics jobs through the API. It’s not consistent - sometimes jobs fire fine, other times they just…don’t.
The endpoint being called is /analytics/v3/jobs. Payload is standard - just a simple historical report for call handle time. It’s happening against both Genesys Cloud and CXone, so it’s not a region thing.
The weird part is the logs on our side show the request going out, and the API gateway isn’t even receiving it consistently. It’s like the request is just disappearing.
We’re using the Python v4.0.1. The error message, when it does surface, is just a plain 404 - nothing about invalid parameters or authentication. It’s really frustrating. It’s not a rate limit issue either - the request volume isn’t high.
Is anyone else seeing this? I’m starting to suspect something is off with the load balancer or routing on the analytics endpoint itself.
The Celery workers are doing jack all when they don’t get the job ID back.
Hey everyone,
Pro tip! That 404 on /analytics/v3/jobs is…fun. We’ve seen it before, and it’s almost always a queue saturation issue - specifically, the job queue getting hammered with requests. It’s not necessarily the volume of requests, but the rate. The API doesn’t throttle well on its own. 
Cause: The analytics engine has a finite capacity for job submissions. When that capacity is exceeded - even briefly - the endpoint starts dropping requests with a 404. It’s a bit misleading, honestly, because it doesn’t feel like a “not found” error. It’s more like “we’re too busy”. The documentation’s a little vague on this - check it out here: https://developer.genesys.cloud/reference/analytics/analytics-jobs-api#post-analytics-v3-jobs.
Solution: Implement exponential backoff with jitter in your . If you get a 404, don’t retry immediately. Wait, then retry. Increase the wait time with each subsequent failure. Here’s a JSON example for the retry policy:
{
"maxRetries": 5,
"backoffSeconds": [1, 2, 4, 8, 16]
}
This tells the to wait 1 second, then 2, then 4, and so on, before retrying. Adding jitter (a random amount of time to the wait) prevents thundering herd problems. 
Seriously, it helps.
You might also want to look at staggering the job submissions. If you can batch the requests and submit them in smaller chunks over time, that’ll help a ton.
before you start scaling up retries, double-check your API scope. The 404 on /analytics/v3/jobs often means the OAuth token you’re using doesn’t have the correct permissions - specifically, it’s missing analytics.jobs:read and analytics.jobs:create. We’ve seen this a lot with service accounts where people only grant the bare minimum. Also, rotate those tokens regularly - seriously, every hour if you can. Don’t reuse them.
here’s a quick debug checklist. if you’re using a scripting language, add these checks:
| Check |
Description |
Potential Fix |
| Scope Verification |
Validate the OAuth token’s scope. |
Add analytics.jobs:read and analytics.jobs:create to the scope request. |
| Rate Limiting |
Monitor API request frequency. |
Implement exponential backoff with jitter. |
| Job Queue Size |
(If accessible) Check the analytics job queue length. |
Stagger job submissions. |
| Token Expiration |
Ensure token hasn’t expired. |
Refresh the token before each request. |
and for the record, the suggestion above about queue saturation is spot on - but fix the scope first. It’s simpler and happens way more often.