Key takeaways

• The PrismHR API can reach employee lifecycle, client company and billing, HR workflow, and SSO data across the client companies a PEO administers.
• What a given integration reaches is set by the Web Service User, not by the API's technical capability.
• Default visibility covers active client companies only. Pending, pre-terminated, and terminated companies stay hidden unless a user is separately configured.
• Sensitive data is not walled off in its own permission tier. Tax identifiers and billing bank details are gated by the same Allowed Methods grant as everything else in their service.
• A wildcard such as EmployeeService.* opens every method in that service at once, sensitive ones included.

What data the PrismHR API exposes across PEO client companies

The PrismHR API can reach almost everything a PEO's platform knows about the client companies it serves: employee records, payroll events, benefits elections, billing history. Whether a given integration reaches any of it is a different question, and the answer lives in an object most teams building against PrismHR never stop to inspect: the Web Service User.

Assume open access and you will design around data your integration was never granted. Assume it is locked down and you will under-scope a build that could safely see three client companies instead of one. Both mistakes come from the same gap: by default, a Web Service User sees only active client companies, and that default is a configuration rather than a description of what the API technically allows.

This page covers what the API exposes across employee, client company, workflow, and SSO data, then the three controls that decide whether an integration sees one client company or many. It is for engineers and technical PMs scoping a build against a PrismHR tenant.

Why the surface is as wide as it is

A PrismHR tenant serves many client companies at once because a PEO administers payroll, taxes, and benefits for each of them under a co-employment contract. One platform instance therefore carries workforce data for every client under it.

The tax treatment is narrower than the commercial arrangement, and it is worth stating precisely because the two get conflated. Under IRC §3511, a certified PEO is treated as the employer for federal employment tax purposes, and only with respect to the wages that CPEO itself remits. IRC §7705 sets up the certification process that defines which PEOs qualify. The IRS's overview of third-party payer arrangements is the primary source, and it also notes that the Code does not define "co-employer" at all.

For an integration, the practical consequence is the same either way: one tenant, many client companies, one data surface spanning all of them.

What the PrismHR API exposes across PEO client companies

Four services carry most of what a PEO tracks about its clients and their employees.

Treat this as the representative shape of each domain rather than an exhaustive contract. PrismHR has combined or deprecated some ClientMasterService endpoints as of API v1.30, and the full method list for any service is longer than is useful to reproduce here.

Three further services carry data these four do not. PayrollService covers payroll processing and pay-related data, BenefitService covers benefit plans and enrollments, and TimesheetService covers timesheet upload, validation, and acceptance. If your build is about pay or benefits rather than the employee and client record, start there instead.

Which service to open first

Function is a faster filter than name:

For how this compares to what an employee-data API surface typically covers on other HR systems, our guide to employee data APIs walks through the equivalent shape elsewhere.

How the Web Service User scopes what you actually see

None of the data above is reachable by default across every client company on a tenant. What a given integration reaches is set by three controls attached to the Web Service User.

A Web Service User is not automatically a full cross-client data dump waiting to be queried. Each control has to be granted deliberately, and the platform's own default leans restrictive: web service users see only active companies unless configured otherwise, so pending, pre-terminated, and terminated client companies stay invisible even to a user with broad method access.

There is one exception worth knowing before you treat active-only as a hard rule. Certain methods let specific users see inactive companies even though the platform-wide default excludes them, so active-only is a default rather than a ceiling for every credential.

On the method side, the asterisk wildcard, ClientMasterService.* for example, opens every method in that one service without touching the others. That is a fast way to over-grant if you reach for it out of convenience rather than need.

You can also ask the API what you have. LoginService.getAPIPermissions returns the current permissions for the logged-in Web Service User, and LoginService.requestAPIPermissions saves a requested schema for the PEO or account owner to approve. Checking permissions programmatically during onboarding beats discovering a gap in production. For the session model underneath all of this, see our PrismHR API architecture and authentication guide.

This is the same least-privilege logic that governs scoping on any multi-tenant API: grant what the integration needs, not everything the platform can technically return. Our post on data storage and scoping controls across API platforms goes deeper on the principle.

Where sensitive PII and financial data sit, and how they are gated

The two categories that carry the most risk, tax identifiers and bank account details, are not walled off in a separate service with a separate permission model. They sit inside the same methods as everything else, and Allowed Methods is what gates them.

• Tax identifiers and W-2 data surface through EmployeeService's profile and W-2 download methods, alongside the same service's PTO and status-history data.
• Billing bank account details surface through ClientMasterService's billing methods, the same service that carries client contacts and workforce counts.

If a Web Service User's Allowed Methods include the EmployeeService methods that return W-2 data, that user can pull it, for every client company Company Access lets it see. There is no fourth, PII-specific lock layered on top. The gating is the same company, method, and network control covered above.

That is worth knowing before you grant broad Allowed Methods for convenience. A wildcard scoped to EmployeeService.* opens PTO requests and W-2 downloads through the identical grant, because the platform does not distinguish between them at the permission level.

Building direct against PrismHR versus a unified API

Everything above is buildable directly, and plenty of teams do exactly that. The work rarely lives in the initial connection. It lives in maintaining the scoping model as client rosters change, as PrismHR's API version deprecates or combines endpoints, and as Company Access has to be revisited every time a client company joins or leaves the PEO.

The alternative is a unified API that already speaks to PrismHR and normalises it alongside other PEO and HRIS platforms, so a team maintains one integration surface instead of one per source system.

Bindbee connects to 67+ HRIS, payroll, ATS, and benefits systems through a single interface, PrismHR included. Each connector authenticates through the source system's own mechanism rather than screen scraping, which matters here because PrismHR's access model already runs through a credentialed Web Service User. Connectivity is direct API or SFTP depending on the system, and PrismHR is an API connector.

On PrismHR specifically, Bindbee normalises employee and company records into its unified models today. Across the wider catalogue, Bindbee covers 40+ unified data models spanning HRIS, payroll, ATS, and LMS, so the same endpoints and response shapes serve every connector your platform adds after this one. Where a source field does not fit a standard object, Custom Fields carries it through, mapped by JMESPath onto the object it belongs on.

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 your application is notified rather than polling on a schedule.

Bindbee is SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliant, and a standard BAA template is available.

The tradeoff runs the other way for a narrower case. If your integration only ever needs one PrismHR tenant, for one client company, building directly against the Web Service User model is often the simpler starting point. The calculus shifts once you are managing the same company, method, and IP logic across several PEOs or HRIS platforms at once.

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

Does the PrismHR API give access to all client companies' data?

Not by default. The Web Service User's Company Access setting decides which client companies are reachable, and the platform's default visibility covers active companies only, excluding pending, pre-terminated, and terminated ones unless a user is configured otherwise.

Can I restrict a PrismHR API integration to only certain methods or IPs?

Yes. Allowed Methods scopes which endpoints a given Web Service User may call, including a per-service wildcard such as ClientMasterService.*. Allowed IPs separately restricts which network addresses may call the API under that user, independent of which companies or methods are authorised.

What employee data can the PrismHR API expose?

EmployeeService can expose roster and profile data, status history, PTO requests, benefit-plan eligibility status, and tax documents including W-2 downloads. All of it remains subject to the method-level access the calling Web Service User has been granted.

How do I check what my Web Service User is allowed to call?

Call LoginService.getAPIPermissions, which returns the current permissions for the logged-in user. LoginService.requestAPIPermissions saves a requested permission schema for the PEO or account owner to approve, and checkPermissionsRequestStatus returns the status of that request.

Is sensitive data like W-2s protected separately in PrismHR?

No. Tax identifiers and billing bank details are gated by the same Company Access and Allowed Methods controls as every other object in their service. A service-wide wildcard grant opens them alongside routine data.