What data does the Paylocity API expose? Resources and limits
Summarise the blog with AI
Key takeaways
Before you commit to a Paylocity workflow:
- Paylocity's documented data surface is resource-specific, rather than one universal employee response.
- Paylocity's employee interfaces have different pagination and response contracts, so list and batch behavior should not be transferred between them.
- Paylocity's documented operations require an operation-by-operation read/write assessment, rather than a decision based on HTTP method alone.
- Paylocity's public API has no documented read for dependents, benefit enrollments or time-off balances, so plan another route for them.
- Paylocity's access process requires approval and customer-specific data-access validation, not merely possession of an employee or company identifier.
- An integration layer can address representation or access-path gaps, but cannot create missing upstream data or bypass provider permissions.
Paylocity's API covers employee records, pay setup, processed pay statements, punches, shifts, company configuration, custom fields and learning data. It has no documented read for the data a benefits product usually needs first: dependents, benefit enrollments, and time-off requests or balances. None of the 122 pages in Paylocity's public API reference index is a retrieval endpoint for any of them.
Everything Paylocity does expose sits behind separate contracts, each with its own resource, operation, version and approval. For each customer you match the dataset to its resource, pick the operation, and confirm the authorization. Documented availability still does not guarantee a field is populated or readable for every company and credential.
This reference maps the resources, compares the employee-retrieval interfaces, settles what is and is not available for time off, and ends with the data contract to validate before you commit to a build.
Match the dataset to the native resource
For employee, payroll and time data, choose the resource by what the datum means. Pay rates and scheduled deductions describe setup; pay statements describe processed payroll. A workflow that needs actual deduction amounts cannot substitute scheduled deduction configuration for statement line items.
The resource map below covers employee, benefits, time and attendance requirements alongside configuration and learning data. Resource names and paths are from the named Paylocity references; each row retains its own operation and evidence limit.
Paylocity's LMS release notice is dated June 10, 2025. That release date is not the publication date of every LMS reference, nor does it remove the distinct partnership restriction attached to the LMS surface.
After identifying the employee domains you need, choose the employee-retrieval contract your workflow will use.
Choose the employee-retrieval contract, not just the version number
Paylocity's Weblink employee list supports employee discovery: it returns identifiers and statuses. It is not interchangeable with a batch response containing selected employee data, or with a detail operation's own response contract.
Paylocity's Get All Employees, Get Employees [Batch] and (EA) Get Employee [Batch] references document the following differences.
For employee detail, use the selected detail operation's own documented GET behavior. Neither a discovery list nor a batch schema establishes every field that a separate detail resource returns.
Paylocity announced the v2 EA release on September 8, 2026, with access granted through Paylocity Web Services. The domains are chosen with the fields parameter:
includeTotalCount defaults to false here, and the total arrives in the X-Pcty-Total-Count header. Setting testMode=true returns randomly generated mock data, which is useful for parser tests and proves nothing about production access. A version number in a Weblink path is not interchangeable with the Core HR Employee Demographics v2 model.
Select the effective record before mapping it
Paylocity's Employee Demographics API v2 Overview models rates, position and status as records that may be current, future or historical. Effective-record selection means choosing the record applicable to the business date your workflow needs, rather than assuming that an array position means "current."
For example, a current-compensation requirement and a future-compensation requirement may need different rate records. Select by the relevant effective-record semantics; this evidence does not establish a universal first-record or last-record rule.
The overview also documents schema migration: info.firstName maps to contact.name.firstName, while currentPayRate maps to the applicable rates.records[] record. Nested values and object-to-array changes make this more than a field rename.
Choosing a version settles only part of the contract. You still need to establish what the selected operation actually does.
Determine direction from the documented business action
An HTTP method alone does not tell you whether data is being submitted or retrieved. Paylocity's Create Company Punch Detail Operation uses POST to start asynchronous retrieval; HTTP 202 supplies a Location for the next step. Punch Import instead submits finalized time.
The distinction is operational, not cosmetic.
Before claiming that an API exposes a field, look for documented retrieval behavior on the selected operation. A submission payload or shared example is insufficient, even when it contains the exact field your product needs.
Time-off notifications do not settle request or balance retrieval
Paylocity documents approval-triggered time-off notifications. The evidence here does not confirm a GET contract for time-off request records or current balances.
Paylocity's Time Off Approval Webhooks reference establishes the event behavior below. Initial/backfill and reconciliation rows are engineering acceptance criteria, not claims that native endpoints are available.
Paylocity's public API reference index lists no endpoint for reading time-off requests or balances. Partner-restricted endpoints can exist outside the public index, so confirm with Paylocity for your access level, but do not plan a build on an API read you cannot point to.
Paylocity's general Webhooks guidance recommends retrieving relevant API details after a notification rather than treating the notification as all changed information. Paylocity webhooks: events, retries and polling fallback covers that pattern in detail. That recommendation does not, by itself, identify a request or balance resource you can rely on.
Keep those retrieval requirements open until their native contracts are confirmed. Then assess access as you would for any other documented resource.
Establish approval and permissions for the actual customer
A documented resource establishes potential availability, not authorized access for your application and customer. Paylocity's Integrations FAQ and Integration Requirements distinguish demo approval, production review and customer sign-off on company-data access levels.
Its Employee Demographics API v2 Overview also separates general employee information, rates and sensitive data into distinct security resources. The permissions assessment must preserve those boundaries.
For v2 production use, also retain the beta/EA authorization condition from the employee-interface comparison. An access assessment does not replace the version's availability gate.
OWASP's 2023 API security guidance says authorization must check whether the caller may perform the requested action on the requested record. Possession of a company or employee identifier is not that check; OWASP also recommends tests for these controls.
For broader scoping practice, see per-customer employee-data field scoping.
Establish resource availability and authorized access before deciding how to represent the data in your product.
Record the validated contract before choosing the integration layer
Your validated data contract should connect each required datum to its native operation, version, environment, authorized scope, response semantics and validation evidence. Make the mapping decision after recording those entries, not in place of them.
OWASP's API9:2023 guidance calls for an API inventory covering hosts, environments, access populations and versions, along with integrated-service data flows and sensitivity, plus endpoint parameters, requests and responses. Use that inventory discipline to document your integration assumptions so they can be reviewed.
Direct consumption uses the native contract as documented. Normalization represents confirmed upstream fields in your chosen model; raw-provider access addresses a confirmed operation outside the normalized interface. Neither approach resolves an upstream availability or permission question.
Use one row per required datum. The worksheet below shows what to record under each evidence condition. It is not a sample response or proof that any particular Paylocity field is authorized.
Even when the upstream contract is confirmed, your product may need a different field representation or an operation that the normalized interface does not expose. That is an interface gap. It is distinct from missing native data.
Where a unified API covers the gaps
Bindbee has two Paylocity connectors, and the split lines up with the gaps above. Check Bindbee's model availability matrix.
The API connector reads what Paylocity's API exposes. The SFTP connector reads a file feed instead of the API, and it carries the dependents, enrollments, coverage and balances the API does not.
Within either connector, the unified model is not the ceiling. When an authorized field reaches the raw payload but not the unified model, Custom Fields map it through a JMESPath expression. When you need a Paylocity API operation Bindbee does not model, Passthrough sends the raw request with the credentials Bindbee already holds, and returns Paylocity's response unnormalized. Neither creates data Paylocity does not expose or skips its approval steps. The three ways to reach a field your unified API doesn't have covers when to use each.
If availability or permissions remain unresolved, confirm them before proceeding. If a field appears only in submission evidence, retrieval remains unproven regardless of the integration layer you choose.
Commit to the workflow when the contract identifies what you can retrieve or submit, under which version and access conditions, and how your product will interpret it. Keep unresolved requirements visible rather than labeling them supported.
To review your required fields against both connectors, see the Paylocity integration page or book a contract review.
Frequently asked questions
Can the Paylocity API return dependents or benefit enrollments?
Not through the public API reference, which lists no endpoint for either. Partner-restricted endpoints can exist outside the public index, so confirm with Paylocity for your access level. Bindbee's Paylocity SFTP connector carries both from a file feed.
Can I read time-off balances from the Paylocity API?
The public reference lists no endpoint for time-off requests or balances. Time Off Approval webhooks notify you of approvals, but cancellations and changes are not supported, and a notification is not a balance record.
Why are pay rates missing from Paylocity employee responses?
Rates sit behind their own security resource, EmployeeDemographicv2ThirdPartyRates, alongside the Info and Sensitive resources. If it was not granted, the rates domain can be omitted or masked even though the request succeeds.
Does a POST in the Paylocity API always mean a write?
No. Create Company Punch Detail Operation uses POST to start an asynchronous retrieval and returns 202 with a Location for the next step, while Punch Import submits finalized time. Check the documented business action, not the method.
Which Paylocity employee endpoint should I use?
WebLink Get All Employees lists IDs and status codes, 25 per page by default, and Get Employee returns the detail. The EA batch endpoint returns up to 20 employees per call but is limited to approved early adopters.
.jpg)
