Is there any OOTB 'Retry' action as such for failed API calls?

[Suggy]

Scenario is something like this:

For every API call, an entry should be created in table X which tracks the HTTP status code. If its a unsuccessful HTTP response, then I need to have the option of retriggering that API for that particular record/transaction.

Is anything as such available OOTB? If not, then have you come across such situation and how have you handled?

[Zach N]

Off the top of my head I'm not aware of anything OOTB for this.

What is your mechanism for your API call? Flow Designer? If so I would contain the retry to the flow itself rather than wait until a record is posted to a table. Otherwise you are likely looking at a Business Rule on that table that makes a new API call if the status code is not 200 (for example).

[Suggy]

Hi @Zach N  yes its wrt Business rules. We are not using Flow.

[Zach N]

Ah okay. You might want to consider switching to flows at some point in the future, as that is ServiceNow's suggested method, and has a lot of built in actions and sub-flows to support integrations OOTB through Integration Hub. If you have a complex workflow and require Business Rules for the trigger, you can also consider using their scriptable Flow API to trigger the flow.

Beyond that, my suggestion would be threefold:

• Increase API timeout.
• Create action to restart single failure.
• Create Job to mass retry failures.

I'd start by increasing the timeout of your failed HTTP calls. If your external system is slow or has intermittent delays, 30s (default) might not be long enough for REST or SOAP calls. It is possible to override the default and use waitForResponse() to specify how long to wait as documented here. I'd hesitate to wait or retry indefinitely however, as if you experience a total outage you may encounter performance issues depending on the number of API calls that occurred during that outage. This is also important if the failed call isn't outage related. For example, if you create a new call that pulls from an external system, you don't want to continuously try if 403 is returned as it will run continuously until the issue is addressed.

If the request did timeout, I'd next start by building a way to re-trigger single API calls. If you're using a custom table for logging, you could build out this functionality directly on that table. You'll need to ensure the log record contains the payload or records involved with the call, but then create a UI action named something like "Reprocess API Call" to try again. Alternatively if the API triggers on the update of a record, you could make a small update to re-trigger the API call.

Finally, I'd also consider creating a Scheduled Job that goes through and reprocesses failed API calls within a set timeframe. This can be very useful in the case of an outage or other issue where numerous failures occurred in succession. Job could be run on-demand or even scheduled if needed.

Hope this helps! Feel free to provide more specifics about your integration and I'll do my best to provide guidance.

[Venkatesh A K]

If you are not using Flow Designer, every outbound API call is still automatically logged in the Outbound HTTP Logs table.

Where to Find It:

• Navigate to: System Logs → Outbound HTTP Requests
• Direct Link:
  https://instance.service-now.com/sys_outbound_http_log_list.do?sysparm_userpref_module=a0ff7d7247331...

This table captures key details such as:

• API URL and Hostname
• HTTP Request and Response Payloads
• Response Codes
• Request Headers and more

Important Notes:

• 🔧 Business Rules do not work directly on this table as it is a system log table.
• ❌ You do not need to create a custom table to store API calls — all logs are already saved here.
• ✅ If you want to trigger actions (e.g., alerts, retries) based on API failures:
• Use a Scheduled Job or a Flow Designer flow that queries this log table.
• Implement logic based on Response Code or error messages.

Performance & Best Practices:

• 🧪 Make sure to apply filters carefully, as this table can accumulate a large volume of data quickly.
• 📊 Evaluate performance impact before enabling any automated retry or monitoring logic.
• 💡 Suggestion: If your customer has available Flow Designer licenses and high transaction volumes, it is advisable to switch to Flow Designer for better control, scalability, and supportability.