iCIMS API: Live Job Postings from iCIMS Career Sites

An unofficial iCIMS API for public job postings. Paste a career-site address such as https://careers-rambus.icims.com, or just the company name, and get back every open role as structured JSON: job title, employer, locations, requisition ID, employment type, category, posted and expiry dates, the full description, and the apply link.

iCIMS is one of the largest applicant tracking systems in the world, used by roughly a quarter of the Fortune 500 across healthcare, manufacturing, retail, logistics, financial services, and semiconductors. Those postings sit on the employer's own career site, which is the original source, ahead of the job boards that syndicate from it. iCIMS publishes no public jobs API, so this Actor reads the career sites the way a browser does. You do not need a login or an API key, nothing runs a headless browser, and the results are not served from a database someone filled last week.

This is an independent tool. It is not affiliated with, endorsed by, or connected to iCIMS, and it reads only pages that are already public.

Why use this iCIMS API

• Reads the career site right now. Results come from the employer's live site during your run, not from a cached copy collected days ago.
• Knows what changed. Every job carries a last-changed timestamp, and newerThan returns only jobs posted or updated since a date you pick. Poll a career site daily and get back the handful of jobs that actually moved.
• Covers both kinds of iCIMS site. Classic iCIMS portals on icims.com and modern iCIMS career sites hosted on the employer's own domain are both detected automatically from the URL you give it.
• Stable job identity. Job URLs are normalized so the same requisition keeps the same URL even after the employer edits the job title. Deduplicating across runs actually works.
• The employer's own requisition ID. The reference a recruiter quotes internally, not just a number from the URL.
• Real posted dates. iCIMS does not print a posted date on the page. This returns one anyway, read from the structured data the page carries.
• Descriptions in the format you need. Plain text, original HTML, or Markdown, which is the friendliest form for feeding a job description to an AI model.
• Explains what it cannot reach. A career site that is missing, restricted, or not iCIMS produces a labelled error row rather than a silent gap in your data.

Use it as an ATS API for iCIMS employers

Most ATS API products are unification layers: you pay a per-seat integration vendor, connect an employer's account, and get their data with permission. That is the right tool for reading a customer's own private ATS.

This is the other half. It reads what an iCIMS employer has already published to the public web, so there is no account to connect and no setup per employer. Point it at a career site and it returns that employer's live roles. That matters most when you are working across many employers at once, building a job board or mapping who is hiring in a market, where per-employer onboarding is the thing that makes the project impossible.

What you can extract

Field	Description
url	Canonical job URL, stable across title edits, and the key to deduplicate on
id	The employer's own requisition ID, for example 2026-23020
title	Job title as published
organization	Hiring employer
organization_url	The employer's own website, when published
description_text	Full description as readable plain text
description_html	Full description with the employer's original markup
description_markdown	Full description as Markdown, headings and bullets preserved
employment_type	Normalized code such as FULL_TIME, PART_TIME, CONTRACTOR, INTERN
locations_derived	Work locations as readable City, Region, Country strings
remote_derived	Whether the role reads as remote
date_posted	When the employer published the job, ISO-8601
date_updated	When the posting last changed, ISO-8601, the field to monitor
date_validthrough	When the posting expires, when published
salary_raw	Pay range exactly as the employer published it, never inferred
category	Job family or department
additional_fields	Extra labelled fields the employer shows, such as travel percentage or visa sponsorship
apply_url	Direct application link
latitude, longitude	Coordinates, on modern iCIMS career sites
tenant, source_domain, source_surface	Which career site the job came from and which kind it is
error_code, error_message	On error rows only: why a career site could not be collected

Input parameters

Parameter	Type	Required	Default	Description
startUrls	array	one of these two	[]	Career sites to collect. Accepts a career-site root, a sitemap.xml, a /jobs/search page, a single job URL, or a modern iCIMS career site on an employer domain.
companies	array	one of these two	[]	Company names as a shortcut. rambus expands to https://careers-rambus.icims.com. Full URLs also accepted.
newerThan	string	no	empty	Return only jobs posted or updated since this moment. Accepts 24h, 7d, 2w, or an ISO timestamp such as 2026-08-01.
cutoffField	string	no	updated	Which date the cutoff compares against. updated catches edits to older postings; posted returns genuinely new roles only and makes the run cheaper on modern career sites.
includeDetails	boolean	no	true	false selects list-only mode: job URL, requisition ID, and change timestamp, one request per site.
descriptionFormat	string	no	both	both, text, html, or markdown.
keywords	array	no	[]	Keep only jobs matching a keyword. Sent to the site's own search on modern career sites; matched against title, category, and description on classic portals.
maxJobsPerSite	integer	no	0	Stop after this many jobs per career site. 0 means every live job.
maxJobs	integer	no	0	Stop the whole run after this many jobs across every site. 0 means no overall limit.
detailConcurrency	integer	no	5	Parallel job-page requests on classic portals, 1 to 10.
proxyConfiguration	object	no	disabled	Optional proxy, needed only for career sites restricted to trusted networks.

Scrape job postings from any iCIMS career site

Every common address form works, and the right approach is picked automatically:

• A career-site root: https://careers-rambus.icims.com
• Just the company name, in the companies field: rambus
• A sitemap: https://careers-rambus.icims.com/sitemap.xml
• A search page: https://careers-rambus.icims.com/jobs/search
• A single job: https://careers-rambus.icims.com/jobs/23020/job
• A modern iCIMS career site on the employer's own domain: https://careers.icims.com

Use cases

• Track hiring at named accounts. Watch a list of employers and see every new requisition the day it appears, before it reaches the job boards.
• Build or backfill a job board. Pull complete, source-of-truth postings with real posted dates and working apply links.
• Monitor changes, not just new jobs. date_updated moves when an employer edits a posting, so you can catch a changed title, salary, or location.
• Recruitment market research. Measure demand by role, category, and location across employers on the same platform.
• Sales and competitive signals. Hiring activity is a reliable indicator of budget, expansion, and new initiatives.
• Feed an AI agent. Markdown descriptions and normalized fields drop straight into a model prompt without extra cleanup.

How to get started

View on Apify Store

Example input

{
  "startUrls": [{ "url": "https://careers-rambus.icims.com" }],
  "maxJobsPerSite": 50,
  "descriptionFormat": "both"
}

Only jobs added or edited in the last week, across several employers:

{
  "companies": ["rambus", "sas"],
  "startUrls": [{ "url": "https://careers.icims.com" }],
  "newerThan": "7d"
}

Example output row

{
  "result_type": "job",
  "url": "https://careers-rambus.icims.com/jobs/23006/job",
  "id": "2026-23006",
  "title": "Design Verification Principal Engineer",
  "organization": "Rambus",
  "organization_url": "https://www.rambus.com",
  "description_text": "Overview\n\nRambus, a premier chip and silicon IP provider...",
  "employment_type": ["OTHER"],
  "locations_derived": ["Hillsboro, OR, United States"],
  "remote_derived": false,
  "date_posted": "2026-08-03T04:00:00+00:00",
  "date_updated": "2026-08-10T15:30:21+00:00",
  "date_validthrough": "2027-08-03T04:00:00+00:00",
  "category": "Engineering",
  "additional_fields": { "Job ID": "2026-23006", "Category": "Engineering" },
  "apply_url": "https://careers-rambus.icims.com/jobs/23006/design-verification-principal-engineer/job?mode=apply",
  "tenant": "rambus",
  "source": "icims",
  "source_type": "ats",
  "source_surface": "portal",
  "source_domain": "careers-rambus.icims.com"
}

Cheap change detection with list-only mode

Turn includeDetails off and the Actor returns just the job URL, requisition ID, and last-changed timestamp for every live job, using a single request per career site. That is the inexpensive way to poll on a schedule.

The pattern that works well: run list-only every morning, compare date_updated against what you stored yesterday, then run again with details on only the jobs that moved.

{
  "companies": ["rambus"],
  "includeDetails": false,
  "newerThan": "24h"
}

Choosing what the cutoff means

cutoffField decides which date newerThan compares against, and it changes both the results and the cost.

• updated, the default. Matches a job posted or edited since the cutoff. Use it to catch a changed title, salary, or location on a role that has been open for months. This is the thorough option, and on a classic portal it is also the cheap one, because the sitemap gives a change timestamp for every job in a single request and only the jobs that moved are fetched.
• posted. Matches only genuinely new roles and ignores edits. On a modern iCIMS career site this lets the run ask for newest-first and stop as soon as it reaches older jobs, so a fortnightly window on a busy career site reads one page instead of all of them.

The trade is real, so pick deliberately: posted will not show you a role that was posted in March and rewritten yesterday.

{
  "startUrls": [{ "url": "https://careers.icims.com" }],
  "newerThan": "14d",
  "cutoffField": "posted"
}

🔌 Integrations: turn iCIMS job data into a standing pipeline

One run answers a question. A schedule builds a dataset. Most of the value here comes from running it on a timer and diffing the results.

• Tasks and Schedules. Save an input as a Task, then attach a Schedule to run it nightly or hourly. Pair a scheduled list-only run with newerThan and you have a change feed for a set of employers.
• Webhooks. Fire an Apify webhook on run completion to push new rows straight into your own service the moment they land.
• n8n. See the n8n section below for the community node.
• Make and Zapier. Use the Apify integrations to start a run and route rows into a CRM, an applicant tracker, or a spreadsheet.
• Supabase, Postgres, and warehouses. Dataset exports in JSON or CSV load cleanly. url is a stable primary key, and date_updated is the column to upsert on.
• MCP. See the MCP section below to hand this to an AI assistant as a tool.

Career sites that restrict access

Some employers restrict part of their iCIMS career site to trusted networks. Most often it is only sitemap.xml that is protected while job search and the job pages stay open, so this Actor detects that case and switches to reading search results instead. You get the jobs either way; the only thing lost is the sitemap's change timestamp, so newerThan is applied after each job is fetched rather than before.

When an employer restricts the whole career site, the run returns an error row with error_code set to ip_gated rather than failing silently. Enabling proxyConfiguration with residential proxies resolves some of them. A few employers allow only their own corporate network, and no scraper can reach those from outside.

The proxy is off by default, and you only need it for those restricted sites. Job pages fetched through a proxy are billed at a separate, higher per-job rate, because iCIMS serves job pages uncompressed and proxy traffic is metered by the gigabyte. Ordinary runs are unaffected, and list-only runs stay on the low rate whether or not a proxy is used.

Other error codes work the same way: tenant_not_found for a career site that does not exist, not_icims for a domain that turns out to run something else, and http_error or network_error for transport problems.

🪢 Use this from n8n

An n8n community node for this Actor is published on npm, so you can drop iCIMS job data into any n8n workflow without writing HTTP requests by hand.

Python example repo

A public example repository shows how to call this Actor from Python and how to wire it into MCP clients, with copy-paste code for the common recipes.

💰 Pricing (pay-per-event)

You pay per job returned, with no per-run setup fee beyond a small run-start charge. There are three per-job rates, and which one applies depends on how much work you asked for:

• Full job postings are the standard rate: one charge per job written to the dataset.
• List-only jobs are charged at a much lower rate, because the whole career site is read in a single request. This is what makes daily change-detection polling cheap enough to schedule.
• Jobs fetched through a proxy carry a higher rate. iCIMS serves job pages uncompressed and proxy traffic is metered by the gigabyte, so a proxied page genuinely costs more to produce. The proxy is off by default and only needed for career sites restricted to trusted networks.

None of the three per-job rates apply to an error row, so a career site that cannot be reached does not bill you for jobs it never returned. A run that produces only errors still costs the run-start charge and Apify's standard per-dataset-item fee, which together come to a fraction of a cent. Current per-event prices are shown on the Store card and in the Actor's Monetization details.

🔗 Related Tools

Job and hiring data across the rest of the portfolio:

• Workday Careers API: the same job for Workday career sites, the other enterprise ATS you will hit constantly.
• LinkedIn Jobs API: job listings and salary data from the destination side of the market rather than the employer side.
• Glassdoor Reviews API: employer reviews and ratings, useful for scoring the companies you find here.
• LinkedIn Company API: firmographics to enrich the organization field into a full company record.
• Crunchbase Company API: funding and investor data, so hiring activity can be read against the money behind it.

For contrast, benthepythondev/icims-jobs-scraper also targets iCIMS, but reads only the modern career-site API and misses classic iCIMS portals entirely, which is where most Fortune 500 tenants still are.

🔌 Use this API from Claude (MCP)

Add this Actor as a tool in Claude Code (free trial), Claude Cowork (free trial), or any other MCP client, through the hosted Apify MCP server:

https://mcp.apify.com/?tools=actors,docs,johnvc/icims-careers-api

Setup walkthrough:

Apify MCP integration docs: https://docs.apify.com/platform/integrations/mcp

💸 Pay per run with crypto (x402)

You can pay for a run with USDC on Base using the x402 standard, with no Apify account and no API token. This suits autonomous agents that need data without holding a subscription.

Apify x402 docs: https://docs.apify.com/platform/integrations/x402

FAQ

Is iCIMS an ATS?

Yes. iCIMS is an applicant tracking system, the software an employer uses to post roles and manage candidates. When a company hires through iCIMS, its public career site is served by iCIMS, which is what this Actor reads.

Is there an official iCIMS API for job postings?

No public one. iCIMS sells API access to its own customers for their own data. There is no public endpoint for reading an employer's live postings, which is why this reads the public career site instead. It is an unofficial tool and is not affiliated with iCIMS.

Is this an API or a web scraper?

Both descriptions fit. It behaves like an API: you send structured input and get structured JSON back, callable from any language or from MCP. Under the hood it is a scraper, because iCIMS exposes no public jobs endpoint, so it reads the same public pages a browser would.

How do you scrape job postings from iCIMS?

Classic iCIMS portals publish an open sitemap listing every live job with a change timestamp, and each job page carries structured data describing the posting. Modern iCIMS career sites expose a public jobs endpoint that already returns the full record. This Actor detects which kind of site you gave it and uses the right path.

Can you tell the job posting date from iCIMS?

Yes, and this is a common frustration: iCIMS career pages usually do not print a posted date anywhere on screen. The date is in the page's structured data, so date_posted comes back on every job. date_updated additionally tells you when the posting last changed, which is what the sitemap tracks.

How do I use this from an MCP server?

Add the hosted Apify MCP URL above to any MCP client and the Actor becomes a callable tool. Field descriptions in the input and output schemas are written for an agent to read, so a model can work out which parameters it needs without extra prompting.

Can I get only the jobs that changed since my last run?

Yes, that is what newerThan is for. Give it a relative window such as 24h or 7d, or an exact timestamp. On classic iCIMS portals the filter is applied before any job page is fetched, so unchanged jobs cost you nothing.

Can I run this on a schedule and connect it to other apps?

Yes. Save your input as a Task and attach a Schedule, then route the output through webhooks, n8n, Make, or Zapier. See the Integrations section above for the full list.

How do I find an employer's iCIMS career site?

Most classic sites follow careers-{company}.icims.com, so the companies field usually resolves it from the company name alone. Employers on a modern iCIMS career site use their own domain, commonly careers.{company}.com; paste that address into startUrls and it is detected automatically. An address ending in icims.com is a genuine iCIMS-hosted career site, which is worth knowing given how often people ask whether one is legitimate.

How is this different from a job aggregator?

An aggregator serves a copy collected on its own schedule, so postings can be stale and closed roles can linger. This reads the employer's career site during your run, which is the same source the aggregators collect from.

Does it return expired or ghost jobs?

Classic iCIMS portals list only live jobs in their sitemap, and a job removed mid-run is detected and skipped rather than returned as data.

Which employers can it not reach?

Career sites restricted to trusted networks, reported as ip_gated. Residential proxies clear most; employers restricting to their own corporate network cannot be reached from outside.

Does it work with multiple employers in one run?

Yes. Combine as many entries as you like across startUrls and companies. Use maxJobs as a single ceiling for the whole run, and duplicates across inputs are removed automatically.

🌐 About Alpha OSINT

More open-source data sources and API guides: Alpha OSINT

Last Updated: 2026.08.15