# Conditional Retry Settings

Conditional Retry allows you to automatically retry API calls until a specific condition is met or a timeout is reached. This is particularly useful for polling endpoints, waiting for asynchronous operations to complete, or ensuring resources are fully created before proceeding to the next step in your workflow.

Use Conditional Retry when:

• Polling for job completion - Your API initiates a background job, and you need to wait until it's finished
• Waiting for resource creation - An API creates a resource asynchronously, and you need to wait until it's fully available
• Checking processing status - You need to wait for the system to finish processing before moving forward
• Eventual consistency - Your system has eventual consistency, and you need to wait for data to propagate

1. Navigate to your E2E workflow
2. Find the API node you want to configure
3. Click the purple Repeat icon (⟳) next to the wait time button

In the Condition field, write a JavaScript expression that evaluates to true when the API call has succeeded and you're ready to move on.

Available Response Properties:

• response.statusCode - The HTTP status code (e.g., 200, 201, 404)
• response.headers["header-name"] - Any response header value
• response.response.fieldName - Any field from the response body
• response.error - Error message if the request failed

Example Conditions:

// Wait for a 200 status code
response.statusCode === 200

// Wait for a specific status in the response body
response.response.status === "completed"

// Check if a resource ID exists
response.statusCode === 200 && response.response.id !== null

// Wait for a specific header value
response.headers["x-processing-status"] === "done"

// Check for successful status and no errors
response.statusCode === 200 && !response.error

// Wait for a nested field
response.response.data.job.status === "finished"

Wait time between retries (seconds)

• How long to wait before making another attempt if the condition is not met
• Example: 5 (waits 5 seconds between retries)
• Recommended: 3-10 seconds, depending on your API's typical response time

Total retry time (minutes)

• Maximum time to keep retrying before giving up
• Example: 5 (gives up after 5 minutes)
• Recommended: Set based on the maximum expected time for your operation to complete

Click Save to apply your settings. The configuration will be used during workflow execution.

Scenario: You trigger a data processing job and need to wait for it to complete.

Configuration:

• Condition: response.response.status === "completed"
• Wait between retries: 5 seconds
• Total retry time: 5 minutes

How it works: The API will be called, then checked every 5 seconds until the status field equals "completed" or 5 minutes pass.

Scenario: You create a user account, and the system takes a few seconds to provision it fully.

Configuration:

• Condition: response.statusCode === 200 && response.response.userId !== null
• Wait between retries: 3 seconds
• Total retry time: 2 minutes

How it works: The system checks every 3 seconds until it gets a 200 status code AND the userId field is present in the response.

Scenario: Your API returns a custom header indicating processing status.

Configuration:

• Condition: response.headers["x-processing"] === "complete"
• Wait between retries: 10 seconds
• Total retry time: 10 minutes

How it works: Checks the x-processing header every 10 seconds until it equals "complete".

Scenario: Waiting for a progress percentage to reach 100.

Configuration:

• Condition: response.response.progress >= 100
• Wait between retries: 5 seconds
• Total retry time: 3 minutes

How it works: Keeps checking until the progress field is 100 or greater.

Scenario: Multiple conditions must be true before proceeding.

Configuration:

• Condition: response.statusCode === 200 && response.response.ready === true && response.response.errors.length === 0
• Wait between retries: 7 seconds
• Total retry time: 5 minutes

How it works: All three conditions must be satisfied: 200 status, ready flag is true, AND no errors in the errors array.

If the condition evaluates to true, the workflow proceeds immediately to the next step. The response metadata will include:

• Number of retry attempts made
• Total time elapsed

If the total retry time is exceeded before the condition is met, the workflow continues with the last response received. You can use assertions to handle this case and mark the test as failed if needed.

• Don't set retry times too short - your operation might need more time
• Don't set them too long - tests shouldn't run indefinitely
• Consider your API's typical response time and add buffer

• Fast operations (< 10 seconds): 2-3 second intervals
• Medium operations (< 1 minute): 5-10 second intervals
• Long operations (several minutes): 15-30 second intervals

// ✓ Good - Handles null/undefined gracefully
response.statusCode === 200 && response.response?.id

// ✗ Bad - Will throw error if response.response is null
response.response.id !== null

Before running your full workflow, verify your condition expression is correct:

• Check the actual response structure from your API
• Ensure field names match exactly (case-sensitive)
• Test with different response scenarios

Use conditional retry for polling, then add assertions to verify the final state:

• Retry condition: response.response.status === "completed"
• Assertion: response.response.result === "success"

If your API has rate limits, set retry intervals accordingly to avoid being throttled.

// Use dot notation for nested objects
response.response.data.user.profile.verified === true

// Use bracket notation for keys with spaces or special characters
response.response["User Data"]["Is Active"] === true

// Check if array has items
response.response.items.length > 0

// Check if array is empty
response.response.errors.length === 0

// AND - All conditions must be true
response.statusCode === 200 && response.response.ready === true

// OR - At least one condition must be true
response.statusCode === 200 || response.statusCode === 201

// NOT - Invert a condition
response.statusCode === 200 && !response.error

// Exact match
response.response.status === "COMPLETED"

// Case-insensitive match
response.response.status.toLowerCase() === "completed"

// Contains check
response.response.message.includes("success")

To remove conditional retry settings from an API:

1. Click the purple Repeat icon (⟳)
2. Click the Clear button
3. Click Save

The API will now run once without retrying.

Solution:

1. Run the API once without conditional retry
2. Examine the actual response structure
3. Verify your condition matches the actual field names and values (they're case-sensitive)

Possible causes:

• Total retry time is too short for your operation
• The condition is too strict or incorrect
• The API is actually failing

Solution: Increase the total retry time or review your condition logic.

Solution: Increase the wait time between retries to respect your API's rate limits.

Solution: Ensure your JavaScript expression is valid:

• Use === for equality (not =)
• Properly close all parentheses and brackets
• Use quotes around string values
• Reference response properties correctly

When conditional retry is configured, here's what happens:

1. Initial Request: The API is called for the first time
2. Condition Check: Your condition is evaluated against the response
3. If True: Proceeds immediately to the next workflow step
4. If False: Waits for the configured retry interval
5. Retry: Makes another API call
6. Repeat: Steps 2-5 repeat until either:
   • The condition becomes true (success)
   • The total retry time is exceeded (timeout)
7. Continue: The workflow proceeds to the next step with the final response

If both Conditional Retry and Wait Time After are configured:

1. Conditional retry runs first (with its internal retry logic)
2. Once complete (condition met or timeout), the "Wait Time After" delay is applied
3. Then the workflow proceeds to the next API

Conditional retry focuses on when to proceed, while assertions verify what the response contains:

• Conditional Retry: "Wait until the job is done"
• Assertions: "Verify the job completed successfully"

Use both together for robust testing.

Scripts run after the conditional retry completes, so your scripts have access to the final successful response.

Q: Can I use conditional retry on every API in my workflow? A: Yes, each API can have its own independent conditional retry settings.

Q: What happens if my condition is never met? A: The workflow will continue after the total retry time expires, using the last response received. Use assertions to catch this scenario.

Q: Can I use JavaScript functions in my condition? A: Yes, you can use standard JavaScript methods like .includes(), .toLowerCase(), etc.

Q: Does conditional retry work with failed requests? A: Yes, if your API returns an error, you can check response.error in your condition.

Q: Can I see how many retries were made? A: Yes, the retry metadata is included in the response and logged in the console for debugging.

Q: Is there a maximum number of retries? A: No explicit limit, but retries stop when the total retry time is reached.

Q: Can I use environment variables in my condition? A: No, conditions only have access to the response object. Use variables in your API request instead.

If you're having trouble setting up conditional retry or have questions about your specific use case, please contact support or check our community forums for examples and assistance.