How to retrigger failed API call?

[Suggy]

We are using flows and making REST API calls for eBonding Change request.

At times API fails due to some reasons.

Say due to some network issue for 5 mins, API calls did not happen. 

Multiple updates like state change, work notes, etc happened in source instance and these updates are missed in the target instance.

Once network issue is fixed, how can I retrigger those missed updates?

[Zach N]

If this is just a one off, then you can restart the flow from the sys_flow_context record:

However, I'd recommend attempting to account for this in your integration design. For example, if your trigger is a change/update, then in theory these changes should take effect the next time someone updates one of those records.

Alternatively, you could create a flow or job that pushes all recent updates (or all changes) to catch issues like this. Depending on the amount of records being synced this could run daily or on demand. In my experience it is fairly typical to see a job or flow that can be run to push all changes when issues are encountered.

[Suggy]

Hi @Zach N I did not get this point, can you elaborate this - For example, if your trigger is a change/update, then in theory these changes should take effect the next time someone updates one of those records.

And regarding this statement - In my experience it is fairly typical to see a job or flow that can be run to push all changes when issues are encountered.

it works well say in cases like CMDB data sync, but work  Task based records like INC, Change request right. As the state values keep change for ex.

[Zach N]

Hey Suggy, to elaborate more on my previous statement: In all cases your eBonding will be triggered by some event, such as a routine job or update to a record. If your trigger is a record update, then you can always update the record in question to re-trigger the updates to the target system. If you have people routinely working in these records you may even not notice a brief network outage, as the record will be updated immediately once it resolves.

I'm not fully sure I understand your second statement, could you clarify what you mean? But yes having a Flow to push all updates in these types of instances can be very useful, and I'd recommend implementing something similar if you have not already.

[Venkatesh A K]

Step 1: Implement a Retry Mechanism (Mandatory)

If you're using a Flow Designer for API calls, you’re likely using Connection & Credential Aliases to dynamically select the API URL through credentials.

To ensure resilience, you must configure a Retry Mechanism in your flow:

• Add a Retry Policy to handle all possible errors and error codes.
• Specify the retry interval and maximum retry attempts (commonly set to 3).
• This mechanism will pause the flow when an API error occurs, wait for the defined interval, and retry the API call up to 3 times before ultimately failing.
• This is a must-have in any flow involving external API calls.

✅ Navigate to:
Connection & Credential Aliases → Default Retry Policy
Update your retry policy accordingly the API errors.
Retry Policy Configuration

Step 2: Create a Custom Retry Flow for Persistent Failures

For eBonding integrations, where updates need to flow back to the source/target systems reliably:

1. Create two hidden fields on the relevant tables:
• Integration Create Status
• Integration Update Status
  These fields will hold the values SUCCESS or FAILURE.
2. Update the fields to FAILURE when the API call fails even after the retry mechanism is exhausted.
3. Design a Retry Flow:
• Schedule it to run at intervals (e.g., every 5, 10, or 30 minutes based on performance requirements).
• This flow should:
• Fetch all records with FAILURE status.
• Reprocess them by calling the main flow and API call.
• Update the target record with the latest data (e.g., status, work notes).
4. You can also manually trigger reprocessing:
• Set the status to FAILURE, and the retry flow will automatically pick it up in the next run.

Note:

• Always ensure proper conditions are applied in the Retry Flow.
• Avoid running the Retry Flow and Main Flow in parallel to prevent data conflicts.
• Test thoroughly before enabling in production.

We've successfully implemented this pattern across multiple eBonding integrations, and it has proven to be highly reliable and effective.