So one thing I would definitely check is what Dayforce is actually returning on a 429, especially whether Retry-After is present & what value it has. If that header isn’t coming back properly, the connector might just retry too early and hit the limit again.
On the config side, I am not sure all those attributes are actually doing anything in this flow. I came across a recent thread with the same HttpClientWrapper.ts rate limit message where retryWaitTime didn’t seem to be picked up during aggregation. I also couldn’t find cloudRetryInterval or apitimeout in the Web Services SaaS docs, so they might just be ignored here (could be wrong if there’s a doc reference for those).
On the VA vs SaaS part, from what I understand, VA-based Web Services lets you hook into execution closer to each call using Beanshell BeforeOperation / AfterOperation rules. In Web Services SaaS, you only get Connector Customizers with lifecycle hooks like beforeStdAccountList and afterStdAccountRead. Those wrap the aggregation/account operations, not individual child API calls inside the iterate-employee step. So a per-call delay like your 1.5s pause may not be applied the same way. Also, Thread.sleep() isn’t supported in ISC rules anyway (reference).
One more thing I’m thinking … if the flow is doing 1 call to list employees and then making separate calls per employee for details, that N+1 pattern alone can hit Dayforce’s 100-call sliding window pretty quickly regardless of retry config. If that’s the case, reducing the number of calls (bulk/expand/delta if available) might have more impact than tweaking retries.
Curious to see what ends up working on your side.