.png)
Phenom Integration Guide
Connect Phenom talent experience data with enterprise systems through tenant-specific APIs, conditional callbacks, scheduled workflows, and controlled data exchange.
Phenom integration options at a glance
Phenom integrations depend on the products licensed, tenant configuration, geography, and implementation contract. A public, complete Phenom API reference was not confirmed, so customers should obtain the supported endpoint catalog, authentication model, pagination rules, and permissions from Phenom. Where a documented REST API is provided, Martini can consume it in workflows to retrieve or update Jobs, Candidates, Applications, Talent profiles, Employees, or Events. If selected outbound callbacks are available, Martini can expose a receiving API. Scheduled synchronization is the fallback when callbacks are unavailable. Customer-specific file exchange may also be possible, but it requires explicit confirmation from Phenom.
| Integration point | Supported by Phenom? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Not confirmed | If supplied for the customer tenant, REST APIs could retrieve or update Jobs, Candidates, Applications, Talent profiles, Employees, and Events. Endpoint coverage, write permissions, pagination, and rate limits require confirmation. | Martini can consume documented REST endpoints from workflows, manage request configuration and secrets, transform responses, and send mapped results to downstream systems. |
| Webhooks / outbound callbacks | Not confirmed | Selected Phenom events may be capable of notifying external systems, but broad coverage across Jobs, Candidates, Applications, or Profiles was not confirmed. | Martini can expose a receiving API or webhook workflow, validate incoming requests, retrieve the authoritative object, and process duplicates or retries when delivery behavior is documented. |
| Scheduled synchronization | Yes | Scheduled polling is a practical fallback when callbacks are unavailable, using documented incremental filters, pagination, or synchronization checkpoints if Phenom provides them. | Martini can run scheduled workflows, persist cursors or last-successful timestamps, process pages, and apply retry and checkpoint logic. |
| Bulk / asynchronous / batch APIs | Not confirmed | No public bulk export, asynchronous job, or batch API specification was confirmed. Large transfers should not assume a bulk mechanism. | Martini can orchestrate documented batch mechanisms if Phenom supplies them; otherwise it can process paginated API responses in controlled workflow batches. |
| File / attachment APIs | Not confirmed | Customer-specific file exchange may support recruiting or HR processes, but public technical specifications for Phenom file endpoints were not confirmed. | Martini can process explicitly documented files, transform supported formats, and route them through workflows, but the Phenom-side exchange must be confirmed first. |
| Authentication | Not confirmed | The Phenom system-to-system authentication model was not confirmed. Possible tenant-specific approaches include OAuth 2.0, API keys, bearer tokens, or other credentials, but none should be assumed. | Martini can store confirmed credentials and tokens in secrets management and apply the documented authentication configuration to API workflows. |
| GraphQL APIs | Not confirmed | No official public Phenom GraphQL documentation was confirmed, so GraphQL should not be assumed for Phenom integration. | Martini can consume GraphQL where a customer-provided Phenom endpoint is documented, but availability and schema must be verified independently. |
| SOAP APIs | Not confirmed | No official public Phenom SOAP documentation was confirmed, so SOAP should not be selected without customer-specific evidence. | Martini can consume SOAP services when Phenom provides a supported service contract and authentication details. |
How Phenom exposes data and business events
Phenom REST APIs
Phenom may provide tenant-specific REST APIs for customer and partner integrations, but a public complete developer reference was not confirmed. The available resources, operations, authentication, pagination, and write permissions must be obtained from Phenom.
Martini implementation pattern
Martini implementation pattern: Martini consumes the documented Phenom endpoint from a workflow, authenticates with tenant-provided credentials stored as secrets, retrieves pages or incremental changes, maps the response into a canonical model, and writes to the target application. The workflow records checkpoints and distinguishes authorization, validation, throttling, and transient failures.
Implementation sequence
Phenom outbound callbacks
A public reference for tenant-configurable Phenom webhooks or outbound callbacks was not confirmed. If the customer tenant supports callbacks for selected events, coverage, signatures, retry behavior, ordering, and delivery guarantees must be verified.
Martini implementation pattern
Martini implementation pattern: Martini exposes a controlled receiving API or webhook workflow. It validates the request according to Phenom’s confirmed security model, records a correlation identifier, retrieves the authoritative object when the notification is incomplete, and applies idempotent downstream processing. Scheduled polling remains the fallback when callbacks are unavailable.
Implementation sequence
Scheduled Phenom synchronization
Scheduled synchronization is a practical integration pattern when Phenom does not provide usable callbacks. Its effectiveness depends on documented collection endpoints, updated-at filters, cursors, continuation tokens, or other tenant-specific change detection mechanisms.
Martini implementation pattern
Martini implementation pattern: A scheduler starts a workflow that reads persisted synchronization state, retrieves changed pages from Phenom when supported, maps each object, and writes idempotently to target systems. Martini stores the checkpoint only after successful processing and applies controlled retry and throttling behavior.
Implementation sequence
Phenom file exchange
Customer-specific file exchange may be used in some recruiting or HR implementations, but a public Phenom file import or export specification was not confirmed. File processing should be designed only after the tenant’s supported format and transfer method are documented.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves an explicitly supported file, validates its structure and provenance, parses the contents, maps rows or documents to Phenom or downstream objects, and records rejected items separately. The workflow should not assume that Phenom-managed files or attachments are directly accessible.
Implementation sequence
Common Phenom integration patterns
Pattern 1: Sync Phenom Jobs to an HR platform
When to use this pattern
Use this pattern when Phenom is the talent-experience source for published job opportunities and an HR platform must maintain aligned requisition or posting data. The exact Phenom API and incremental filtering capability must be confirmed first.
Integration direction
Example Mapping
| Phenom Field | Canonical Field | Target Field |
|---|---|---|
| jobId | externalJobId | External Job ID |
| title | jobTitle | Job Title |
| location | workLocation | Primary Location |
| status | jobStatus | Requisition Status |
Martini implementation pattern
A scheduled Martini workflow retrieves changed Jobs, processes documented pages, normalizes status and location values, and performs an idempotent upsert using the Phenom identifier. Validation failures are isolated, transient errors are retried with backoff, and the synchronization checkpoint advances only after successful processing.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Synchronize Candidates and Applications
When to use this pattern
Use this pattern when recruiting teams need Phenom candidate engagement or application information available in a recruiting or HR platform. Candidate and application fields should be limited to approved, consented data.
Integration direction
Example Mapping
| Phenom Field | Canonical Field | Target Field |
|---|---|---|
| candidateId | candidateExternalId | Candidate ID |
| contactEmail | ||
| applicationId | applicationExternalId | Application ID |
| status | applicationStatus | Application Status |
Martini implementation pattern
Martini retrieves Candidates and Applications through confirmed endpoints or receives a supported notification, correlates applications with Jobs and Candidates, applies consent and field-level access rules, and upserts the target records. Duplicate detection, rejected updates, and rate-limit responses are handled independently from permanent validation failures.
Martini capabilities used
- workflows
- API consumption
- data mapping
- privacy-aware business rules
- idempotency
- retry handling
Pattern 3: Exchange Employees and talent profiles
When to use this pattern
Use this pattern for internal mobility or employee-experience scenarios where permitted worker information must be exchanged between Phenom and an HR platform. Available fields and write permissions vary by Phenom module and tenant configuration.
Integration direction
Example Mapping
| Phenom Field | Canonical Field | Target Field |
|---|---|---|
| workerId | employeeExternalId | Employee ID |
| jobProfile | roleProfile | Talent Profile |
| skills | normalizedSkills | Skills |
| employmentStatus | employeeStatus | Employment Status |
Martini implementation pattern
Martini retrieves changed employee data from the source system, maps only authorized attributes, normalizes skills and status values, validates required fields, and submits permitted updates to Phenom. Incomplete or unauthorized records are placed into an operational review path rather than retried indefinitely.
Martini capabilities used
- workflows
- API orchestration
- data transformation
- validation
- business rules
- operational error handling
Pattern 4: Process conditional Phenom event notifications
When to use this pattern
Use this pattern only when the customer tenant confirms outbound callbacks for the required Phenom events. It supports near-real-time routing while retaining scheduled polling as a fallback.
Integration direction
Example Mapping
| Phenom Field | Canonical Field | Target Field |
|---|---|---|
| eventType | notificationType | Task Type |
| eventId | sourceEventId | Correlation ID |
| candidateId | subjectExternalId | Subject Reference |
| status | workflowStatus | Task State |
Martini implementation pattern
Phenom sends a confirmed callback to a protected Martini API. Martini validates the request, checks idempotency, retrieves the authoritative object when necessary, applies routing and privacy rules, and creates or updates the downstream task. Duplicate delivery and temporary downstream failures are handled without losing the source event.
Martini capabilities used
- API exposure
- webhook consumption
- workflows
- data mapping
- business rules
- idempotency
- error handling
Applications commonly integrated with Phenom
Phenom commonly participates in enterprise recruiting, HR, talent relationship, and employee-experience landscapes. The applications below represent practical architecture patterns rather than proof of a native Phenom integration; supported objects, directions, and endpoints should be confirmed for each tenant.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Workday | Synchronize worker, job requisition, candidate, or application information between Workday and Phenom talent experience capabilities. | Workday → Martini → Phenom | Martini can schedule source extraction, map permitted HR and recruiting fields, apply validation and consent rules, and perform controlled upserts in Phenom where tenant permissions allow. A reciprocal workflow can return recruiting or engagement updates to Workday. |
| SAP SuccessFactors | Align recruiting, employee, and job data across SAP SuccessFactors and Phenom. | SAP SuccessFactors → Martini → Phenom | Use separate workflows for employee and recruiting domains, preserve source identifiers, transform status and location values, and route rejected updates for review. Exact APIs and write permissions require confirmation from both systems. |
| Oracle HCM Cloud | Exchange job, candidate, application, and employee information across the HR suite and Phenom. | Oracle HCM Cloud → Martini → Phenom | Martini can orchestrate scheduled or event-triggered extraction, normalize profile and job data, enforce field-level privacy rules, and retry transient failures without creating duplicate objects. |
| iCIMS | Synchronize recruiting requisitions and candidate or application activity with Phenom engagement experiences. | iCIMS → Martini → Phenom | A Martini workflow can retrieve changed requisitions or applications, map recruiting identifiers and statuses, apply upsert logic, and record tenant-specific validation or permission failures. |
| Greenhouse | Connect recruiting workflows with Phenom career-site, candidate-engagement, or talent-community capabilities. | Greenhouse → Martini → Phenom | Martini can coordinate scheduled polling or supported callbacks, transform candidate and job fields, minimize sensitive data, and route updates according to consent and downstream ownership rules. |
| UKG Pro | Exchange employee and recruiting-related information with Phenom. | UKG Pro → Martini → Phenom | Use a controlled workflow to retrieve changed employee or recruiting data, validate required fields, map module-specific attributes, and persist synchronization state for safe reruns. |
| Salesforce | Synchronize talent relationship or engagement information where Salesforce is used as an enterprise customer-data platform. | Phenom → Martini → Salesforce | Martini can consume confirmed Phenom data endpoints, apply consent and deduplication rules, map talent profiles to Salesforce objects, and expose status or error outcomes through an API. |
| ServiceNow | Route recruiting or employee-experience requests and operational tasks between Phenom and ServiceNow. | Phenom → Martini → ServiceNow | Martini can receive confirmed Phenom notifications or poll for changes, create or update ServiceNow tasks, map priority and ownership values, and return status updates when supported. |
How to build a Phenom integration in Martini
Objective
Establish the tenant-specific Phenom connection only after Phenom confirms the API base URL, authentication method, scopes, permissions, and network requirements.
Instructions in Martini
- Obtain the customer-specific Phenom integration documentation
- Store credentials and tokens in Martini secrets management
- Configure the confirmed endpoint and authentication requirements
- Test access with a non-production or least-privilege account
Objective
Select scheduled polling or a conditional inbound callback based on the mechanisms Phenom confirms for the required objects and events.
Instructions in Martini
- Use a scheduler when polling or incremental retrieval is available
- Expose a Martini API only when Phenom supports callbacks for the required events
- Define the synchronization frequency and overlap strategy
- Document the fallback approach if callbacks are unavailable
Objective
Retrieve authoritative Phenom objects using documented pagination, filters, cursors, or callback follow-up requests.
Instructions in Martini
- Read Jobs, Candidates, Applications, Talent profiles, Employees, or Events as permitted
- Process pages or continuation tokens without assuming a specific pagination model
- Persist a cursor or last-successful timestamp when supported
- Capture correlation identifiers without logging unnecessary personal data
Objective
Build the Martini workflow to coordinate retrieval, validation, transformation, target writes, checkpointing, and failure paths.
Instructions in Martini
- Separate transient failures from validation and permission failures
- Apply bounded retries and backoff for throttling or temporary outages
- Route rejected records to an operational review path
- Advance synchronization state only after successful processing
Objective
Convert Phenom-specific fields into a canonical model and target application structure while respecting product and tenant variation.
Instructions in Martini
- Map stable Phenom identifiers to external keys
- Normalize statuses, locations, skills, and employment attributes where required
- Minimize candidate and employee fields to the approved data set
- Validate required fields before downstream writes
Objective
Enforce consent, privacy, ownership, deduplication, and business routing rules before creating or updating downstream objects.
Instructions in Martini
- Check consent and field-level authorization requirements
- Use idempotent upsert or pre-existence checks
- Route unsupported or incomplete records for review
- Prevent duplicate processing of callback notifications
Common Phenom data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Jobs | Represent job requisitions and published job opportunities, including descriptions, locations, employment attributes, and status. | Workday, SAP SuccessFactors, Oracle HCM Cloud, iCIMS, Greenhouse | Martini retrieves or receives confirmed job changes, maps identifiers and status values, applies validation, and performs idempotent creates or updates. |
| Candidates | Represent individuals participating in recruiting or hiring processes. | iCIMS, Greenhouse, Workday, Salesforce | Martini applies consent-aware field mapping, minimizes sensitive data, uses stable Phenom identifiers, and routes validation or permission failures for review. |
| Talent profiles | Provide candidate or employee profile information for matching, engagement, and talent discovery. | Workday, SAP SuccessFactors, UKG Pro, Salesforce | Martini maps only permitted attributes, normalizes profile values, and separates profile synchronization from recruiting transactions where appropriate. |
| Applications | Represent candidate submissions associated with Jobs or requisitions. | Workday, Oracle HCM Cloud, iCIMS, Greenhouse | Martini correlates Applications with Jobs and Candidates, applies status transformation and duplicate protection, and records request identifiers and outcomes. |
| Employees | Represent internal worker profiles used by employee experience and internal mobility capabilities. | Workday, SAP SuccessFactors, Oracle HCM Cloud, UKG Pro | Martini validates employee attributes, enforces field-level privacy rules, and synchronizes only fields authorized by the tenant configuration. |
| Events | Represent recruiting events, campaigns, or engagement activities. | Salesforce, ServiceNow, recruiting platforms | If exposed through a confirmed API or callback, Martini routes Events according to type, retrieves complete objects when necessary, and handles duplicate notifications safely. |
Authentication and security considerations
Tenant-specific authentication
Phenom’s public system-to-system authentication model was not confirmed. Obtain the tenant API base URL, token or credential method, scopes, roles, and network requirements from Phenom or the implementation team.
Secret handling
Store Phenom credentials, tokens, and other sensitive configuration in Martini secrets management rather than embedding them in workflows.
Privacy and access control
- Apply least-privilege permissions and field-level access rules.
- Minimize candidate and employee data transferred to downstream systems.
- Review consent, retention, deletion, residency, and audit requirements.
- Avoid placing unnecessary personal information in logs.
Operational considerations for Phenom integrations
Pagination and checkpoints
Confirm whether Phenom uses page numbers, offsets, cursors, continuation tokens, updated-at filters, or change tokens. Persist synchronization state and avoid relying solely on page numbers during changing data sets.
Rate limits and retries
Public Phenom rate limits were not confirmed. Design for HTTP 429 responses, Retry-After headers, bounded exponential backoff, and controlled concurrency.
Idempotency and duplicates
Use stable Phenom identifiers, upsert or pre-existence checks, callback event identifiers, and retry-safe writes to avoid duplicate Jobs, Candidates, or Applications.
Schema variation
Field availability can vary across Career Site, CRM, Recruiting, Employee Experience, and Talent Marketplace implementations. Validate schemas and permissions per tenant and module.
Testing and observability
Test authentication, pagination, permissions, privacy rules, validation failures, throttling, duplicate delivery, and partial outages. Record correlation identifiers and operational outcomes while protecting personal data.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Phenom integrations often require tenant-specific authentication, pagination, checkpoints, privacy rules, transformations, and coordination with multiple HR or recruiting systems. Martini centralizes this behavior in maintainable workflows.
Reusable integration logic
Martini can expose APIs, consume confirmed Phenom endpoints, receive supported callbacks, apply business rules, and reuse mappings and validation across synchronization processes.
Reliable operations
Workflows can separate transient failures from permanent data errors, apply controlled retries, preserve synchronization state, and provide monitoring and troubleshooting context without coupling every target directly to Phenom.
Frequently asked questions
Phenom can be integrated through tenant-specific APIs, conditional outbound callbacks, scheduled synchronization, and customer-specific file exchange where those mechanisms are provided by Phenom. The exact objects, authentication model, permissions, pagination, and event coverage depend on the licensed products and tenant configuration.
Yes. Martini can integrate with Phenom when Phenom provides documented tenant endpoints, credentials, callbacks, or explicitly supported file mechanisms. Martini can consume confirmed APIs, expose an API for supported callbacks, orchestrate workflows, transform data, and write to downstream systems.
No. A dedicated Phenom connector is not required. Martini can use Phenom’s confirmed native APIs, callbacks, authentication methods, or supported file exchange mechanisms through workflows and APIs. A native Martini Phenom connector was not documented in the supplied materials.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Phenom. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Phenom, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Use a documented Phenom REST API when the tenant provides one with suitable read or write operations. Use confirmed callbacks for selected event-driven scenarios, and scheduled synchronization when callbacks are unavailable. GraphQL, SOAP, bulk APIs, and broad webhook coverage were not publicly confirmed and should not be assumed.
Public documentation confirming tenant-configurable webhooks or outbound callbacks was not found. Some customer implementations may support callbacks for selected events, but event coverage, signatures, retries, ordering, and delivery guarantees must be confirmed with Phenom. Martini can receive supported callbacks through an API workflow.
Martini can run scheduled workflows or process supported callback notifications. The workflow retrieves authoritative Jobs, Candidates, Applications, Talent profiles, Employees, or Events, handles documented pagination or incremental filters, maps data to the target model, and persists synchronization state after successful processing.
Martini can transform Phenom data, apply validation and privacy rules, and use stable Phenom identifiers for idempotent upserts. Workflows can distinguish authentication, permission, validation, throttling, and temporary failures, then apply bounded retries, backoff, duplicate checks, and operational review paths. Martini can also expose an API façade for controlled downstream access to processed data.
Related Martini documentation
Workflows
Plan your Phenom integration with Martini
Confirm the Phenom tenant’s supported APIs, authentication model, callbacks, objects, and data policies, then use Martini to implement a secure, observable integration workflow.