iCIMS Job Board Scraper — any icims.com careers portal

Collect job postings from any iCIMS-hosted careers portal on icims.com. Give this Actor an iCIMS portal URL or tenant subdomain, and it returns the portal's postings with title, company, department, employment type, location split into city, state and country, remote flag, posted date and apply URL.

iCIMS renders its job cards server-side into one platform-wide template, so this Actor reads that markup directly: every tenant ships the same job-card shape from the same platform build. Postings are collected by following the portal's own rel="next" paginator, up to 200 pages per board.

No iCIMS account, login, API key or cookies are used. This Actor reads the public careers portal that a logged-out visitor sees.

What it returns

Field	Type	Notes
jobId	string	iCIMS's own posting ID, taken from the job URL — stable, use it to de-duplicate
title	string
company	string	From the tenant's own company field — Company, Subsidiary, Brand, Business Unit and similar. null when the portal publishes none
tenant	string	The iCIMS portal subdomain, e.g. careers-emcorgroup
location	string	Verbatim, in iCIMS's coded form country-state-city, e.g. "US-PA-Wilkes-Barre". A posting open in several places lists them all, pipe-separated
city, state, country	string	Split from that coded form, describing the first location listed. null when a tenant writes a location outside the coded form
isRemote	boolean	From the tenant's workplace field where it publishes one, otherwise from the location. null when neither is present
department	string	From the tenant's category field — Category, Department, Function, Job Family and similar. null when the portal publishes none
employmentType	string	From the tenant's type field — Position Type, Employment Type, Full/Part Time and similar. null when the portal publishes none
postedAt	string	YYYY-MM-DD, or YYYY-MM-DDTHH:MM:SS when the portal publishes a time. Kept as a local wall-clock stamp — iCIMS renders the posting time in the portal's own timezone and never states which
jobUrl	string	Direct link to the posting
boardUrl	string	The portal a person would open, https://<tenant>.icims.com
sourceUrl, collectedAt	string	Provenance for every row

Input

{ "boards": ["https://careers-emcorgroup.icims.com"], "maxItems": 1000 }

Field	Description
boards	iCIMS portal URLs or tenant subdomains on icims.com. Required, 1–100.
maxItems	Cap on dataset items. Default 1000, maximum 50,000. Free plans stop at 250 requests and 250 results — see below.
concurrency	Portals fetched in parallel. Default 3, maximum 5.

maxItems is a budget shared across every portal in the input, and each portal stops paginating as soon as the run can no longer keep the rows — so a hundred portals under a thousand-row cap fetch a thousand rows rather than a hundred portals in full.

Use cases

• Tracking enterprise and high-volume hiring across a watchlist of iCIMS careers portals
• Competitor headcount signals by location, department and employment type
• Filling an ATS, job board or talent CRM with live postings straight from the employer
• Recruiting lead lists filtered on city, state, country or isRemote
• Monitoring a portal over time by re-running on a schedule and diffing on jobId

Reliability

iCIMS serves its job cards from one platform-wide template, so the card shape is the same across every tenant. What varies is which fields a tenant turns on and what it calls them — Job Locations against Location, Category against Function against Department. Every value is labelled in the markup, so this Actor reads the labels and maps them to contract fields rather than relying on positions. A field a tenant does not publish comes back null rather than holding another column's value.

iCIMS answers with the branded portal wrapper — no cards and no pagination — unless a request presents iframe-context fetch metadata. That is not a URL parameter: without those headers a portal that lists 1,450 postings returns a 98KB shell with zero job cards. Those headers are sent on every page request.

The paginator is markup a tenant can rewrite, so a rel="next" link pointing off the portal's own host is not followed.

A portal that cannot be read is recorded in the run's SUMMARY under failures rather than silently returning fewer rows, and a run where every portal failed exits with an error.

Frequently asked questions

How do I find a company's iCIMS portal URL? An iCIMS careers portal lives at https://<tenant>.icims.com, where the tenant is a subdomain the company chose — for example careers-emcorgroup. Open the company's "careers" or "search jobs" link and copy the host from the address bar. You can pass the full URL or just the subdomain.

Do I need an iCIMS account, API key or login? No. This Actor reads the public job search that any logged-out visitor can see. No account, no cookies, no session.

How many job postings does one request return? It depends on the portal — iCIMS lets each tenant set its own page size. This Actor follows the portal's own rel="next" link until the rows run out, up to 200 pages per board.

Does it work for any company on iCIMS? Yes — any careers portal on icims.com, addressed by its tenant subdomain. Nothing is hardcoded per company.

Why are company, department and employmentType sometimes empty? iCIMS lets each tenant choose which fields appear on a job card and what to call them. Those three are only filled when the portal publishes a matching labelled field on the card.

Is postedAt in UTC? No, and deliberately not stamped as if it were. iCIMS renders the posting time in the portal's own timezone and never states which one, so the value is kept as a local wall-clock stamp rather than being given an invented offset.

Limitations

Job-card fields only: no job description body, no compensation, no application counts and no recruiter contacts. The full JobPosting structured data lives on each posting's detail page, which this Actor does not open. A posting open in several locations has all of them in location, but city, state and country describe only the first. Only icims.com portals are accepted — a URL on any other host is rejected rather than fetched.

Free plan limit

Runs started from an Apify free plan stop at 250 requests and 250 results, and the run reports that it reached the limit. Any paid plan runs the full input and maxItems you set.

The limit exists because this Actor fetches through our own infrastructure, which Apify does not cover for free-plan runs. It binds on requests as well as results so that a large input list cannot spend those fetches for rows the run will not return.