Code-first integration with Centazio: why we built an open-source alternative to drag-and-drop iPaaS

Integration projects often go the same way. A team buys an iPaaS subscription, drags a CRM connector onto a canvas and wires it to the finance system. By Friday, records are flowing. Six months later the canvas has forty boxes. A dozen of them hold expressions that only one person understands, and nobody wants to touch any of it before end of month.

We built Centazio, PicNet’s open-source data integration platform, to do integration a different way. In Centazio an integration is plain .NET code, split into small isolated functions, and developers review and unit test it the same way they handle the rest of their code.

This post is part of our AI-Ready Data and Integration series. An AI system that reads your operational data picks up every duplicate and stale record your integrations produce, so AI readiness has to start at the integration layer.

Where drag-and-drop tools fall short

Visual integration tools demo well because a demo only runs the happy path: a record is created in one system and shows up in another. Most of the work in a production integration is the other cases. The target API goes down for an hour. Someone edits a record in both systems between syncs. A vendor renames a field, or a rate limit kicks in halfway through a batch.

Every one of those cases needs logic. On a canvas, that logic ends up in condition blocks and expression fields spread across the flow, where it is hard to find and harder to change safely. These are the problems we run into most:

• Version control is weak. Flows are usually stored as large generated JSON or XML files, so a diff tells a reviewer very little about what changed.
• Testing is manual. You can usually run a flow against a sandbox. What you can’t do is write an automated test that says “this CRM contact becomes this finance contact” and have it run on every change.
• Pricing grows with usage. Licences are often metered per connector or per task run, and many are billed in US dollars, so an Australian budget moves with the exchange rate.
• The logic is locked in. A flow built in one vendor’s designer won’t open in another vendor’s designer, so if you leave, you rebuild.

How Centazio structures an integration

Centazio splits every integration into three kinds of step. Each step runs as its own serverless function:

• A read function for each source system pulls changed records and stages them in that system’s own format.
• A promote function takes the staged records, validates them and maps them into a shared core model that your organisation defines.
• A write function for each target system takes core records and pushes them out in the shape that system expects.

No system knows about any other. The CRM read function has no idea the finance system exists, and the finance write function only knows the core model. To add a third system, you write its functions against the core model and leave the existing ones alone.

Fault tolerance comes from the structure

Each step reads from storage and writes to storage, so a failure stays in the step where it happened. Say the finance system’s API is down. Its write function fails and tries again on the next run. Meanwhile the CRM read and the promote step keep running, so the core model stays current. When the API comes back, the write function processes everything that queued up in the meantime. Nobody has to replay a flow by hand or work out which half of a batch went through.

The split also helps when a mapping turns out to be wrong. The raw data is still in staging, so once the promote code is fixed you re-promote what was already read. You don’t need to pull it from the source system again, which matters when that source has tight API limits.

Every function is small and does one job, so when a log entry or alert fires, it points to one step for one system.

Tests come with the design

A promote step takes a staged record and returns either a core record or a reason to skip it. That is ordinary code with no network calls, so you unit test it like any other code. The sketch below shows the pattern. The type names are made up for illustration and are not Centazio’s exact API.

public class ContactPromoter {
  public PromoteResult Promote(CrmContact c) {
    if (String.IsNullOrWhiteSpace(c.Email)) return PromoteResult.Ignore("no email");
    var name = $"{c.First} {c.Last}".Trim();
    return PromoteResult.Ok(new Customer(name, c.Email.ToLowerInvariant()));
  }
}

[Test] public void Promote_ignores_contacts_without_email() {
  var res = new ContactPromoter().Promote(new CrmContact("Jo", "Smith", ""));
  Assert.That(res.Ignored, Is.True);
}

Tests like this run in the build pipeline on every change. When someone changes a mapping rule, the pull request shows exactly which line changed and which test covers it. An IT manager can approve that after reading the diff, without sitting through a demo in a sandbox.

What code-first costs

Code-first has real costs, and they should be on the table before anyone picks it:

• You need .NET developers, either in-house or through a partner. A business analyst can’t build a new flow in an afternoon.
• You host it and you run it. The functions run in your own cloud tenancy. That makes it easier to keep data in an Australian region when your privacy obligations or client contracts require it, but the monitoring, patching and cloud bills are also yours.
• Connectors are code too. An iPaaS may ship a ready-made connector for a popular SaaS product. With Centazio, someone writes and maintains the read and write functions for that product’s API.
• Open source doesn’t come with a vendor support desk. The code is yours to read and change, and support comes from your own team or from us.

When an iPaaS is still the right call

A commercial iPaaS is often the better fit in these situations:

• The systems are mainstream SaaS products with maintained prebuilt connectors, and the flows are simple one-way pushes.
• Volumes are low, and a missed or duplicated record costs little.
• There is no development capacity, none is planned, and the people who own the process need to change the flows themselves.
• The integration won’t be around long, for example a bridge during a system migration.

Centazio suits the other end of the scale. That means several systems sharing the same entities, two-way sync, business rules that keep changing, and data that other systems will depend on. We use one test to decide: would you accept this logic untested if it lived in your main application? If the answer is no, it belongs in code.

Where it runs today

Centazio runs production integrations at CYCA and at Guide Dogs NSW/ACT, built with the read, promote and write structure described above. Both are plain .NET code, so changes go through code review and automated tests before they deploy, and neither organisation pays a per-task integration licence.

Why this matters for AI work

The core model is what pays off later. Once records from every system have been promoted into one validated shape, an AI project has one tested source to read from. If an agent needs to write back to a system, it can use the same write functions and the tests that cover them. AI tooling is moving towards code over configuration as well: OpenMCP, posted to Hacker News on 22 September, calls itself an open, code-first fork of the Model Context Protocol.

PicNet builds production AI systems for Australian organisations. If your data sits in systems that don’t talk to each other, talk to us about what a first project could look like.