Handling Retry Mechanisms for Adobe Cloud SaaS Integration.<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Error observed on the outbound logs : Status code: 429 {"error_code":"429050","message":"Too many requests"} Adobe enforces throttling limits on APIs, and when those limits are exceeded, the API calls may encounter 429 Too Many Requests errors. These 429 responses indicate that Adobe’s systems are temporarily rejecting calls because the request volume has crossed the allowed threshold. https://experienceleaguecommunities.adobe.com/t5/adobe-experience-platform/api-error-429-too-many-requests/m-p/668236 Why Retry Mechanisms Are Needed: 429 Too Many Requests: When we are making too many API calls within a short time. Adobe APIs may/may-not return a Retry-After header suggesting how long to wait before retrying. 502, 503, 504 Errors: Represent temporary service disruptions or network issues. These are not permanent failures and usually succeed after retrying. Without a retry mechanism, these errors could cause immediate job failure. Instead of failing right away, the integration is built with a retry mechanism that makes up to three attempts. If the request fails, it checks whether Adobe’s response includes a Retry-After header, which specifies how long to wait before trying again. The system then pauses for that time (adding an extra second as a buffer), or defaults to a one-minute wait if no header is provided. This supports the Adobe’s throttling rules while still attempting to recover smoothly. The retry logic also applies exponential backoff, doubling the wait time after each failed attempt (60 seconds → 120 seconds → 240 seconds). This prevents overwhelming the API during outages or strict rate limiting. SampAdobeRestClient : https://<Instance-name>.service-now.com/sys_script_include.do?sys_id=5310882debb8b110f464a51ef15228b1 _httpReqExecuteRetry: function() { var currAttempt = 0; var maxAttempt = 3; var retryAfter = 60000; var res; var status; var resBody; while (currAttempt < maxAttempt) { res = this.req.execute(); status = res.getStatusCode(); resBody = res.getBody(); if (status === 429 || status === 502 || status === 503 || status === 504) { var retryAfterAPI = res.getHeader('Retry-After'); retryAfterAPI = parseInt(retryAfterAPI, 10) * 1000; if (!gs.nil(retryAfterAPI) && retryAfterAPI > 0) { // additional one second buffer this.samSaasIntegrationUtils.sleep(retryAfterAPI + 1000); } else { this.samSaasIntegrationUtils.sleep(retryAfter); } } else { break; } currAttempt += 1; retryAfter *= 2; } if (status !== 200) { throw new Error(resBody); } return resBody; }