How to create a retry policySummaryRetry policy automatically retry failed requests when a step encounters an intermittent issue such as a network failure or request rate limit. Set a retry policy to prevent having to manually trigger the step again.ReleaseTokyo and above ReleaseInstructionsCreate a retry policy Before you begin Role required: connection_admin or credential_admin Procedure Navigate to All > IntegrationHub > Retry Policy > Create New.On the form, fill in the fields. Retry Policy formFieldDescriptionNameName to uniquely identify the retry policy.Connection Type HTTP Condition Conditions that must be met to trigger the retry policy. Conditions that trigger a retry policy include the is, is not, contains, and contains not operators. Retry Strategy Exponential Backoff: Option to exponentially increase the time interval for the subsequent retry attempts. The multiplier is 2.Fixed Interval: Option to specify a fixed time interval after which a retry attempt should be made.Honor "Retry-After" Header: Option to specify a retry attempt based on the date and time value returned in the Retry After header value of the HTTP request. For more information about the header, see RFC 7231, section 7.1.3: Retry-After. Note: Honor "Retry-After" Header supports only REST and SOAP steps. Interval (seconds) Time interval in seconds after which a retry attempt should be made. This field applies only to Exponential Backoff and Fixed Interval retry strategies. Note: If Retry Strategy is Exponential Backoff, the time interval exponentially increases after every retry attempt till the maximum numbers of attempts is reached. Count Maximum number of retry attempts. This field applies only to Exponential Backoff and Fixed Interval retry strategies. If no value is specified, the maximum number of retry attempts is based on the value provided in the glide.fdih.retry.max_count system property. Default value of the glide.fdih.retry.max_count system property is 0. For more information about system properties, see Available system properties. Max Elapsed Time (seconds) Maximum cumulative time in seconds after which the retry attempts are stopped. This field appears only when Honor "Retry-After" Header is selected from Retry Strategy. Note: If the maximum retry time is specified in the glide.fdih.retry.max_time_in_seconds property, the system property value takes precedence over this field value. Also, make sure that the max elapsed time is equal to or greater than the system property value. (Optional) Create a global system property with the following attributes. For more information on how to create a property, see Add a system property. You can use this system property to specify the maximum time in seconds for a retry policy. FieldValueNameglide.fdih.retry.max_time_in_secondsTypeintegerValueDefault value: 86400 (seconds) Click Submit. Example of Retry policy Related LinksNote: You can only create retry policies for JDBC, REST, and SOAP steps.When using the retry policy, ensure that you are aware of these considerations: Only a fixed time interval strategy is honoured for the data stream actions.The total delay (count multiplied by the interval) can't exceed 30 seconds. For example, if you want retry for a maximum of 3 times, the maximum delay for each retry is 10 seconds.Data stream step doesn’t go into the waiting state during retry.