--- title: "Paycom Jobs API: a developer's reference - JobsPipe" description: "Paycom has no public jobs API. The Client API is private to each customer. How the actual data path works, where to read postings from, and when reaching for a unified jobs API saves weeks." canonical: https://jobspipe.dev/guides/paycom-jobs-api date_published: 2026-05-27 date_modified: 2026-05-27 author: Dvir Atias --- # Paycom Jobs API. A developer’s reference. Paycom doesn’t ship a public jobs API - the Client API is private to each Paycom customer. Here is what the actual data path looks like, what breaks at scale, and when a unified jobs API saves you from per-customer scrapers. Reference·Updated May 2026·9 min read On this page 1. [The short answer](#short-answer) 2. [What the Client API actually is](#client-api) 3. [The actual public surface](#public-surface) 4. [Why scraping breaks at scale](#scraping-realities) 5. [When to use a unified API instead](#when-to-use) 6. [FAQ](#faq) ## The short answer Paycom has one API, and it is not the one most developers searching for “Paycom jobs API” are looking for. The **Client API** is Paycom’s authenticated, per-customer surface for HR and payroll operations - employees, time, payroll, benefits, and (in some plans) recruiting records. It is private to each Paycom customer and not available to third parties at all. There is no public, multi-tenant Paycom jobs API. If you want to read postings across many Paycom-using companies - for a job board, an aggregator, a sales-trigger workflow, or labor-market research - Paycom does not offer a first- party path. The data exists publicly, but only as rendered careers pages on paycomonline.net subdomains. The realistic options are: per-customer scrapers (real ongoing maintenance), per-customer Client API agreements (impractical for any cross-company use case), or a unified jobs API that handles the integration centrally. ## What the Client API actually is The Paycom Client API is HRIS-shaped. Its design assumes one customer reading or writing their own data through credentials Paycom issued to them. Employees, payroll runs, time-and-attendance, benefits enrollment, and custom fields are the primary surface. The recruiting module exists in some plans, but exposing job postings across the Paycom customer base is not a use case Paycom’s API model supports. Even within a single customer, getting Client API credentials is a Paycom-customer-mediated process - the customer has to mint and share them. There is no self-serve sandbox, no public OpenAPI spec, and no path for an independent developer to access the API across customers. ## The actual public surface Every Paycom customer with active job postings hosts their careers page on a Paycom-provided subdomain - typically `.paycomonline.net` - or embeds Paycom on a customer-owned domain via a vendor-managed iframe. The HTML on those pages renders openings, application forms, and basic posting metadata. Underneath, the page calls an internal Paycom endpoint that returns the job data in a structured shape, but that endpoint is not documented, not stable across Paycom releases, and not consistent across customers. Some customers run a newer version of the careers widget with different field names than older deployments. Any third-party integration has to account for that drift. There is no list endpoint for “every Paycom customer’s board” - you have to discover each customer’s subdomain by some other means (their company website’s careers link, a Google site: search, or a maintained directory). ## Why scraping breaks at scale Three problems compound when you try to consume Paycom postings across many customers via scraping. **Discovery.** No list of Paycom customers exists publicly. You build the list by hand, by site: search, or by maintaining a curated directory. New customers appear, old ones churn off Paycom, and you find out by missing data. **Shape drift.** The internal endpoint the careers widget calls changes between Paycom releases. What worked last quarter may return a different JSON shape this quarter. The careers HTML changes too. Both require ongoing maintenance per customer config. **Rate limits and blocks.** Paycom rate- limits per-domain and runs CDN-level abuse protection. A scraper hitting many customer subdomains from one IP gets blocked fast. IP rotation, polite crawl cadences, and careful retry logic become real engineering work. ## When to use a unified API instead If your need is “Paycom data for one of my customers, who is already a Paycom customer too” - request Client API credentials from them and integrate directly. That is the supported path. If your need is “Paycom postings across many customers” - a job board, sourcing tool, hiring-signal intent product, or labor-market research - direct integration doesn’t scale. A unified jobs API like does not collect Paycom, but Paycom employers also post the same roles to LinkedIn and Indeed, which it does collect, so a company-name search reaches them in one normalized JSON schema across 30+ sources. The free tier includes 1,000 credits to start, with no Paycom partner application. Coverage of any one Paycom employer depends on where else it posts. The integration cost is one HTTP request. ## FAQ Does Paycom have a public jobs API?+ No. Paycom's Client API is private and per-customer - it's reachable only by active Paycom customers, for their own data. There is no first-party multi-tenant endpoint that returns job postings across many Paycom-using companies. Anyone searching for a 'Paycom jobs API' is usually trying to aggregate postings across customers, which is not a supported use case from Paycom directly. What is the Paycom Client API?+ The Client API is Paycom's authenticated HRIS-shaped surface for an individual customer to read or write their own data - employees, payroll, time, benefits, and (in some plans) recruiting records. Credentials are issued by Paycom to the customer, not to third parties, and scoped to that customer's tenant. It is not a developer self-serve API. Where do Paycom job postings actually live?+ Most Paycom customers host their careers pages on subdomains of paycomonline.net (the most common pattern), though some embed Paycom on customer-owned domains. The job data is reachable through the public HTML rendering of those pages, but Paycom does not expose a consistent JSON endpoint across customers. Can I scrape paycomonline.net to get jobs?+ Technically yes. Each Paycom customer is a separate scraper config, the HTML changes occasionally, and you'll need IP rotation to stay under Paycom's per-domain rate limits. For ongoing production use, the maintenance burden is real - selectors break when Paycom ships updates, and there's no aggregation across customers without per-tenant configs. How does JobsPipe handle Paycom?+ JobsPipe does not collect Paycom. Paycom employers also post the same roles to LinkedIn and Indeed, which JobsPipe collects, so a company-name search on POST /v1/jobs/search reaches them in one normalized JSON schema across 30+ sources. Free tier of 1,000 jobs to start, with no Paycom partner application. What does a JobsPipe record include?+ Title, company, location (city, region, country, remote flag), salary (parsed when available), employment type, posted\_at, apply\_url, and full description. Same shape for every source JobsPipe collects, whether the posting comes from Workday, LinkedIn or Indeed. Does JobsPipe access private Paycom data?+ No. JobsPipe does not collect Paycom at all, and never has access to Paycom Client API endpoints, customer credentials, employee records, or payroll data. How fresh are the Paycom employers' roles JobsPipe returns?+ As fresh as the source they were found on: every source JobsPipe collects is refreshed at least every 24 hours, and high-volume sources more often. Every public Paycom careers site, one endpoint. Free tier, self-serve signup, no partner application. [Paycom source page](https://jobspipe.dev/sources/paycom)[JobsPipe Jobs API](https://jobspipe.dev/jobs-api)[How to build a job aggregator](https://jobspipe.dev/guides/how-to-build-a-job-aggregator)[What is an ATS API?](https://jobspipe.dev/glossary/ats-api)[ADP API: the developer’s reality check](https://jobspipe.dev/guides/adp-api) ## Further reading - [Which ATS APIs are actually public? The 2026 job-data reference](https://jobspipe.dev/blog/public-vs-gated-ats-apis) - [Unified API platforms: the two kinds, and which one job data needs](https://jobspipe.dev/blog/unified-api-job-data) --- Building this integration yourself? The steps above work. The alternative is one API over 30+ sources, already normalized and deduplicated. Try it right now - no key, no signup: ```bash curl -d '{"limit":3}' https://api.jobspipe.dev/v1/sandbox/jobs/search ``` Sample data, exact live schema. For live data get a free key (1,000 jobs to start) 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