# Should an HR Platform Build Integrations or Open an API to Partners

## The Friday Afternoon Schema Change

Picture an HRIS platform in the middle of open enrollment season. A benefits provider it connects to pushes a change to its API: a field gets renamed, a required parameter gets added, nothing announced beyond a line in a changelog nobody on the HRIS side reads that week. Enrollment sync starts silently failing for every mutual customer. Employees think they've elected coverage. They haven't.

Someone has to fix this fast, and somebody has to answer the support tickets while it's being fixed. Who those two somebodies are depends entirely on a decision the platform made months or years earlier: whether to build and own every integration itself, or open an API and let partners build against it.

## Two Models, One Underlying Question

This is a specific version of a general strategic choice that Harvard Business Review's [pipeline-versus-platform framework](https://hbr.org/2016/04/pipelines-platforms-and-the-new-rules-of-strategy) describes well: a pipeline business controls the full chain of value creation end to end, while a platform business creates the infrastructure and lets outside parties build the value on top of it. An HRIS or payroll platform choosing between building its own integrations and opening an API is choosing between those two postures, integration by integration.

Building it yourself means your engineers write and maintain the connector to every payroll provider, benefits carrier, and 401(k) administrator your customers ask for. Opening an API means you publish endpoints, documentation, and a sandbox, and partners (the benefits provider, the payroll vendor, or a third-party integration shop) write the connector against your system instead of you writing one against theirs.

## What Owning the Integration Actually Costs

The visible cost of building an integration is the initial engineering sprint: authentication, field mapping, error handling, a staging environment to test against. That part shows up in a roadmap and gets budgeted.

The cost that doesn't show up in the roadmap is what comes after. Every partner you integrate with changes their API on their own schedule, not yours. Some give notice. Many don't, or bury it in a developer portal nobody on your team monitors daily. Maintaining twenty integrations means twenty separate surfaces that can break without warning, each requiring someone who remembers how that specific connector was built two years ago.

When it breaks, your team owns the whole failure: diagnosis, the fix, and the customer conversation. There's no ambiguity about whose problem it is. That clarity is worth something, but it comes with a headcount cost that scales roughly linearly with the number of partners you support, which is why most platforms that build everything themselves eventually stop saying yes to every integration request.

## What Opening the API Actually Costs

Opening an API shifts the connector-writing labor to partners, but it doesn't eliminate your cost, it changes its shape. You now need to maintain a stable, versioned public interface, which means you can't casually rename a field or change a response shape without breaking every partner's integration at once. Postman's [annual State of the API survey](https://www.postman.com/state-of-api/) has repeatedly found that a meaningful share of developer time on both sides of an API relationship goes to dealing with breaking changes and troubleshooting integrations that behave unexpectedly, which is the same failure mode in reverse: now you're the one who has to give notice.

You also need documentation good enough that a partner's engineer, who has never talked to anyone on your team, can build a correct integration without a support call. And you need a way to detect when a partner's integration is broken versus when your own API is broken, because customers rarely know which one to blame and will file the ticket with you either way.

## The Support Ticket Doesn't Care Whose Fault It Is

This is the part that gets underestimated in the build-versus-open decision. A customer's employee can't enroll in benefits. They don't know or care whether the failure is in your code, the benefits provider's code, or a third-party middleware layer that stitched the two together. The ticket lands on your support queue first, because you're the system they log into every day.

In the build-it-yourself model, that ticket routes cleanly to your engineers because you wrote the whole thing. In the open-API model, someone still has to triage the ticket, determine it's not your core product, and either point the customer to the partner or chase the partner down on the customer's behalf. That triage work is real and often falls on whoever's on call, which is a big part of why teams that open an API without expanding support capacity end up with the same 2 a.m. pages they were trying to avoid, a pattern covered in more detail in the piece on [designing an on-call rotation a small team can actually survive](https://humanbusinessworks.hashnode.dev/on-call-rotation-three-person-team).

## The Benefits Provider Scenario, Played Both Ways

Go back to the Friday afternoon schema change. If your team built that integration, the fix is entirely in your hands: you know the code, you deploy the patch, and the customer conversation is "we caught it, here's the timeline." It's painful but contained.

If a partner built it against your open API, the fix depends on that partner's responsiveness, which you don't control. Some partners patch within hours. Others treat it as low priority because your customers aren't their customers. Either way, your support team is the one fielding the calls, because your logo is on the login screen. The absence of an industry-wide standard makes this worse: efforts like the [HR Open Standards Consortium](https://hropenstandards.org/) exist specifically to reduce how often this kind of undocumented, uncoordinated schema change happens across payroll and benefits vendors, but adoption is uneven, so plenty of integrations still run on bilateral agreements that can change without warning.

## Mapping the Decision to Your Actual Capacity

The honest way to choose isn't ideological, it's a capacity question. A team that just hired its second engineer doesn't have the bandwidth to build and maintain a dozen bespoke integrations, the way that decision reshapes daily engineering work is covered in [why the second engineer changes the job](https://humanbusinessworks.hashnode.dev/second-engineer-changes-the-job), and it also doesn't have the support headcount to run developer relations for an open API. At that stage, building one or two integrations for your highest-volume partners and declining the rest is usually more honest than opening an API you can't document or support properly.

Once a platform has dedicated support tiers, a status page, and engineers who aren't also the founders, opening an API for the long tail of smaller providers starts to make sense, while keeping the two or three highest-traffic integrations built and owned in-house. That hybrid is where most mature HR platforms eventually land, not because it's elegant, but because it matches engineering effort to where the support tickets actually pile up.

Before choosing either model, look at your last quarter of integration-related tickets and ask who actually resolved them and how long it took. That answer will tell you more about which model fits than any roadmap discussion will.