.png)
iCIMS Integration Guide
Connect iCIMS recruiting data with enterprise systems through REST APIs, selected event notifications, document resources, and OAuth-based workflows.
iCIMS integration options at a glance
iCIMS primarily supports REST API integration for reading and updating People, Jobs, Applications, Companies, Locations, and other recruiting data enabled for a tenant. Selected iCIMS services also provide event-notification or callback capabilities, although coverage and payloads must be confirmed for each event. Candidate documents and attachments may be available through supported resources. OAuth 2.0 is the expected authentication approach, subject to tenant permissions and API-specific configuration. Martini can consume these APIs, receive supported callbacks, paginate and checkpoint scheduled synchronizations, transfer documents, apply mappings and business rules, and expose a controlled REST façade for downstream applications.
| Integration point | Supported by iCIMS? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Read and update People, retrieve Jobs and Applications, access Companies and Locations, and publish normalized recruiting data. | Martini can consume iCIMS REST endpoints from workflows, map responses, apply business rules, and expose REST APIs as a controlled façade. |
| Webhooks and outbound callbacks | Limited | Receive notifications for selected recruiting events or integration scenarios supported by the tenant and iCIMS service. | Martini can receive supported callbacks, validate them, retrieve the current object, and process duplicate or failed deliveries safely. |
| File and attachment APIs | Limited | Retrieve candidate resumes, cover letters, and other application documents where the tenant and API product enable document resources. | Martini can transfer binary content and metadata, route files to another system, and persist source identifiers to prevent duplicate transfers. |
| Bulk and batch APIs | Not confirmed | A dedicated bulk or asynchronous endpoint may be available for selected API products, but it must be confirmed for the required data set. | Where no bulk endpoint is enabled, Martini can run scheduled, paginated workflows with checkpoints, throttling, and retries. |
| Scheduled synchronization | Yes | Extract People, Jobs, Applications, or other permitted objects incrementally when event coverage is unavailable or incomplete. | Martini can schedule workflows, maintain external checkpoints, use lookback windows, and reconcile transferred data. |
| Authentication | Yes | Authenticate API requests using OAuth 2.0 credentials, client identifiers, secrets, tokens, and tenant-specific permissions. | Martini can manage secured environment configuration and authentication settings without embedding secrets in mappings or source code. |
| SDKs and custom logic | Limited | Direct HTTP API consumption is the normal approach; specialized pagination, signing, or document processing may require custom logic. | Martini supports workflow transformations and can use JVM-compatible custom logic such as Groovy when standard processing is insufficient. |
| Database access | No | Direct access to the iCIMS production database is not an appropriate integration mechanism. | Martini should use supported iCIMS APIs and notifications rather than attempting direct vendor-database connectivity. |
How iCIMS exposes data and business events
iCIMS REST APIs
REST is iCIMS's primary standards-based integration approach. The applicable API product and tenant permissions determine which People, Jobs, Applications, Companies, Locations, documents, and operations are available.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to iCIMS, retrieves or updates resources, validates the response, transforms fields into a canonical model, applies business rules, and writes to the target system. Checkpoints and source identifiers support incremental synchronization and replay-safe processing.
Implementation sequence
iCIMS Event Notifications
iCIMS provides event-notification or webhook-style capabilities for selected recruiting events and services. Coverage, payload completeness, delivery security, and retry behavior must be verified for each tenant and event.
Martini implementation pattern
Martini implementation pattern: an exposed workflow endpoint receives the callback, validates its security requirements, extracts the affected object identifier, retrieves the current iCIMS resource when necessary, and updates downstream systems. Persisted event or object identifiers protect against duplicate delivery.
Implementation sequence
iCIMS Document Resources
Candidate resumes, cover letters, and other application documents may be available through iCIMS document or attachment resources when enabled for the tenant and API product.
Martini implementation pattern
Martini implementation pattern: a workflow retrieves permitted binary content and metadata, checks size and content requirements, transfers the document to a document or HR platform, and stores the source document identifier and outcome for reconciliation.
Implementation sequence
Scheduled iCIMS Synchronization
Scheduled API extraction is a practical fallback when required event coverage is unavailable. Dedicated bulk or asynchronous APIs are not confirmed and must be checked for the selected iCIMS product.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow queries filtered and paginated endpoints, uses a persisted checkpoint and lookback interval, throttles requests, and reconciles expected versus transferred People, Jobs, Applications, or documents.
Implementation sequence
Common iCIMS integration patterns
Pattern 1: Sync candidates and applications to Workday
When to use this pattern
Use this pattern when recruiting data must enter downstream HR processes after a candidate or application reaches a defined stage. It reduces rekeying while keeping iCIMS as the source for recruiting-specific data.
Integration direction
Example Mapping
| iCIMS Field | Canonical Field | Target Field |
|---|---|---|
| Person.id | sourcePersonId | Worker or candidate reference |
| Person.email | emailAddress | Workday email |
| Application.status | applicationStatus | Recruiting stage |
| Job.id | sourceJobId | Job requisition reference |
Martini implementation pattern
Martini consumes People and Applications through REST APIs or supported callbacks, enriches applications with Job data, filters by configured hiring stages, maps tenant-specific fields, and performs idempotent Workday updates. Failed validations go to an exception path, while transient API failures are retried and processed records are reconciled.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- scheduled synchronization
Pattern 2: Create onboarding work in ServiceNow
When to use this pattern
Use this pattern when a Person or Application status change should create onboarding tasks, access requests, or HR cases in ServiceNow.
Integration direction
Example Mapping
| iCIMS Field | Canonical Field | Target Field |
|---|---|---|
| Person.id | sourcePersonId | Subject identifier |
| Person.name | personName | Requested for |
| Application.status | hiringStage | Case trigger |
| Job.title | jobTitle | Onboarding request summary |
Martini implementation pattern
Martini receives a supported iCIMS notification or performs incremental polling, retrieves the current Person, Application, and Job objects, evaluates the hiring-stage rule, and creates or updates ServiceNow records. Correlation identifiers and deterministic matching prevent duplicate cases; failed downstream calls are retried or routed to exception handling.
Martini capabilities used
- event-driven workflows
- API consumption
- data mapping
- conditional routing
- idempotency
- error handling
Pattern 3: Transfer candidate documents to DocuSign
When to use this pattern
Use this pattern when candidate or application documents must be prepared for signature or routed into a document lifecycle. Document resources and signature flows must be enabled and confirmed for the relevant tenants.
Integration direction
Example Mapping
| iCIMS Field | Canonical Field | Target Field |
|---|---|---|
| Person.id | candidateId | Recipient reference |
| Job.title | positionTitle | Envelope metadata |
| Document.fileName | documentName | Document name |
| Document.id | sourceDocumentId | External reference |
Martini implementation pattern
Martini retrieves permitted iCIMS documents and metadata, validates content and size, builds the DocuSign request, and records source and target identifiers. The workflow can process signature status updates where supported and uses idempotent document references to avoid duplicate envelopes.
Martini capabilities used
- workflows
- file handling
- data mapping
- business rules
- API consumption
- retry handling
Pattern 4: Run incremental recruiting reconciliation
When to use this pattern
Use this pattern when event notifications do not cover all required objects or when the enterprise needs a dependable periodic comparison of People, Jobs, Applications, or documents.
Integration direction
Example Mapping
| iCIMS Field | Canonical Field | Target Field |
|---|---|---|
| Person.modifiedDate | lastChangedAt | checkpoint timestamp |
| Application.id | sourceApplicationId | application key |
| Application.status | sourceStatus | normalized status |
| Job.id | sourceJobId | job key |
Martini implementation pattern
A scheduled Martini workflow loads a persisted checkpoint, retrieves filtered and paginated iCIMS resources with a lookback window, transforms and upserts results, and advances the checkpoint only after successful processing. Throttling, transient retries, dead-letter or exception handling, and reconciliation reports make replay safe and visible.
Martini capabilities used
- scheduler triggers
- API consumption
- pagination orchestration
- data mapping
- checkpointing
- monitoring
- error handling
Applications commonly integrated with iCIMS
iCIMS recruiting data can be integrated with adjacent HR, workflow, document, recruiting, and screening applications. The exact direction and object mapping depend on the licensed modules, tenant configuration, and APIs available from each application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Workday | Transfer candidate, application, or hire information into downstream worker and recruiting processes while reducing rekeying. | iCIMS → Martini → Workday | Martini consumes iCIMS People and Applications through REST APIs, maps identifiers and status values to the Workday model, applies hiring-stage rules, and performs controlled upserts with retry and reconciliation handling. |
| Salesforce | Make recruiting activity, job information, and application context available to recruiting, staffing, or talent teams using Salesforce. | iCIMS → Martini → Salesforce | A Martini workflow retrieves iCIMS Jobs, People, and Applications, normalizes tenant-specific fields, applies duplicate matching rules, and writes selected objects to Salesforce while recording source identifiers. |
| ServiceNow | Create onboarding tasks, access requests, HR cases, or service requests when an application or person reaches a defined hiring stage. | iCIMS → Martini → ServiceNow | Martini receives an iCIMS callback where available or polls incrementally, evaluates status rules, creates ServiceNow records, and returns or stores task identifiers for later reconciliation. |
| DocuSign | Prepare and route offer or employment documents using candidate and job information, then synchronize signature status where supported. | iCIMS → Martini → DocuSign | Martini retrieves permitted iCIMS documents and metadata, transforms them into the DocuSign request model, tracks document identifiers, and processes status updates through the applicable APIs. |
| Indeed | Publish open positions and receive applicant or source-attribution information when the applicable iCIMS and Indeed capabilities are enabled. | Indeed → Martini → iCIMS | Martini can normalize job or applicant payloads between the applicable endpoints, validate source identifiers, and apply idempotent upserts; current job-board and Indeed support must be confirmed. |
| Sterling | Initiate background checks when a candidate reaches a configured stage and synchronize screening outcomes with recruiting workflows. | iCIMS → Martini → Sterling | Martini evaluates iCIMS Application or Person status, submits the permitted screening request to Sterling, stores correlation identifiers, and applies returned outcomes to the appropriate iCIMS process where supported. |
How to build a iCIMS integration in Martini
Objective
Establish the tenant-approved iCIMS API connection and keep credentials isolated from workflow mappings and logs.
Instructions in Martini
- Confirm the applicable iCIMS API product, tenant permissions, OAuth grant, scopes, and token endpoint
- Store client identifiers, secrets, and tokens in secured environment configuration
- Configure authentication and token refresh or reauthorization behavior
- Restrict access to recruiting data to the minimum required resources
Objective
Select an event-driven or scheduled entry point based on the coverage and reliability of the required iCIMS events.
Instructions in Martini
- Use a supported iCIMS callback for selected events after confirming payload and security behavior
- Use a scheduler for incremental polling when event coverage is incomplete
- Define a checkpoint, lookback interval, and controlled concurrency
- Capture correlation identifiers at the start of each execution
Objective
Retrieve the current iCIMS resources required for the business process rather than relying on incomplete callback payloads.
Instructions in Martini
- Call the relevant REST endpoints for People, Jobs, Applications, Companies, Locations, or documents
- Implement documented pagination and filtering
- Retrieve the current object after a callback when the notification contains only an identifier
- Apply throttling and transient retry handling
Objective
Coordinate retrieval, enrichment, validation, routing, target writes, and outcome recording in one maintainable integration flow.
Instructions in Martini
- Enrich Applications with related People and Job data when required
- Branch by application status, job status, document type, or target destination
- Separate event receipt from downstream processing when asynchronous handling is appropriate
- Persist source identifiers and processing outcomes
Objective
Convert tenant-specific iCIMS payloads into a canonical or target-specific model without losing required source references.
Instructions in Martini
- Map stable iCIMS identifiers and documented codes
- Normalize names, locations, dates, statuses, and document metadata
- Validate required fields and preserve selected unknown fields where audit needs require it
- Use custom JVM-compatible logic only when standard mapping is insufficient
Objective
Ensure only the correct recruiting events, records, fields, and documents are transferred to downstream systems.
Instructions in Martini
- Filter by supported modification timestamps, statuses, or hiring stages
- Minimize personally identifiable and sensitive employment data
- Apply deterministic matching and idempotency rules
- Route validation failures to an operational exception path
Common iCIMS data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Person | Synchronize candidate, employee, or other individual profiles and identifiers. | Workday, Salesforce, ServiceNow, screening platforms | Martini retrieves permitted fields, maps tenant-specific attributes, applies privacy and validation rules, and performs idempotent upserts. |
| Job | Share requisitions, job details, locations, and publishing information. | Salesforce, Indeed, reporting platforms, HR systems | Martini retrieves Jobs incrementally, normalizes statuses and locations, and routes approved fields to downstream APIs. |
| Application | Transfer a person’s application, stage, status, and relationship to a Job. | Workday, ServiceNow, Sterling, Salesforce | Martini uses Application identifiers and status rules to trigger workflows, submit screening requests, and reconcile downstream outcomes. |
| Company | Associate recruiting activity with an organization or employer-related object. | Salesforce, Workday, reporting stores | Martini maps stable identifiers and organization attributes, preserving source references for matching and updates. |
| Location | Represent physical or organizational locations associated with jobs and recruiting activity. | Workday, Salesforce, reporting platforms | Martini normalizes location values and applies reference-data mapping before writing target records. |
| User | Represent an iCIMS platform user who administers or operates recruiting processes. | Identity, audit, workflow, and reporting systems | Martini transfers only required user attributes, applies access and privacy rules, and records source identifiers. |
Authentication and security considerations
OAuth and tenant permissions
iCIMS integrations should use the OAuth 2.0 configuration enabled for the tenant and applicable API product. Confirm the grant type, scopes, token endpoint, client credentials, and resource-level permissions with the iCIMS administrator.
Protect recruiting data
- Store client secrets and tokens in secured Martini environment configuration or secrets management.
- Minimize copied candidate and employee data and restrict access by workflow and target.
- Do not place credentials, resumes, application answers, or sensitive personal data in logs.
- Secure callback endpoints using the validation, token, signature, or source restrictions supported by the applicable iCIMS service.
Operational considerations for iCIMS integrations
Rate limits and pagination
Confirm tenant-specific quotas, page sizes, filters, sorting, concurrency, and throttling behavior. Use controlled concurrency, exponential backoff, and any applicable Retry-After response.
Incremental synchronization
Prefer supported modification filters or event notifications. Persist checkpoints outside individual executions and use a lookback interval to account for timestamp precision and eventual consistency.
Idempotency and reconciliation
Use stable iCIMS identifiers for People, Jobs, Applications, Companies, Locations, and documents. Treat callbacks as potentially duplicated, perform deterministic upserts, and schedule reconciliation workflows.
Schema and documents
Tenant-specific fields, statuses, workflows, forms, document permissions, content types, and size limits must be confirmed. Version mappings, validate required values, and preserve document metadata and source identifiers.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates iCIMS API calls, callbacks, downstream writes, validation, enrichment, and reconciliation in reusable workflows instead of distributing logic across scripts.
Maintainable transformations
Mappings and business rules can normalize tenant-specific People, Jobs, Applications, and document data while keeping source identifiers and audit context.
Reliable operations
Standardized authentication, checkpoints, throttling, retries, error paths, logging, and monitoring provide a more controlled operating model than point-to-point code.
Controlled API access
Martini can expose a REST façade that shields downstream applications from iCIMS-specific payloads and provides a consistent enterprise interface.
Frequently asked questions
iCIMS is primarily integrated through its REST APIs for People, Jobs, Applications, Companies, Locations, and other tenant-enabled resources. Selected iCIMS services also provide event-notification or callback capabilities, while document resources may support candidate files and attachments. OAuth 2.0 is the expected authentication approach, subject to tenant and API-product configuration.
Yes. Martini can consume iCIMS REST APIs, receive supported iCIMS callbacks or event notifications, run scheduled and paginated synchronization workflows, transfer permitted documents, and expose REST APIs that normalize iCIMS data for downstream applications.
No dedicated iCIMS connector is required. Martini can integrate using iCIMS's confirmed native mechanisms, including REST APIs, selected event notifications or callbacks, supported document resources, OAuth authentication, and scheduled API retrieval.
Lonti does not charge an additional per-connector or per-vendor fee to integrate iCIMS. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from iCIMS, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.
REST APIs are the primary recommended method. Use selected iCIMS event notifications when the required event and delivery model are confirmed, and use scheduled incremental API synchronization when events are unavailable or incomplete. Dedicated bulk or asynchronous APIs and SOAP capabilities should not be assumed without confirmation.
Potentially. iCIMS supports event-notification or callback-style integration for selected events and services, but coverage is not universal. The event types, payload completeness, delivery security, and retry behavior must be confirmed; scheduled incremental polling is the fallback for unsupported events.
Martini retrieves iCIMS resources through REST calls, handles pagination and checkpoints, maps tenant-specific fields into canonical or target models, applies validation and business rules, and writes idempotent updates to downstream APIs, databases, files, or messaging endpoints supported by the design.
A Martini integration can distinguish authentication, authorization, validation, throttling, transient, and downstream failures. It can retry transient failures with controlled backoff, persist event and source identifiers, use idempotent upserts, and route non-retryable errors to an operational exception or reconciliation workflow.
Related Martini documentation
Data Processing
Operations
Integrate iCIMS with Martini
Use Martini to connect iCIMS recruiting data with enterprise applications through secure API consumption, event-driven workflows, scheduled synchronization, transformation, and controlled API exposure.