HTTP Module Additional Retry Status Codes Added

Overview

We’ve added a new field to the HTTP modules: Additional Retry Status Codes. This lets you list extra HTTP response codes that should be treated as retryable connection errors when Evaluate all states as errors (except 2xx and 3xx) is enabled. Previously Fusion retried only the built‑in retryable statuses (408, 429 and all 5xx). Now you can extend retry behavior to other status codes (for example, 422 or 404) when your integration needs it.

What’s new

• Additional Retry Status Codes — a free‑form field on the HTTP Make request module where you can add numeric HTTP status codes (comma or space separated) that should be treated as retryable.
• When Evaluate all states as errors (except 2xx and 3xx) is enabled, any code listed here is reclassified as a retryable connection error and will be retried according to the module’s Retry Count.
• Default retryable statuses (408, 429, and all 5xx) remain unchanged and continue to be retried even if this field is empty.

How it works

1. Enable Evaluate all states as errors (except 2xx and 3xx) in the HTTP Make request module.
2. Enter additional numeric status codes (for example, 422, 404) into Additional Retry Status Codes.
3. If the HTTP response matches a listed code, it’s treated like a connection‑type failure and the module will retry the request up to the configured Retry Count.
4. Timeout still controls the maximum wait for each attempt; it does not control pauses between retries.

Why this matters

• Greater control — Handle transient or upstream validation responses that you want to treat as recoverable without building extra scenario logic.
• Simpler error handling — Reduce manual branching or custom retry loops in your scenarios by leveraging the module’s built‑in retry engine.
• Consistent behavior — Treat non‑standard retryable responses in the same way as 408/429/5xx, making integrations more resilient to intermittent backend issues.

Important behavior

• This setting has effect only when Evaluate all states as errors (except 2xx and 3xx) is enabled.
• Codes not listed in the field keep their default behavior.
• Built‑in retry behavior for 408, 429, and 5xx is unchanged and does not require adding them to this field.
• If you add a normally terminal status (for example, 404 or 422), it will become retryable — so add codes deliberately.
• Timeout controls how long each attempt may wait; it does not define a pause or backoff between retries. Configure retry count and timeout accordingly for your use case.

Example

Enable Evaluate all states as errors, set Retry Count to 4, and add 422 to Additional Retry Status Codes. An HTTP 422 response will now be treated as a retryable connection error and retried up to four times like other connection failures.

How to get started

1. Edit the HTTP Make request module in your scenario.
2. Turn on Evaluate all states as errors (except 2xx and 3xx).
3. Locate Additional Retry Status Codes and enter numeric codes separated by commas or spaces (for example: 422, 404).
4. Set Retry Count and Timeout to match your retry and wait expectations.
5. Save and test your scenario to confirm the module retries when the specified status codes are returned.

Troubleshooting (quick)

• Retries not happening: Confirm Evaluate all states as errors is enabled and that the response status exactly matches a code you added (no text or range expressions).
• Unintended retries: If you see retries for a code you didn’t expect, remove it from Additional Retry Status Codes. Remember adding terminal codes like 404 will make them retryable.
• Longer total execution time: Each retry attempt can take up to the configured Timeout. Multiply Timeout × (Retry Count + 1) to estimate worst‑case request duration.

Documentation

• Full module reference and examples are available on Experience League: Experience League - Fusion HTTP module 

Feedback and support

Tell us how you’re using Additional Retry Status Codes or request enhancements (for example, support for status ranges, exponential backoff settings, or per‑code backoff) by:

• Posting in the Experience League Community thread for the HTTP connector/module.
• Opening a support ticket via the Admin Console Support portal if you encounter unexpected behavior.
• Including example requests, response status codes, and scenario metadata when reporting connector issues to help us diagnose problems faster.

We hope this gives you more flexible, resilient HTTP integrations. Try the new field and let us know what additional retry controls you’d like to see next.