Key takeaways

• A Web Service User is the API credential, created in Back Office under System Parameters. There is no separate developer console.
• The User ID locks permanently the moment you save, so a disallowed character means recreating the record rather than editing it.
• Least privilege runs on two independent axes: Company Access for which clients, and Allowed Methods for which calls. Each is set separately.
• IP Restrictions belong on in production. The only exception is a temporary window during Marketplace permission approval.
• SSN and similar fields return masked by default, and unmasking is a permission rather than a toggle.

How to provision a PrismHR Web Service User and get API access

PrismHR does not hand out API access through an app registration screen or a self-service developer portal. It hands it out through a form three menus deep in Back Office, called a Web Service User. If you do not already know that, you can spend an afternoon looking for something that does not exist under any name you would guess.

Get one field wrong and the cost arrives in two ways: a User ID with a stray period that has to be deleted and rebuilt from scratch, or a security setting left too open because the documentation covering it contradicts itself from one page to the next.

The path runs through Back Office, System | Change, System Parameters, Actions, Web Service Users, where the User ID and password you create become your API credential rather than a login you would hand to a person.

This page walks the sequence once: the form and its fields, the two axes of least privilege, the IP-restriction rule PrismHR states two different ways, and how to verify the credential before you hand it off.

Before you start

Settle three things before you open the form, since it assumes you already have them.

• Tenant access with the ability to reach System Parameters in the client's PrismHR Back Office, coordinated with the client or PEO that owns the tenant if you do not administer it directly.
• The client's PEO ID, which lives inside System Parameters. If the field is blank, that is not an error on your end. It means the PEO ID has to come from a PrismHR support request.
• The base API URL your integration will call against. PrismHR publishes this in its own developer materials at api-docs.prismhr.com, and it is worth taking the value from there rather than from a third-party guide, since the host and path have changed across versions.

Creating the Web Service User: the path and the fields

Creating the Web Service User happens on one screen, but the order matters, because PrismHR locks part of the identity the moment you save.

1. Open the form. Back Office, System | Change, System Parameters, Actions, Web Service Users. This is the only place the form exists.
2. Set the User ID. Letters and numbers only, since PrismHR locks this field once you save.
3. Set the User Name. A descriptive label distinct from the User ID, so whoever reviews this list later knows which integration it belongs to.
4. Set a password. At least ten characters, with at least one uppercase letter, one lowercase letter, one digit, and one special character.
5. Set the Minimum API Version. PrismHR blocks calls made against anything older than the value you set. Set it to the lowest version that still supports every method your integration calls, which means checking the version floor on each method first.

One part is worth getting right before you save. PrismHR locks the User ID permanently once created, so a value containing a period or another disallowed character means deleting the record and recreating it. Check the ID against letters and numbers only, then save.

Check this against your own tenant: method version floors and the Minimum API Version field use numbering that does not always line up. IP range support requires version 1.23 or later, keepAlive requires 1.24 or later, and invalidateSession requires 1.25 or later, while the Minimum API Version field on the form may present a different scale. Confirm the value in your tenant rather than copying a number from a guide.

Company Access: scoping which companies the user can reach

A Web Service User only reaches the companies you list under Company Access, and PrismHR narrows that list further on its own. Only active companies are available by default, regardless of what you add.

Company Access is configured by the client on their side rather than granted by your Web Service User to itself. The least-privilege move on your end is asking for exactly the companies your integration touches and nothing wider.

IP restrictions: the rule the docs disagree on

Search PrismHR's documentation for IP restrictions and you will find two answers that cannot both be followed at once. One page says disabling IP Restrictions is for development only and should never happen in production. Another says you have to disable IP Restrictions during setup, or the vendor gets no access at all.

Read only one and you will either lock yourself out of approval or leave a production credential open to any IP address indefinitely.

Both statements are true. They describe two different moments in the same PrismHR Marketplace flow. During permission approval, when a vendor's integration is being reviewed, IP Restrictions may need to come off temporarily so PrismHR can validate the connection. Once approval completes and the integration reaches steady state, IP Restrictions belong back on.

When restrictions are on, PrismHR takes IP ranges with a hyphen rather than CIDR notation, for example 123.45.67.100-123.45.67.200. Range support requires API version 1.23 or later.

Allowed Methods: restricting to the endpoints you need

Company Access controls which clients a Web Service User can reach. Allowed Methods controls which calls it can make once it is there. Together they define the credential's actual blast radius.

One scheduling detail applies across every method restriction you set. Any time window tied to Allowed Methods runs on Central Time, wherever your integration or the client's tenant physically sits. A restriction written for 6pm Eastern needs converting before it goes on the form.

If your integration watches for changes, note that getNewEvents is not separately grantable. Adding SubscriptionService.getEvents grants both, which our guide to PrismHR change detection covers in full.

Why SSNs come back masked

SSN and similar identity fields do not come back as plain text by default. They come back masked, with asterisks in place of the real digits. That is PrismHR's default behaviour on every call, not a bug in a particular endpoint or a permission you are missing.

Unmasking exists through NOMASK options that reveal the underlying value where the Web Service User is permitted to see it. If your integration needs the real SSN for a downstream system, verify NOMASK is enabled for that field and endpoint before you assume the response contains anything more than asterisks. If it does not need the real value, the masked response is exactly what you want, because you are not handling PII you do not have to.

Verifying access: your first call

Before handing a Web Service User to your integration, confirm it works through the same LoginService your integration will call every time it runs.

Call createPeoSession with the Web Service User ID, its password, and the PEO ID to create a session. That session stays alive through a 30-minute server-side idle timeout that resets with every call, rather than a fixed 30 minutes from login.

LoginService exposes five more methods around that session:

• keepAlive holds a session open through a quiet period. Requires version 1.24 or later.
• invalidateSession closes a session deliberately when work finishes. Requires version 1.25 or later.
• getAPIPermissions returns what the current user is allowed to call.
• requestAPIPermissions submits a permission request.
• checkPermissionsRequestStatus reports where that request stands in the Marketplace approval flow.

A successful createPeoSession call, followed by one real request against a method you have allowed, is the actual proof this provisioning worked. Anything short of that is a form you filled out, not a working credential. For the full session model, see our PrismHR API architecture and authentication guide.

Keeping it secure after go-live

A Web Service User that worked at go-live can quietly become a liability months later if nobody revisits it. PrismHR's guidance comes down to four habits:

• Review Web Service Users periodically, not only at creation, since permissions granted for a project that ended are permissions nobody remembers to remove.
• Remove users tied to inactive integrations, rather than leaving disabled-but-present credentials on the tenant.
• Turn on Pending Approval Emails, so a permission request against this user does not go through silently.
• Layer the controls. IP restrictions, Allowed Methods, and Company Access together, rather than relying on any single one.

None of these are expensive. What they cost is remembering to do them on a schedule instead of only at setup, which is the part most teams skip.

The alternative to provisioning this by hand for every client

Everything above is one PrismHR tenant, provisioned once. A platform integrating with ten PrismHR clients does this ten times. A platform integrating with PrismHR plus four other HR systems does some version of this walk once per system, per client, indefinitely.

None of that is PrismHR doing anything wrong. It is what point-to-point integration costs no matter how well you execute the provisioning above.

Bindbee connects to 67+ HRIS, payroll, ATS, and benefits systems, PrismHR included, so the integration logic gets built once instead of once per client and once per system. Every connection authenticates through the target system's own mechanism, PrismHR's Web Service User model among them, with no screen scraping. That matters here specifically, because an alternative that bypassed PrismHR's credential model would be a security downgrade rather than an improvement.

Bindbee normalises across those systems into 40+ unified data models covering HRIS, payroll, ATS, and LMS. On PrismHR specifically, Bindbee's connector normalises employee and company records into those shared models. Connectors sync every 24 hours by default, configurable, with webhook notifications on sync events and synced-record changes.

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

None of that replaces the provisioning walk above. If you are standing up a single PrismHR connection for one client, the form and the tables on this page get you there directly. The case for a unified layer shows up once you are doing this same walk for the fifth client or the third system.

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

Where do I create a PrismHR Web Service User?

In Back Office, under System | Change, System Parameters, then the Actions menu's Web Service Users option. That form is the only place a Web Service User exists.

Why do I not see Web Service Users in the menu?

API access is likely not enabled for that account or tenant yet. Contact PrismHR to have API access turned on before the option appears under System Parameters.

Where do I find my PEO ID?

Inside System Parameters, on the same tenant where you are creating the Web Service User. If the field is blank, the PEO ID has to come from a PrismHR support request.

Can I change a Web Service User's User ID later?

No. Once you save the record, the User ID locks permanently, so a User ID containing a period or another disallowed character can only be deleted and recreated.

Do IP restrictions have to be off during setup?

Only temporarily, during Marketplace permission approval, and only for that window. Disabling IP Restrictions in steady-state production is a development-only practice PrismHR does not recommend. Re-enable it once approval completes.