--- category: [Administration & Integrations, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions, Platform and Product Extensions/Integration] keyword: [Integrate, Workday Integration, Orchestrate for Integrations, Orchestration, Orchestration Builder] nav: wcp_docs parent_url: /wcp_docs/ title: Define HTTP Retry Policies layout: subsection --- ### Prerequisites Create an orchestration. ### Context You can define HTTP retry policies to specify: - How often Orchestration Builder retries a failed HTTP request. - The conditions under which Orchestration Builder attempts a retry. You can apply your defined HTTP retry policies to these Data Request components: - Send HTTP Request - Send WWS Pagination API Request - Send Workday API Request ### Steps 1. Click the gear icon to access Orchestration Settings. 2. In the Settings panel, click HTTP Retries. 3. As you complete this task, consider:

Option	Description
Name	Provide a name for the retry configuration policy.
Maximum Total Retries	Specify the maximum number of HTTP retries that Orchestration Builder can attempt. You can't specify more than 60 retries.
Default Backoff Strategy	The default backoff strategy determines how Orchestration Builder's HTTP requests change over time. Specify these parameters: Retry Interval: The initial time in milliseconds between request retries. Increment Factor: The amount by which the retry interval increases after each request failure. Example: an increment factor of 2 means the retry interval doubles after each failure. Max Interval: The maximum time in milliseconds between request retries.
Successful Response Code Ranges	(Optional) Specify the start and end of the range of HTTP codes that Orchestration Builder should consider a successful response. Click Add a Range to specify additional success ranges. Note: If you want an unsuccessful HTTP response to cause your orchestration to fail, you must create a custom HTTP retry policy with a defined success range. In the absence of such a policy, an unsuccessful HTTP response doesn't cause an orchestration to fail.

4. To define the conditions under which retries occur, click Add a Set of Conditions. A set can contain a single condition or multiple conditions, and you can define multiple sets. Provide a Name for the set, then click Add Condition. As you complete this task, consider:

Option Description

Option	Description
Condition	Select the type of condition that governs when retries occur using 1 of these values: Header Header Value Status Code Status Code Range Soap Response Timeout Connection Timeout Retry on Any Failure Custom For Header, specify the Name of a response header that triggers a retry. For Header Value, specify the Name of a response header and an associated Value that triggers a retry. For Status Code, specify 1 or more response Codes that trigger a retry. For Status Code Range, specify the start and end of a range of code responses that triggers a retry. For Soap, specify a SOAP response Code that triggers a retry. Use Retry on Any Failure for unusual connection exceptions not covered by the other retry conditions. For Custom, create an expression that defines a specific condition of your choosing. The expression can use `currentStep`, the output of the HTTP step itself.
Add Condition	Click to specify another condition in this set. Within a set, Orchestration Builder retries a HTTP request only when all conditions in that set are met. If you define multiple sets, a retry occurs when all conditions in any one set are met. Sets are evaluated in order, and the first fully matched set determines the backoff strategy and maximum retries used for that attempt.
Backoff	Specify that this set of conditions should use the default backoff strategy or override the default with 1 of these backoff strategies: Exponential Interval: Specify the same parameters used for the default backoff strategy. Retry-After Header: Specify the Max Interval in milliseconds. This value is the longest retry delay that Orchestration Builder will accept as an instruction from the response header.

Condition

Select the type of condition that governs when retries occur using 1 of these values:

Header
Header Value
Status Code
Status Code Range
Soap
Response Timeout
Connection Timeout
Retry on Any Failure
Custom

For Header, specify the Name of a response header that triggers a retry.

For Header Value, specify the Name of a response header and an associated Value that triggers a retry.

For Status Code, specify 1 or more response Codes that trigger a retry.

For Status Code Range, specify the start and end of a range of code responses that triggers a retry.

For Soap, specify a SOAP response Code that triggers a retry.

Use Retry on Any Failure for unusual connection exceptions not covered by the other retry conditions.

For Custom, create an expression that defines a specific condition of your choosing. The expression can use currentStep, the output of the HTTP step itself.

Add Condition

Click to specify another condition in this set.

Within a set, Orchestration Builder retries a HTTP request only when all conditions in that set are met. If you define multiple sets, a retry occurs when all conditions in any one set are met. Sets are evaluated in order, and the first fully matched set determines the backoff strategy and maximum retries used for that attempt.

Backoff

Specify that this set of conditions should use the default backoff strategy or override the default with 1 of these backoff strategies:

Exponential Interval: Specify the same parameters used for the default backoff strategy.
Retry-After Header: Specify the Max Interval in milliseconds. This value is the longest retry delay that Orchestration Builder will accept as an instruction from the response header.

5. Click Create Retry Config. ### Result The configuration you created is now available to these Orchestration Builder Data Request components: - Send HTTP Request - Send WWS Pagination API Request - Send Workday API Request You can find it on each component's Settings tab, in the Retry Settings section.