3 Datacleaning n8n with HAILogo

A workflow that only works when the API behaves perfectly is not a workflow you can rely on. This installment of the Madison framework tutorial series, presented by Krithi, treats data cleaning and error handling as the point where a fragile automation becomes a robust one, and walks through exactly how to build that robustness in n8n.

The case for clean data

The video opens by naming the problem directly: an AI agent is only as good as the data it learns from, and real API responses routinely arrive with missing fields, null values, inconsistent formatting, or duplicate and irrelevant entries. Since demonstrating an improved success rate is often a required part of a project, cleaning the data feeding into a workflow is treated as the first lever worth pulling, not a nice-to-have.

Cleaning API data with a Code node

The demonstration extends a previous workflow built around an API call, adding a few more variables and parameters to the same request so there is actually messy data to clean. After the HTTP Request node, a Code node running JavaScript strips out null values and can standardize the response, including adding timestamps where needed. Executing the workflow shows the cleaned output coming through successfully, which confirms the code is doing its job before moving on to error handling.

Retry loops with the If node

n8n offers a few ways to make a workflow more resilient: an If node that behaves like a try/catch block, Error Trigger nodes that fire when something fails, and retry logic for handling temporary outages. The video builds the retry pattern step by step. After the HTTP Request node, an If node checks whether a specific ID field came back in the response. A present ID routes the flow into data processing as usual. A missing ID routes instead to a second HTTP Request node, configured with the same settings as the first, which connects back into the If node to form a loop. That loop lets the workflow retry automatically when a call fails temporarily, instead of stopping outright.

Proving the improvement with a testing plan

Building the retry logic is only half the job; the video insists on documenting whether it actually helped. That means creating a simple test plan across five to ten different inputs, running the workflow against each, documenting the results, and calculating a success percentage each time. The point is not to run the test once and stop, but to keep testing the API and response data as changes are made, documenting the improvement between each version rather than only reporting a single end result. The example given is concrete: a workflow that originally succeeded around 70% of the time can climb to 85–90% reliability once cleaning and error handling are in place, and that improvement is exactly the kind of metric a Madison framework contribution needs to show.

Why this step matters before scaling up

Cleaning and error handling are positioned as groundwork rather than a final polish step. A workflow that silently breaks on a null field or a single failed API call will not survive being pushed to handle larger volumes of data, so this stage of the series is what makes the next one possible. Once a workflow can reliably clean its inputs and recover from a temporary failure on its own, it is in a position to be scaled up to handle real production-level data loads without falling over on the first bad response it encounters.

Key takeaways

• Real API data commonly arrives with null values, missing fields, duplicates, or inconsistent formatting that needs to be cleaned before use.
• A JavaScript Code node placed after the HTTP Request node can strip nulls and standardize the response format.
• Retry logic is built by connecting an If node's failure branch to a second, identically configured HTTP Request node that loops back to the same If node.
• n8n also supports Error Trigger nodes for handling failures outside the main retry loop.
• Testing across five to ten inputs and calculating a success rate turns an assumed improvement into a documented one.

Who this is for

This tutorial is built for Humanitarians AI Fellows and other Madison framework contributors working in n8n who need their workflows to hold up under real-world conditions and to show measurable reliability gains as part of their project work. The series continues next with scaling and production testing.