iCIMS API guide for 2026: what to verify - 100Hires

Before you write code against the iCIMS API, settle six decisions: access, authentication, coverage, sync design, operating limits, and production approval.

Core iCIMS references are public, yet the right build plan still depends on the integration path and each customer's configuration. This guide turns those moving parts into a checklist.

Public complaint evidence is sparse, so individual developer reports stay separate from current official requirements. The real question is fit. iCIMS suits teams that need enterprise depth and a governed process for repeatable integrations.

Key takeaways

• Start with the integration path. Customer-specific and repeatable iCIMS-defined work follow different access, test, and approval routes.
• Do not assume one auth model. Get the approved method and verify the fields and profile types available through that credential.
• Treat Search as a sync tool. iCIMS says its Search API is not for real-time use and applies a 15-minute default staleness value.
• Confirm current limits in writing. Old examples and prior comparison pages do not prove a current universal request quota.
• Compare operating models, not endpoint counts. 100Hires offers a public OpenAPI contract and core ATS CRUD, with verification and initial rate limits.

iCIMS API readiness at a glance

The two APIs expose different operating models. This table frames the questions to answer, not a scorecard.

Save one written output from each step. You should finish with an access decision, auth record, coverage matrix, sync plan, limit sheet, and production checklist.

1. Access path and customer
2. Approved auth and credential owner
3. Object, method, field, and permission matrix
4. Event or background-sync design
5. Current limit and test-condition sheet
6. Approval, release, and maintenance checklist

Want to inspect the 100Hires side first? The 100Hires API guide links to its live contract and explains how keys work.

Step 1: identify the iCIMS integration path

Do not request credentials until you know which path applies. iCIMS documents customer-specific work and repeatable iCIMS-defined integrations.

Customer-specific work

This route starts with an existing mutual customer. The implementation may use custom fields, flat files, API calls, or a mix.

iCIMS says it does not provide a sandbox for this path. Your plan needs a customer-approved test area, test records, owners, and a rollback process.

Repeatable iCIMS-defined work

This route targets an integration that can serve more than one customer. It enters Partner Manager and Developer Support review, then gains test access through that process.

One practitioner, writing from a disclosed personal perspective, described API-key access as tied to paid implementation help or a larger contract. That is one opinion, not an iCIMS policy.

Current partner material describes packaged options with service and fee terms that vary by route. Ask which terms apply to your use case.

Put the choice in a one-page access record. Name the mutual customer, intended users, data direction, environment, commercial owner, and person who can approve production use.

Step 2: confirm authentication and credential ownership

The iCIMS FAQ says teams establish the authentication method with iCIMS and receive credentials for inbound calls. Search requires an Integration User.

List and Profiles examples show Basic authorization. An example is not a universal auth promise, so get the approved method for your service and customer.

Access depends on more than a valid credential. Profile permissions, enabled profile types, field settings, search locks, security rules, and layouts can change the returned data.

• Name the credential owner and the customer it belongs to.
• Record the approved auth method and environment.
• Grant the minimum fields, profiles, and methods needed.
• Document rotation, revocation, and staff offboarding.

A versioned OpenAPI contract can make security schemes and operations easier to review. It is one documentation format, not a requirement for a working API.

Run two permission tests. Read one known safe record, then request one field your integration should not receive. Record both outcomes so a future permission change does not look like random data loss.

Step 3: map objects, methods, fields, and permissions

A successful login proves authentication. It does not prove that the API covers the workflow your team needs.

Search supports GET and POST and returns matching System IDs. List supports GET, PATCH, and POST. List nodes can be hidden, but the reviewed documentation says they cannot be deleted.

Profiles documents GET, POST, and PATCH. Method support varies by profile type, and not every customer enables every profile type.

The operator evidence reviewed points to mapping, cleanup, testing, credentials, compliance, and ownership. A sample request cannot replace that inventory.

The documentation uses several endpoint families and conventions. Treat that as a reason to verify the live path and supported method. It does not prove deprecation.

Decide how IDs cross systems too. Email can change, and one customer's System ID should not be treated as a global person ID. Store a customer-scoped crosswalk and define what happens when a record merges or disappears.

Keep a redacted response sample for every required read. Test a missing optional field, an empty page, and a blocked field before freezing your internal schema.

Step 4: choose events or background synchronization

iCIMS says its Search API is not supported for real-time use. It is meant for background synchronization between systems.

Search returns up to 1,000 matching IDs per page. If the caller does not set staleness, the documented default is 15 minutes.

That has a direct design impact. A query matching 40,000 records needs at least 40 result pages before record fetches, processing, or retries. Polling every minute will not turn a 15-minute default cache into a real-time feed.

Some use cases do have documented push behavior. Job Posting sends job data to a third-party vendor for post and unpost events. That does not establish one webhook model for every object.

• Use a documented event when the required event exists.
• Use polling or background sync where Search is the supported path.
• Set an acceptable delay and a reconciliation schedule.
• Queue IDs, deduplicate work, and make replay safe.

The operator guidance reviewed supports the same rule: request real-time behavior only where the business needs it. Keep the queue and reconciliation logic under your control.

Give each business event an acceptance test. Trigger a known change, measure when it becomes visible, run the handler twice, and compare the final ATS and downstream records.

Step 5: verify current limits, paging, caching, and test conditions

The reviewed Search material confirms a 1,000-match page and a 15-minute default staleness value. The List examples use paging and a 1,000-item child retrieval boundary.

The rate-limit story needs care. A Profiles example contains a 50,000 limit value dated 2012. Prior comparison copy cites 10,000 requests per day. Neither is a verified current universal quota.

The current FAQ says rate limits and integration fees exist, but the linked terms did not render in our anonymous check. Get the current values and commercial terms in writing.

Paging and request limits answer different questions. A 1,000-item page does not grant 1,000 requests, and a request quota does not say how fresh a cached result will be.

• Request window, headers, and overage response
• Paging rules, cache behavior, and concurrency
• Test data, environment, and production approval
• Support escalation and limit-change process

Step 6: finish validation and assign an owner

The repeatable iCIMS-defined path has a formal production sequence. It includes design review, approval, sandbox work, a validation video, logs, field checks, collateral, final approval, listing, and possible revalidation.

Keep that sequence scoped to repeatable work. A customer-specific integration needs a mutual customer and does not receive the same iCIMS sandbox path.

Formal review can add lead time. It can make sense for an enterprise integration that will affect several customers and needs consistent support boundaries.

• Customer, data, security, and release owners
• Sandbox or customer-approved test plan
• Field validation and access checks
• Logging, alerting, replay, and reconciliation
• Support contacts and post-launch review date

Give one person ownership after launch. Integrations change when fields, workflows, permissions, vendors, or downstream systems change.

The release packet should list the deployed version, enabled customers, approved fields, monitors, replay steps, and support contacts. Review it after the first week and after any profile or workflow change.

Common mistakes this checklist prevents

• Starting with an endpoint sample. The team has not yet chosen the access path or confirmed the customer configuration.
• Treating credentials as coverage. A working login may still hide a profile type, field, or method.
• Using Search as a live event feed. The current documentation positions it for background sync.
• Copying an old quota. A dated response header or prior article is not a current service limit.
• Ending at launch. No one owns mapping drift, failed jobs, permission changes, or reconciliation.

Reddit did not yield a direct iCIMS API complaint thread in our search. The implementation-adjacent posts we found concerned allowlisting and workflow changes, which support a planning check, not an API defect claim.

A short pre-build review catches these mistakes cheaply. Finding them after production means debugging access, data shape, timing, and ownership at the same time.

What developers actually dislike about the iCIMS API

This is a bounded evidence synthesis, not a survey of developer sentiment. Reddit and X produced no direct complaint corpus, and the strongest operator evidence came from one focused show.

1. Public visibility varies by page, though core endpoint references are readable.
2. The integration path and customer configuration can matter as much as endpoint syntax.
3. Mixed conventions force a live-path check, without proving that an endpoint is deprecated.
4. Repeatable integration work has review and validation steps that add project work.
5. Search is a background-sync tool, so a real-time query design needs a different approach.

These are real planning costs. They do not support calling the API unusable, closed, or universally tied to a partner contract.

Where iCIMS is a reasonable choice

iCIMS makes sense when it is already the enterprise system of record and the team can staff the integration lifecycle.

Its configurable profiles and formal repeatable-integration process may suit organizations that value governed change and customer-specific controls.

Treat iCIMS product strengths in customization, reporting, support, integrations, and candidate management as context, not as an API performance test.

That enterprise fit matters. A public developer surface can be easier to inspect, but teams should compare governance, partner review, and internal support needs separately.

How the 100Hires API compares

The live 100Hires API uses https://api.100hires.com/v2 as its base and publishes a public OpenAPI 3.1 contract.

Our parse found 89 paths and 133 operations. The contract documents CRUD for candidates, jobs, applications, and notes.

It has job-level and company-level webhook subscription operations for listing, creating, and deleting subscriptions, and rotating secrets. Path or operation totals describe surface area, not quality.

The current API page says every 100Hires plan includes API access without an added API fee. A working key still requires company verification.

Each key belongs to one user and company. Account permissions may mask candidate values. New or unapproved keys start at 100 requests per 10 minutes and return 429 when that limit is reached.

List endpoints use one-based pages. The allowed page size is 1 to 100, with 20 as the default.

One current documentation conflict needs disclosure. The live OpenAPI describes signed v2 webhooks, HMAC-SHA256, one-time secrets, and secret rotation.

A separate live 100Hires webhook page says raw webhooks have no signing secret or built-in retries. The checked sources do not establish whether the copy covers different products or versions.

Build against the live OpenAPI contract and confirm the exact webhook product before production. Do not assume one page resolves the conflict for every account.

100Hires limitations

• Company verification must pass before a key works.
• The initial limit may be too low for a high-throughput enterprise sync.
• The checked evidence does not establish OAuth, an official SDK, or a sandbox.
• The webhook signing and retry documentation needs reconciliation.
• The inspected ICP material targets teams up to about 500 employees, not every multinational deployment.

A simpler developer path does not replace iCIMS-scale governance or an existing enterprise system of record. See the broader 100Hires recruiting software fit before treating the API as the whole buying decision.

Which API model fits your team

Put the two API contracts side by side for the three workflows that matter most to your team.

Choose iCIMS when it already anchors enterprise recruiting and your team can own the governed integration lifecycle. Consider 100Hires when a smaller team values a public contract and direct CRUD over core ATS objects, and its verification and initial limits fit the workload.

If you want to test the 100Hires model against your workflows, book a demo. You can review more ATS API guides on our ATS API comparison hub.

Frequently asked questions

Is the iCIMS API public?

Core iCIMS endpoint references were publicly readable in our anonymous check, but some linked authentication, service, and community material was not. 100Hires publishes a public OpenAPI contract, though a working key still needs company verification.

Do you need to be an iCIMS partner to build an integration?

Not always. iCIMS separates customer-specific work for a mutual customer from repeatable iCIMS-defined integrations. 100Hires does not document an equivalent partner gate for its core API, but company verification and key permissions still apply.

Is the iCIMS Search API real time?

No. Current iCIMS documentation positions Search for background synchronization and uses a 15-minute default staleness value. 100Hires documents job and company webhook subscriptions in its OpenAPI, but its current documentation conflicts on signing and retries, so confirm those details.

Does iCIMS provide a sandbox?

The repeatable iCIMS-defined process includes sandbox access after review and approval. The customer-specific path says no iCIMS sandbox is provided. 100Hires did not expose a public sandbox claim in the sources checked.

What does the 100Hires API cover?

The live 100Hires OpenAPI documents CRUD for candidates, jobs, applications, and notes. It documents job and company webhook subscription management too. Verification, permissions, masking, and initial rate limits apply.

Is 100Hires API access included in every plan?

The current 100Hires API page says every plan includes API access without an added API fee. Company verification, user-company key scope, permissions, masking, and the initial 100 requests per 10 minutes still apply.