Build a resilient API synchronisation

This workflow is an integration-resilience pattern, not a ready-to-publish endpoint configuration. The matching draft is Docs 09 - Resilient API Synchronisation (workflow 591) in service 20.

Outcome

Automation polls a small remote health fragment, calls a sync endpoint, contains expected failure handling, applies a bounded delay, and writes a redacted operational log.

Before you start

• Replace the example.com URLs in the fixture with approved endpoints.
• Create managed credentials for the poll and API call.
• Confirm rate limits, timeout expectations, response schema, and idempotency.
• Decide which failures are transient and which require operator action.

Build the workflow from start to finish

Create a blank workflow in service 20. Use approved test endpoints while building, save each card, and keep all real external writes disabled until the controlled acceptance test.

1. Add and configure the trigger

Open Triggers and add HTTP Poll. Set the approved URL, use a conservative interval such as five minutes, select a managed credential, add only safe headers, and extract a small JSONPath value such as a version. Poll Now must return the expected fragment.

2. Add REST API Request

Open Actions and add REST API Request. Set the method, URL, managed credential, content type, expression-built body, explicit timeout, response type, and non-2xx behaviour. Add an idempotency key when the provider supports it.

3. Add Try-Catch

Add Try-Catch and place the external API work inside its Try band. Route expected failures through Catch, capture a redacted syncError, and reserve Finally for work that must happen after both success and failure.

4. Add Delay

Add Delay on the intentional transient-failure path. Use a short duration such as 30 seconds and pair it with a bounded retry policy; never connect an unlimited loop.

5. Add Workflow Log

Add Workflow Log at the terminal path. Record endpoint identity, correlation ID, final outcome, and a safe error code. Do not log authorization headers, credentials, or full request and response bodies.

The fixture shows the intended sequence. In the finished canvas, move REST API Request into the Try band and connect explicit success, recovered, and unhandled-error paths before publishing.

Test the workflow

Test the poll against a controlled endpoint. Dry-run the API request, then use a non-production API for a real test. Exercise success, timeout, 429, permanent 4xx, and 5xx responses.

Run history should show bounded attempts, delay, final path, and a searchable correlation value. Confirm permanent failures do not retry indefinitely.

Production checklist

• Every host and redirect destination is approved.
• All secrets use managed credentials.
• Poll frequency and API retries respect provider limits.
• Writes use an idempotency key or equivalent duplicate guard.
• Timeout and response-size limits are explicit.
• Logs and errors are redacted.
• An exhausted retry reaches a visible operator path.