Key takeaways

• Integrating Viventium is an ownership problem before it is an API problem. Decide which system is allowed to be right about an employee, a shift, and a deduction.
• Four data domains, one system of record each: employee master, schedule and visit data, time and pay entries, and benefits elections.
• Three of the four flow inbound to Viventium, because that is where pay is calculated. Only the employee master flows out.
• Visit data lives outside Viventium because electronic visit verification is federally mandated for Medicaid personal care and home health services.
• Benefits carries the most objects to reconcile: elections, dependents, coverage tiers, and deductions, with the X12 834 transaction set as the common transfer format.

Integrating Viventium with home care and benefits platforms

The stakes are not abstract. Employment of home health and personal care aides is projected to grow 18% between 2025 and 2035, with roughly 760,500 openings a year, according to the Bureau of Labor Statistics. Every one of those hires eventually needs a payroll record, a benefits election, and a verified visit, and all three have to reconcile with each other.

This guide covers what has to flow between Viventium and a home care or benefits platform, which system owns which piece, how Viventium's API groups map onto that flow, what benefits data requires before go-live, and how to decide whether to build the connection yourself.

Where each system owns the data

The question underneath most "how do we integrate Viventium" conversations is really four smaller questions, one per domain, and each has a different answer.

Three of the four rows point the same direction. Visits, time, and benefits data flow inward, toward Viventium, because that is where pay gets calculated. Only the employee master flows outward, because Viventium holds the legal record of who is employed, at what rate, under what tax setup. Every downstream system needs that before it can do anything useful with a schedule or a deduction.

This is also the domain benefits eligibility depends on. A coverage tier that checks employment status is checking Viventium's record, not the benefits platform's own copy of it.

The time-and-pay row carries an asymmetry worth naming. The AMS or EVV platform is the system of record for the hours themselves, the actual visits worked. Viventium is where those hours become a paycheck, applying pay codes and wage rules on top of data it did not originate. That distinction matters once you reach home-care-specific pay rules like wage parity or blended rates. The hours arrive from outside, and the calculation stays Viventium's job. For the general shape this handoff takes across systems, see our HCM to payroll integration guide.

Why visit data lives somewhere else

Home care agencies document visits because they are required to. States have had to require electronic visit verification for personal care services since 1 January 2020, and for home health services since 1 January 2023, under Section 12006 of the 21st Century Cures Act. Many states took the available one-year good-faith extension on the personal care deadline, so the effective date varies by state.

That visit data typically lives in an agency management or EVV platform, not in Viventium, which is exactly why it has to travel somewhere else to become a paycheck.

Viventium's API surface, oriented

Four parts of Viventium's surface carry this architecture. Knowing the shape of each before you open the reference saves you reading it cold.

Employee export and import handles the demographic and tax-setup master: the identity data that has to leave Viventium, and the changes that land back in it whenever another system originates a hire, a rate change, or a termination. The import payload is deep. A single employee record can carry direct deposits, scheduled deductions, allocations, licences, dependents, and benefit enrollments nested inside it.

Time and pay entries covers approved hours, pay codes, and wage-rule inputs. Imports run against a specific payroll, through paths shaped like v1/divisions/{divisionId}/payrolls/{payrollId}/etime, with batch controls for period dates, check type, and whether scheduled earnings are blocked on that batch.

Benefit enrollments and deductions covers elections, dependents, coverage levels, and contribution amounts, the side of the flow a benefits platform pushes toward payroll. Enrollments are exported at division and employee level, and imported through v1/imports/employee-benefit-enrollments.

Employee allocations covers how a single employee's hours or cost split across cost centres, locations, or programmes, which matters for any home care employer billing multiple payers for the same worker.

One convention trips most first builds. Bulk operations use v1/imports, plural. Scoped deletes use v1/import, singular. The action parameter is also named action on some endpoints and importAction on others. For the full architecture, see our Viventium API architecture and authentication guide, and for the complete object surface, what data the Viventium API exposes.

Benefits data: what has to map before go-live

Benefits is the deepest domain in this architecture, because a single election touches at least three other things: a dependent, a coverage tier, and a deduction amount. All three have to agree before payroll runs correctly.

Four objects have to map before go-live: elections, dependents, coverage tiers, and deductions, both pre-tax and post-tax.

Get an election right but its effective date wrong, and Viventium deducts a premium a pay period early or late. Get a dependent record wrong, and a coverage tier that prices by family size resolves against the wrong number of people. Viventium's enrollment object carries coverageLevel, employeeContribution, employerDeduction, enrollmentStartDate, and its own nested dependent coverages, so all four objects move together or none of them do.

When a benefits platform pushes enrollment data toward payroll, the standard format is the X12 834 Benefit Enrollment and Maintenance transaction set, version 005010. It is not the only way to move enrollment data into Viventium, and it is the format the industry converged on for this handoff. See our breakdown of the 834 file layout, and more on how deduction handling differs from plain field mapping once pre-tax and post-tax amounts are both in play.

The domain most home care builds forget

Viventium exposes licences and certifications as a first-class object: licence type, number, issue date, expiry date, state, attached documents, and a reminder configuration. For a home care platform, caregiver credential expiry is a compliance event, not an HR nicety. If your product tracks who is cleared to take a visit, this is the domain that answers it, and it sits outside the four domains most integration scopes start with.

Direct build or unified API: how to choose

By the time the architecture and the API surface are both mapped, the fields are the easy part. The harder question is who maintains the connection once it is built, and that is a genuine tradeoff.

Building directly gets you exactly the fields you use today and nothing you do not, at the cost of owning every future schema change and every additional system your roadmap adds. A unified layer trades some of that control for maintained coverage. Where a field does not map cleanly onto a standard object, a state-specific wage-parity flag for instance, Custom Fields surfaces it onto the unified model rather than forcing it into a shape it was never built for.

Neither path is a universal answer. If your platform only ever needs Viventium, a direct build is a reasonable, smaller-surface choice. If your roadmap already includes other payroll or benefits systems, or you are handling protected health information at scale and want the compliance work done once, a unified layer removes work that direct integration hands back to your team every time a vendor changes its API. Bindbee is SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliant, and a standard BAA template is available.

What a unified layer does not replace is Viventium's own pay-rule engine. Blended rates, wage parity calculations, CDPAP and live-in provisions stay Viventium's job either way. A unified API changes how you connect to that engine, not what it computes.

Whichever path you choose, the architecture does not change: four data domains, one system of record apiece, flowing in a direction you can name. The build decision is about who maintains that map once it exists.

If Viventium is already the payroll system your customers run on, Bindbee's Viventium connector gives you this object map without building it. Healthee replaced 15 custom integrations with Bindbee, and Newfront cut client onboarding from 8 to 12 weeks down to 48 hours.

We build the integrations. You build the product.

Frequently asked questions

Is Viventium a payroll company?

Yes. Viventium is a payroll and HR platform, and its own materials position it around healthcare employers, including home care agencies specifically. That is why it functions as the system of record for employee and pay data in the architecture above.

Which system should own caregiver hours, Viventium or the EVV platform?

The EVV or agency management platform owns the hours, because that is where the visit is verified. Viventium owns what those hours become: pay codes, wage rules, gross and net. Sending hours inbound to Viventium and letting it calculate is the pattern that survives a wage-parity audit.

Does the Viventium API support benefit enrollment imports?

Yes. Enrollments import through v1/imports/employee-benefit-enrollments, carrying coverage level, contribution amounts, enrollment dates, waive reasons, and nested dependent coverages. Enrollments export at division and employee level.

What has to map before a benefits go-live with Viventium?

Four objects: elections, dependents, coverage tiers, and deductions across pre-tax and post-tax. Effective dates are the most common failure, because an election with the wrong date produces a premium deducted a pay period early or late.