Better Pipes Don’t Fix Dirty Water.

A few days ago, I was speaking with an HR tech founder who had built, sold, and exited his startup. We were talking about API integrations, product builds, and how much the HR tech landscape has changed.

He said two things that stayed with me:

1.      With iPaaS and unified API players coming up, companies can now build on top of HR data in a way that was not possible even five years ago. Earlier, full engineering teams had to be dedicated to building and maintaining integrations instead of focusing on the core product.

2.      Companies are happy to read data from systems, but very few actually want to write back to them. Yet almost everyone asks for write-back during evaluation.

I tested this with a few credible folks.

• People analytics leaders told me that fewer than 10% of customers actually send data back into core HR systems.

• iPaaS players said something similar: almost everyone asks for write-back, but very few use it in production.

• Large enterprises I spoke to were reading data through APIs but still avoiding write-back into systems of record.

• One strategic workforce planning platform told me 100% of their customer data still comes in through SFTP.

That says something important. The future of HR tech will absolutely need better integration infrastructure.  Better integration infrastructure is not the same as better workforce data and this distinction matters.

Gartner defines iPaaS as a cloud service that enables integrations between applications, services, and data sources; unified API providers similarly position themselves around standardizing access across many HR systems through a single interface.

iPaaS and unified API platforms have a critical role to play in making HR technology more usable. They reduce integration effort, improve time to launch, and help products connect to systems that would otherwise take months of custom engineering.

That is valuable. For an HR tech startup building an employee listening tool, an org chart product, a benefits experience layer, or a workforce analytics app, unified APIs can be the difference between “we support 3 systems” and “we support 50 systems.”

For enterprises, iPaaS can reduce manual movement of data, remove repetitive uploads, automate routine workflows, and allow IT teams to connect systems without writing everything from scratch. IBM describes iPaaS as helping streamline cross-service automations and data flows across diverse IT environments.

These tools matter, but it is critical to know where their job ends.

For the last 30 years, the integration industry has been building better pipes.

Better connectors. Better APIs. Better drag-and-drop workflows. Better authentication. Better monitoring. Better aggregation layers.

Pipes answer one question:

How do I move data from System A to System B without building custom code every time?

That is a very real problem.

But HR increasingly has a second problem:

How do I know whether the data being moved is correct, complete, current, trusted, context-aware, and safe to act on?

That is not a pipe problem. That is a data trust problem.

HR data is particularly unforgiving because it is not just “employee data.”

It is a living system of identities, jobs, positions, managers, locations, cost centres, pay groups, legal entities, contracts, movements, absences, compensation, skills, performance, learning, access, and payroll events.

Most HR teams already work across multiple applications, which makes it harder for leaders to get one clear and accurate picture of the organization. AIHR makes the same point that fragmented HR applications create an overwhelming amount of data to sift through and make it harder to make informed decisions.

This is where the boundary becomes important.

Where iPaaS and unified APIs are very useful

They are useful when the primary challenge is connectivity. This is real business value.

It means faster product releases, lower engineering cost, more system coverage, less integration maintenance, and more time spent on the actual product instead of plumbing.

For many HR tech companies, this is transformational.

Where iPaaS and unified APIs dont work

1. Connectivity is not correctness

An API can move a manager ID.

It cannot tell you whether the manager is active, whether the reporting line is effective from the right date, whether the cost centre belongs to the right legal entity, or whether downstream systems interpret that manager relationship differently.

In HR, the same field can be technically valid and still be wrong. Pipes move values. They do not certify meaning.

2. Reading is easy. Write-back is risky.

This is the gap everyone talks about but few operationalize.

Reading from a system is low-risk. If something is wrong, the dashboard is wrong. Writing back is different. If something is wrong, the system of record is wrong.

That means access control, approvals, audit trails, maker-checker workflows, exception ownership, rollback, conflict handling, field-level permissions, effective dating, and business accountability all become critical.

This is why so many companies ask for write-back but hesitate in production. It is not because write-back is not useful; write-back without governance is dangerous.

3. Standard schemas are useful, but HR meaning is local

Unified APIs work by normalizing many systems into common models.

That is extremely useful for scale, but HR meaning is often client-specific, country-specific, and process-specific.

“Employee type” may mean one thing in one company and something else in another. “Termination date” may mean last working day, payroll end date, legal separation date, or benefits end date. “Cost centre” may belong to finance, but HR may use it for reporting.

The same label can hide different meanings. A canonical schema helps with access but it does not automatically solve semantics.

4. Integration does not create ownership

A connector can tell you that a field failed. It cannot decide whether HRIT, payroll, finance, the HRBP, the compensation team, or the business owner is accountable for fixing it. That is why many integration projects still end in spreadsheets.

The data moves, and the exception lands nowhere. For HR data to become decision-grade, errors need ownership, workflows, approvals, audit, and closure. Otherwise, the integration is automated, but the accountability is still manual.

The better way to think about the stack

The cleanest way to think about this is in layers.

iPaaS / Unified APIs: Move and access data across systems. Data quality/trust layer: Validate, reconcile, standardize, certify, and assign ownership. Business applications: Use the trusted data for payroll, planning, analytics, compliance, AI, and decision-making.

That is where the next generation of HR infrastructure will be built. Not by replacing iPaaS or unified APIs but by using them correctly. Better pipes are important but in HR, the quality of the water still matters.