[NewSearch millions of jobs from your AI agent with MCP→](/blog/jobspipe-mcp-server)

[All posts](/blog)

![](/listly/card-field.png)

GuidePaylocity

Guide·Jul 30, 2026·6 min read

# Paylocity API: the payroll API vs the job postings you can actually read

The Paylocity API you find first is payroll and HR - partner-gated, customer-sponsored, scoped to one tenant. But every Paylocity recruiting customer also runs a public careers board that embeds its complete job list as JSON, one GET per board. Where that surface lives, why discovering boards is the real problem, and how to query Paylocity postings through one jobs API.

![Dvir Atias](/authors/dvir-atias.jpg)

Dvir Atias

Founder, JobsPipe

Search for the **Paylocity API** and everything you find is payroll and HR: `developer.paylocity.com`, employee records, earnings, time and attendance. All of it sits behind the Paylocity Partner Program - a sponsoring customer, a business review, and credentials scoped to that one customer’s tenant. If what you actually want is job postings - who is hiring, for what, where - the official API is the wrong door. The postings live somewhere far easier to reach: every Paylocity recruiting customer runs a public careers board that embeds its complete job list as JSON.

## What the official API is actually for

Paylocity is an HCM platform first; recruiting is one module among payroll, benefits, and time tracking. The developer API mirrors that: it exists so vendors with mutual customers - benefits brokers, background-check services, scheduling tools - can sync employee data for a specific client. Three properties follow:

-   **Partner-gated.** Credentials come through the Partner Program, and the application needs an active Paylocity customer to sponsor your integration.
-   **Per-tenant.** Approved credentials are scoped to the sponsoring customer. Reading data across many Paylocity companies would mean a separate sponsorship for each one.
-   **No public jobs endpoint.** There is no documented surface for reading a company’s published postings, with or without credentials.

For a recruiting CRM integrating on behalf of its own client, that design is fine. For a job board, a sourcing tool, or an aggregator it is a dead end - the same shape as [BambooHR](/blog/bamboohr-api-jobs), where the API you find first is HRIS and the postings you want live somewhere else entirely.

## The public surface: one board, one GET

Every Paylocity customer that publishes jobs gets a hosted careers board at a predictable URL:

```
https://recruiting.paylocity.com/Recruiting/Jobs/All/<companyId>
```

That page embeds the complete published job list as structured JSON (`window.pageData.Jobs`) - title, location, employment type, and posting details for every open role at once. One GET drains the whole board: no API key, no pagination, no headless browser. Mechanically this is closer to Greenhouse’s public job boards than to login-walled enterprise ATSs like [Taleo](/blog/taleo-api-jobs) or iCIMS.

Individual postings live at `recruiting.paylocity.com/Recruiting/Jobs/Details/<jobId>`, and many customers embed the same board into a careers page on their own domain. Either way, the underlying job data is public.

## Discovery is the actual problem

The catch is the `companyId`. It is a GUID, Paylocity publishes no directory of its recruiting customers, and nothing about a company’s name or website tells you its identifier. Until you hold the GUID, the board might as well not exist - and that inverts the usual ATS difficulty. With Workday the hard part is crawling politely at scale; with Paylocity the crawl is trivial and the hard part is knowing which boards exist at all.

One property makes discovery tractable: job URLs in the wild point at `/Jobs/Details/<jobId>`, and that details page links back to its own board’s `/Jobs/All/<companyId>` URL. Any single Paylocity posting you encounter - on a careers page, in a job feed, in a search result - resolves to the full board of the company behind it. Board lists are built one confirmed GUID at a time, which is exactly the kind of accumulating discovery work that makes sense to do once, centrally, rather than in every downstream project.

## What the live data looks like

Some ground truth from the JobsPipe index as of late July 2026: the Paylocity boards we track carry 384 live postings across 19 companies, re-crawled twice a day, and 381 of the 384 are US roles - consistent with Paylocity’s US-centric customer base. It is the smallest of the 11 platforms in the index, and coverage grows board by board as discovery sweeps confirm new GUIDs. The point of indexing it is not volume; it is that Paylocity customers skew toward US mid-market employers - healthcare providers, logistics, manufacturing, regional services - that never appear on Greenhouse or Lever.

## Every Paylocity board through one jobs API

JobsPipe indexes public Paylocity boards alongside LinkedIn, Indeed, Workday, Greenhouse, Lever, and the rest of its 11 source platforms, normalized into one [jobs API](/jobs-api) schema. One filter scopes a search to Paylocity-sourced postings:

```
curl https://api.jobspipe.dev/v1/jobs/search \
  -H "Authorization: Bearer jp_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "source_or": ["paylocity"], "job_country_code_or": ["US"] }'
```

Scope to one employer with `company_name_partial_match_or`, or drop the `source_or` filter and search every platform at once - the response shape is identical whether a posting came from a Paylocity board or a Workday tenant. The free tier includes 100 requests a month. For the wider landscape of which ATSs are open and which are gated, see [public vs gated ATS APIs](/blog/public-vs-gated-ats-apis) and [the best jobs APIs of 2026](/blog/best-jobs-api-2026).

Every public Paylocity board, one jobs API - no partner program, free tier included.

## Skip the scraper - try the API right now

Live, normalized postings from 30+ ATS feeds and job boards in one JSON schema. No key, no signup - this sandbox returns sample data in the exact live shape.

Job title WorkplaceRemote onlyAny Results3510Test search

Results

Press **Test search** to see normalized job records rendered here, and the raw JSON on the right.

JSON response`POST /v1/sandbox/jobs/search`

```
{
  "job_title_or": [
    "software engineer"
  ],
  "limit": 3,
  "remote": true
}
```

Advanced: edit the raw request, or copy it as curl

{ "job\_title\_or": \[ "software engineer" \], "limit": 3, "remote": true }

```
curl -X POST https://api.jobspipe.dev/v1/sandbox/jobs/search \
  -H "Content-Type: application/json" \
  -d '{"job_title_or":["software engineer"],"remote":true,"limit":5}'
```

For live results, [get a free key](/signup) (1,000 jobs/month) and swap `/v1/sandbox/jobs/search` for `/v1/jobs/search` with an `Authorization: Bearer` header - request and response shapes are identical.

[

← Previous

Naukri API: what exists, what doesn't, and how to get Indian jobs data

](/blog/naukri-api)[

Next →

Labour market intelligence: what it is, who sells it, and how to get it (2026)

](/blog/labour-market-intelligence)

---
Canonical URL: https://jobspipe.dev/blog/paylocity-api-jobs
Title: Paylocity API: the payroll API vs the job postings you can actually read
Description: The Paylocity API you find first is payroll and HR - partner-gated, customer-sponsored, scoped to one tenant. But every Paylocity recruiting customer also runs a public careers board that embeds its complete job list as JSON, one GET per board. Where that surface lives, why discovering boards is the real problem, and how to query Paylocity postings through one jobs API.

---
Building this integration yourself? The steps above work. The alternative is one API over this source and 30+ others, already normalized and deduplicated. Try it right now - no key, no signup:

```bash
curl -X POST https://api.jobspipe.dev/v1/sandbox/jobs/search \
  -H "Content-Type: application/json" \
  -d '{"job_title_or":["software engineer"],"limit":5}'
```

Sample data, exact live schema. For live data get a free key (1,000 jobs/month) at https://jobspipe.dev/signup, then swap /v1/sandbox/jobs/search for /v1/jobs/search with an Authorization: Bearer header. Full agent index: https://jobspipe.dev/llms.txt?src=md-twin