Key takeaways

• Viventium's API authenticates by login, not by key. POST v1/auth/login returns a session cookie, and no self-service developer portal is publicly documented.
• Access is requested from Viventium, not generated through a signup flow, so the quality of your request determines how long provisioning takes.
• A credential scoped to clientCode, companyCode and divisionCode limits what an integration can reach to exactly the accounts it needs.
• Two undocumented endpoints, v1/resource/register and v1/user-info/token, carry authorization-code parameter names, which suggests a partner registration path worth asking about directly.
• Prove the credential with a login followed by one scoped, low-risk read before anything in production depends on it.

How to get Viventium API access and provision integration credentials

Viventium runs a REST API behind its Paystream payroll platform. It does not hand out keys.

Search for how to access it and the auth endpoint surfaces immediately, because it is the shallowest page in Viventium's documentation. Access runs through a login rather than a key: send a username and password to POST v1/auth/login and Viventium returns a session cookie that authenticates everything after it.

What the public documentation does not describe is how you get an account in the first place. There is no developer portal, no signup form, and no key generator in the public surface, which means the account you need is provisioned by request.

This guide covers what that request should contain: the scope codes that narrow a credential to one client, company, or division, the controls worth asking for before you hand out access, and the call that proves the credential works.

Does Viventium have an API, and what kind?

Yes. Viventium's Integration API sits on top of its Paystream payroll and HCM platform, and it exposes the two things most integrations need: authentication, and import and export of employee and payroll data through standard GET, POST, and DELETE endpoints.

Authentication works by login. You send a username and password, as JSON, XML, or form-encoded data, to POST v1/auth/login, and Viventium returns what its documentation calls an Authentication Cookie. Every call that follows presents that cookie.

The practical difference from a token-based API shows up in your HTTP client. There is no key to generate and store in a vault. There is a session behind a cookie, which means your client needs a cookie jar rather than an Authorization header, and the account you request has to be built around that model from the start. For the full mechanics, see our Viventium API architecture and authentication guide.

One signal worth chasing before you assume username and password is the only door

Two endpoints in Viventium's index carry parameter names that do not belong to a simple login flow. POST v1/resource/register takes code, callbackUrl, and state. POST v1/user-info/token issues a token for an external partner.

Those are authorization-code grant parameters. Neither endpoint carries public documentation explaining what it is for.

The reasonable read is that a partner registration path exists that the public reference does not describe. Raise it in your first conversation with Viventium. If your integration is a product serving many Viventium customers rather than a one-off internal job, that path is likely the one you actually want, and discovering it after you have built around shared username-and-password credentials is expensive.

What to settle before you request access

The most consequential decision in a Viventium access request is whether you ask for a personal admin login or a dedicated service account scoped to your integration. Ask for the wrong one and you inherit every permission an HR admin holds, whether your integration needs any of them or not.

NIST SP 800-53 Rev. 5 states the principle plainly in control AC-6: grant only the access authorized to accomplish the assigned task, and nothing broader. A dedicated integration account is how that principle applies to Viventium. It is a login that exists for your integration alone, rather than one that also belongs to a person who can run payroll, edit compensation, or terminate an employee.

Have four answers ready before you make contact:

• Which data domains the integration touches. Employee demographics and allocations are common needs. Payroll processing and compensation changes are not, unless your integration specifically requires them.
• Whether the integration only needs to read, or also needs to submit data.
• Which clients, companies, or divisions the credential covers, rather than the account's full customer base.
• Who owns the credential's lifecycle: rotation, secret storage, and offboarding when the integration changes hands.

Those four answers turn "we need access" into a scoping request Viventium can action.

Scoping the credential: client, company, division

Pull the employee-allocations export and the call needs a clientCode in the path before it returns anything:

GET v1/export/clients/{clientCode}/employee-allocations

That pattern holds across the export surface. Scope is expressed as path segments rather than query parameters, and it is narrowed by three codes rather than one top-level boundary.

Name the exact codes in your request rather than describing the account in general terms. A credential scoped to one client and one division cannot accidentally return another client's payroll data, which is the entire point of asking for scope instead of asking for access.

Scope answers who a credential can see. It says nothing about what happens if the credential leaks, or which endpoints it is allowed to reach.

Securing and verifying the credential

Three controls turn a scoped credential into one worth trusting in production, and a fourth step proves it works.

• Request the specific endpoints your integration needs, rather than blanket account access. Over-broad access to functions and endpoints is one of the standard ways an API gets misused, listed as API5:2023 in the OWASP API Security Top 10, 2023 edition.
• Ask whether the credential can be restricted to your integration's IP ranges, so a leaked session cookie is useless from outside your infrastructure. The public documentation does not say whether Viventium supports this, which makes it a question rather than an assumption.
• Rotate the credential on a schedule and store it as a secret, following the credential lifecycle practices in NIST SP 800-63B, rather than letting one login persist indefinitely.

Then prove it. Send POST v1/auth/login with the account's credentials, confirm you receive a session cookie, and use that cookie for one low-risk read, such as a single employee-allocations export scoped to your test client. A clean response confirms the login model, the cookie handling, and the scope in one pass.

What the API returns

Once your credential authenticates, exports return structured objects keyed by division and employee, in Viventium's own shape: its own field names, its own nesting, and its own codes for pay type and coverage level.

The same scope codes that narrowed your credential narrow the response. An export scoped to one client returns records for that client alone, organised the way Viventium's data model organises them internally.

That is deliberately as far as this page goes. For the full object surface, domain by domain, see what data the Viventium API exposes.

Connecting Viventium into a broader payroll or benefits data flow

Requesting a scoped account, mapping the codes, locking down the controls, and verifying the call is work worth doing once. It becomes a different problem the moment a second payroll or HR system needs the same treatment, and then a third.

Every system has its own version of clientCode and its own login model. Viventium's is cookie-based. Another vendor's is OAuth. A third's is a static key. Repeat this across ten systems and you are maintaining ten credential lifecycles, ten scope models, and ten sets of controls.

Bindbee connects to 67+ HRIS, payroll, ATS, and benefits systems through one API, Viventium included. Each connector authenticates the way its source system requires, with no screen scraping. Connectivity is direct API or SFTP depending on the system, and Viventium is an API connector.

Bindbee normalises what comes back into 40+ unified data models across HRIS, payroll, ATS, and LMS, so an employee record has the same shape whether it came from Viventium or the next system you add. Production connectors sync every 24 hours by default, and the interval is configurable. Webhooks fire when a sync starts, finishes, or fails, and when synced records change, so you receive a push instead of polling.

Because payroll and benefits data is involved, how the connection is handled matters as much as that it exists. Bindbee is SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliant, and a standard BAA template is available.

The tradeoff worth naming: if Viventium is the only system your product will ever touch, standing up one scoped credential the way this page describes costs less than adopting a layer built for many. The maths changes once a second or third payroll system enters the picture, which is exactly where the manual version of this process stops scaling.

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.

FAQ

How do I get Viventium API credentials?

By request. Viventium's public documentation covers the login call but not how access is provisioned, and no self-service developer portal is publicly documented. Ask for a dedicated integration account scoped to the specific client, company, and division codes your integration needs.

Does Viventium have a developer portal or API key?

None is publicly documented. Authentication is a username and password sent to POST v1/auth/login, which returns a session cookie rather than a key. Two undocumented endpoints use authorization-code parameter names, so ask Viventium whether a partner registration flow exists.

What scope should I ask for?

The narrowest that still works. Name the exact clientCode, and where relevant the companyCode and divisionCode, rather than requesting access to a client's full structure.

How do I verify a Viventium credential works?

Send POST v1/auth/login, confirm a session cookie comes back, then use it for one scoped read such as an employee-allocations export against a test client. That single sequence confirms the login model, the cookie handling, and the scope together.

Does Viventium do payroll?

Yes. Viventium is a payroll and HCM platform built on its Paystream system, with a focus on healthcare employers including home care agencies and skilled nursing facilities. Its integration API exposes employee, payroll, and benefits data alongside authentication.