iCIMS (platform)
iCIMS is an enterprise ATS (the iCIMS Talent Cloud) whose Platform API exposes People, Jobs and Applicant Workflows as profiles under a per-customer path, with a Search API for filtered reads that return matching ids. The Job profile is the requisition object, and tenant administrators define custom fields that the API reads, writes and searches by their customfield id. composerID creates the Job profile for an approved permanent hire and stamps the Intent ID into a tenant-created Job custom field, which the Search API can filter on for read-back.
The public API facts composerID's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.
| Authentication | HTTP Basic with a dedicated API user that the tenant admin provisions in System Configuration, with per-object and per-field permissions (IP allowlisting is common). iCIMS also offers OAuth 2.0 client credentials for newer Talent Cloud and Marketplace integrations; which flow a tenant runs is confirmed at onboarding. |
|---|---|
| API style | REST, JSON, per-customer path. Profiles are read by GET on the object id, created by POST (the new id comes back in the Location header) and updated by PATCH with a partial body. The Search API takes a JSON filter set (field name, values, operator) and returns matching ids, followed by profile GETs; the exact verb and encoding are indicative until confirmed at onboarding. |
| Base URL | https://api.icims.com/customers/{customerId} (resources: people, jobs, applicantworkflows, companies; search at .../search/{objectType}) |
| Objects | people, jobs (requisition profile: jobtitle, folder as status, hiringmanager, recruiter, joblocation, numberofpositions, positiontype, customfield{id}), applicantworkflows (candidate-to-job link and status), companies, talentpools; field names indicative until read from the tenant's profile schema |
| Events / webhooks | Tenant-configured outbound notifications push job, person and workflow-status changes to a registered HTTPS endpoint. Coverage and payload are set per tenant and not every field change raises an event, so composerID pairs them with Search API polls on the Intent ID custom field. |
| Rate limits | Throttled per customer with 429 responses; iCIMS publishes no single figure we can cite. Plan for low tens of requests per second, back off on 429; indicative until confirmed at onboarding. |
“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary, especially around custom fields, approval flows and object extensions.
Deterministic mapping
Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).
Tenant discovery
composerID can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.
Enrichment loop
If the target platform requires a field the Intent record doesn't yet have, composerID emits an enrichment_request back to the intake layer.
An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.
| Object | Canonical fields | Platform target | Required status | Notes |
|---|---|---|---|---|
| Job profile Open the approved requisition |
role_title -> jobtitle, headcount -> numberofpositions, hiring_manager -> hiringmanager, location -> joblocation, status -> folder | POST jobs (Job profile) under /customers/{customerId} | Required | Field names follow the iCIMS Job profile schema and are indicative until read from the tenant; folders, position types and locations are tenant lists resolved to the tenant's ids at onboarding |
| Intent ID correlation Carry the Intent ID |
intent_id -> customfield{id} on the Job profile | Job profile custom field (customfield{id}), created by the tenant admin and enabled for the API user | Required | iCIMS exposes admin-defined custom fields to the API as customfield<id> and the Search API filters on them, so the Intent ID is readable back and queryable. No stock client-supplied external reference on the Job profile is known to us; if the tenant's schema carries one, prefer it. Deep link uses the careers-site job route (illustrative); the recruiter-UI route is confirmed at onboarding. |
| Applicant workflow and job status Close the loop |
hire_status <- applicantworkflows status, requisition_status <- job folder | Search API (search/jobs, search/applicantworkflows) plus tenant outbound notifications | Read scope only | Notifications arrive only for the changes the tenant configures; the Search API poll on the Intent ID custom field is the guaranteed path |
Idempotency & drift: publish + reconcileExpand
Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, composerID supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.
Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). composerID is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.
How scanning works
High-level flow
What gets produced
Portable artefacts
Important: where this platform is tenant-definedExpand
The Intent ID field is a tenant-created Job profile custom field: its customfield id differs per tenant, and the API user must be granted field-level visibility to it (and to every field the create call writes) in System Configuration, or the stamp silently fails to round-trip. Onboarding also captures the folder, position-type and location ids the create call needs, whether the tenant runs Basic-auth API users or OAuth client credentials, which outbound notifications exist and where they post, the throttling the tenant sees in practice, and the recruiter-UI route for the deep link.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.