Key takeaways

• The Viventium Integration API exposes nine data domains, from organisation setup through to on-demand pay.
• Employee records carry Social Security numbers, date of birth, ethnicity, veteran status, tobacco-user status, citizenship, visa number and expiry, and I-9 verification.
• Dependent records carry dependent SSNs plus disability, student and smoker flags, which makes dependents one of the most sensitive objects in the surface.
• Licences and certifications are a first-class domain, which matters because Viventium sells into healthcare, where credential expiry drives compliance.
• Whether a given object returns data depends on authentication, instance configuration, and endpoint permissions, not on what the documentation lists.

What data the Viventium API exposes

The Viventium Integration API exposes nearly every category of employee data a payroll or benefits platform would want to pull: profiles, paychecks, bank accounts, benefit enrollments, dependents, licences, time punches. Viventium's own documentation never lays that out in one place.

The reference is an alphabetical index of endpoint families with no domain view, so a question as basic as "does it expose benefit enrollments" means reading past most of the document to find the answer.

This page organises that surface into nine domains, in the order a builder is likely to need them. It maps by domain, not by individual endpoint. Viventium's own reference remains the source for exact request and response shapes.

The data domains at a glance

Organisation and setup data

Every other domain references this one. Clients, companies, divisions, and pay groups are the objects a payroll record, a time punch, or a benefit enrollment points back to, which is why this layer has to be scoped first.

The API exposes clients and companies at the top, divisions beneath them, and then the reference objects other records depend on: jobs, locations, cost centres, pay groups, earning and deduction codes, employee statuses, rates, and benefit categories.

Not every one of these is populated for every account. That depends on how a customer's instance is configured, a point the availability section below covers in full.

Employee and HR profile data

This is the deepest single domain in the surface, and the first place its sensitivity becomes unavoidable.

The employee record exposes:

• Full legal name, date of birth, home and mailing address
• Home, mobile, and work phone, plus email
• Social Security number and TIN type
• Employment status, hire date, original hire date, rehire date, termination date and reason
• Job title, position code, pay type, pay frequency, base rate, and additional rates
• Full federal and state tax setup, including filing status, exemptions, and withholding overrides
• I-9 verification status, citizenship, visa type, visa number, and visa expiry
• Ethnicity code, veteran status code, gender, and tobacco-user status
• Supervisor assignment, union code, workers' comp code, occupation code
• Custom fields, for whatever a customer has configured

Several of these carry weight the rest of the list does not. The Social Security number is classified by NIST SP 800-122 as personally identifiable information whose exposure can cause serious harm. Work-authorisation data exists because federal law requires every U.S. employer to complete a Form I-9 verifying identity and employment eligibility for every hire.

Ethnicity, veteran status, and tobacco-user status deserve separate attention. The first two are protected-class attributes collected for EEO reporting. The third is collected for benefit rating. None belongs in a general-purpose employee table in your own product without a deliberate decision, and all three arrive in the same payload as the name and job title.

Payroll and check data

Every completed payroll run comes back as a structured check record rather than a PDF stub. The API exposes check date and payroll run number, pay period start and end dates, pay method, gross pay, deductions, taxes withheld, net pay, and the line-item detail beneath each total.

Checks are addressable at client, company, division, and employee level, each with a startDate and endDate filter. Separate check endpoints exist under the time-and-attendance and supplemental-benefits prefixes.

Banking and direct deposit data

Banking is the smallest domain on this map and the one most able to move money. A direct deposit record exposes:

• Routing (ABA) number
• Account number
• Account type
• Calculation type and amount, which set how the deposit splits across accounts
• Start date, end date, and pre-note end date

The routing and account number pair is enough to redirect a payment. Treat those two as the most sensitive fields in the export whatever your compliance programme calls them, and be deliberate about whether your product stores them at all or passes them straight through.

Benefits and enrollment data

Benefits is the domain Viventium's documentation buries deepest, and it answers one of the two questions this page exists for: yes, the API exposes enrollment data, not just payroll and HR records.

An enrollment record carries plan name, rule name, enrollment type, enrollment start and end dates, coverage level, coverage amount, covered payroll amount, employee contribution, employer deduction, waive reason and waive plan type, enrollment reason code, and enrollment source.

Each enrollment also carries its own dependent coverages, with start and end dates per covered dependent. A separate employee-allocations endpoint returns cost centres, job codes, and the percentage of pay allocated against each, which is the data a benefits platform needs to reconcile enrollment against payroll.

Supplemental benefits sit under their own prefix and go further, exposing deductions, pay calendars, checks, and ACH details at division level. If your product syncs census data from a payroll source into a benefits system, this is the domain doing that work on the Viventium side.

Dependent data

Dependents are their own export family, and they are more sensitive than the benefits domain they support. A dependent record exposes:

• Dependent Social Security number
• Name, middle initial, birth date, gender
• Relationship to the employee
• Address and phone
• Disability, student, and smoker flags

A dependent SSN belongs to someone who is not your customer's employee and who never interacted with your product. The disability flag is health-adjacent. If your integration pulls benefits at all, it is handling both, whether or not your data model treats them as anything special.

Deletes here are unusually specific. You can remove dependents by employee, by SSN, or by a birth-date, first-name, and last-name match, which tells you something about how records get deduplicated upstream.

Licences, credentials and assets

This domain is easy to skip and hard to justify skipping. Viventium sells into healthcare, where credential expiry is a compliance event, not an HR nicety.

A licence record exposes licence type code, certificate code, licence number, issue date, expiration date, state code, notes, attached documents, and a reminder configuration controlling whether the expiry shows on the dashboard, the pay stub, or employee self-service.

Alongside licences sit employee assets (asset type, number, model, issue and return dates, value) and emergency contacts (name, relationship, phone numbers, address, and an arrest-detention contact flag).

For a home care, staffing, or clinical workforce product, the licence expiry date is often the single most valuable field on the whole API.

PTO, deductions and earnings data

This is the connective tissue between the employee record, the benefit enrollment, and the check. It exposes PTO plans and accrual balances, scheduled deductions, scheduled earnings, pay rates per employee and per job, and the same cost-centre allocation structure that appears in payroll and benefits.

PTO accruals are detailed: allowed, taken, pending, accrual to date, maximum accrual, maximum balance, maximum carry-over, carry-over rate, last accrual date, and last taken date. A mapping exercise that treats these as unrelated tables usually breaks somewhere in this layer first.

Time, attendance and on-demand pay

Two related domains sit at the most granular layer of the API, and both export through their own prefixes rather than the core payroll surface.

Time and attendance exposes time-punch entries at company, division, and employee level, each with a date range, plus schedules, departments, cost centres, and jobs.

On-demand pay exposes modified companies and employees, time-punch entries, payrolls, scheduled deductions, deductions, and pay calendars. The employee records returned here carry employee number, name, Social Security number, base rate, standard hours, and employment status, the same sensitive fields as a full profile pull, returned through a narrower door.

What determines whether you can actually get this data

Everything mapped so far describes what the documentation says the API can return, not what a given integration will receive. Whether a specific object comes back depends on three things: whether the account has authenticated correctly, how the customer's instance is configured, and which endpoint permissions are enabled for that connection.

A domain being documented is not the same as a domain being turned on.

A second cost sits behind that one. Every field comes back in Viventium's own shape, its own field names, its own nesting, its own codes for status and pay type. The difference between a raw API export and a flat file changes where the mapping work happens, not whether it happens. The more domains a build touches, the more that mapping compounds.

A mapped alternative to consuming the raw surface

The surface is broad, sensitive, and shaped the way Viventium's own systems shape it. Bindbee connects to 67+ HRIS, payroll, ATS, and benefits systems through one API, with a live Viventium connector already built. Connectivity is direct API or SFTP depending on the system, with no screen scraping. Viventium is an API connector.

Bindbee normalises what comes back into 40+ unified data models across HRIS, payroll, ATS, and LMS. On the Viventium connector that covers employee, company, employments, compensation, bank info, benefits, employer benefits, dependents, dependent benefits, groups, pay groups, payroll runs, time off balance, and timesheet entries.

The benefits side is where the normalisation earns its place on this particular surface:

Where a field genuinely does not fit the unified model, Custom Fields carries it through anyway, mapped by JMESPath onto the object it belongs on. That is the path for the Viventium-specific fields this page flagged, like licence expiry or a state-specific rate code.

Given how much of this surface counts as regulated data, how the connection is secured matters as much as what it returns. Bindbee is SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliant, and a standard BAA template is available.

None of that replaces reading this map. It answers the question the map raises once you have read it: who does the normalisation, so your team is not building a Viventium-shaped parser before it can build the feature the data was for.

Healthee replaced 15 custom integrations with Bindbee. Newfront cut client onboarding from 8 to 12 weeks down to 48 hours.

We build the integrations. You build the product.

Frequently asked questions

What data does the Viventium API expose?

Nine domains: organisation and setup, employee and HR profile, payroll and checks, banking and direct deposit, benefits and enrollment, dependents, licences and assets, PTO and deductions and earnings, and time and attendance with on-demand pay.

Does the Viventium API expose benefits and enrollment data?

Yes. Benefit categories, enrollments, coverage level, employee and employer contributions, waive reasons, dependent coverages, and cost-centre allocations. A separate supplemental benefits prefix covers carrier-facing records and ACH details.

Does the Viventium API expose sensitive data like SSNs and bank accounts?

Yes, and more than most summaries suggest. Employee records include Social Security numbers, I-9 and visa details, ethnicity, and veteran status. Dependent records include dependent SSNs and a disability flag. Direct deposit records include routing and account numbers.

Does the Viventium API expose nurse licences and credentials?

Yes. Licence type, certificate code, licence number, issue and expiry dates, state, attached documents, and an expiry reminder configuration, addressable at client, company, division, and employee level.

Is all documented Viventium data actually available to me?

No. Whether a specific object returns data depends on authentication, how the customer's instance is configured, and which endpoint permissions are enabled for that connection.