Ellipse Gradient for Header

CyberArk Integration Guide

Integrate CyberArk PAM, Privilege Cloud, Identity, and Conjur with enterprise systems through product-specific APIs, authentication models, and scheduled workflows.

CyberArk integration options at a glance

CyberArk's primary enterprise integration surface is its product-specific REST APIs, particularly the CyberArk PAM and Privilege Cloud APIs for Safes, Accounts, Platforms, users, permissions, and audit information. PAM commonly uses session-based authentication, while CyberArk Identity and Conjur use distinct OAuth-oriented or product-specific authentication models. Broad webhook coverage is not confirmed across CyberArk products, so scheduled Martini workflows can poll APIs with pagination, filtering, and persisted checkpoints. Martini can securely authenticate, orchestrate calls, map CyberArk objects, apply business rules, and write normalized results to enterprise applications, databases, or security platforms.

Integration pointSupported by CyberArk?Common use casesHow Martini supports it
REST APIsYesCyberArk PAM and Privilege Cloud REST APIs support authentication, Safe and Account operations, users, platforms, permissions, searches, password-management operations where permitted, and product-specific audit activity.Martini can consume CyberArk REST APIs from workflows, manage request sequencing, transform responses, and expose a controlled API façade for downstream systems.
AuthenticationYesPAM commonly uses a product-specific authentication endpoint and session token. CyberArk Identity and Conjur use separate authentication models, including OAuth 2.0-oriented flows or product-specific tokens.Martini can store credentials, client secrets, API keys, and session tokens in secure environment configuration and can re-authenticate when sessions expire.
Bulk / async / batch APIsLimitedCollection-oriented and product-specific bulk or asynchronous operations may be available, but support and behavior vary by product, endpoint, and deployment version.Martini can process collections with controlled concurrency, pagination, checkpoints, and endpoint-specific handling after the target API contract is confirmed.
Webhooks / outbound callbacksNot confirmedCyberArk event, audit, notification, or integration capabilities vary by product. Universal webhook coverage for Account, Safe, password, user, or policy changes was not confirmed.Martini can receive a supported callback if the selected deployment exposes one; otherwise it can use scheduled REST polling with filtering and persisted checkpoints.
Scheduled synchronizationYesScheduled API polling is a practical approach for account inventories, Safes, audit activity, and other changes when a suitable callback is unavailable or incomplete.Martini scheduler-triggered workflows can retrieve pages, compare timestamps or hashes, upsert target data, and persist synchronization state.
File / attachment APIsNot confirmedNo general-purpose CyberArk file or attachment API was confirmed. CyberArk primarily manages privileged credentials, metadata, policies, and security activity.Martini can process files from other enterprise endpoints when required, but should not assume CyberArk exposes a general file API.
Database / analytics accessNoDirect access to CyberArk Vault storage or internal product databases is not a recommended integration mechanism.Martini should consume supported CyberArk APIs or approved audit and security integrations, then write normalized results to a permitted database or analytics platform.
GraphQL APIsNot confirmedNo CyberArk GraphQL API was confirmed for the products covered by the research.Martini can use REST or another confirmed product-specific endpoint instead of assuming GraphQL availability.

How CyberArk exposes data and business events

CyberArk REST APIs

CyberArk PAM and Privilege Cloud expose REST APIs for authentication, Safes, Accounts, users, platforms, permissions, searches, selected password-management operations, and product-specific audit information. CyberArk Identity and Conjur expose separate product-specific APIs and should not be treated as interchangeable with PAM.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates against the relevant CyberArk product, stores the resulting session or access token securely, calls the required endpoints, handles pagination and authorization responses, maps the result to a canonical model, and writes to the target system or returns an API response.

Implementation sequence

Identify the CyberArk product, edition, version, and API host
Authenticate using the product-specific method
Retrieve the required CyberArk resource or collection
Follow pagination and apply supported filters
Map the response into the target data model
Apply authorization, validation, and business rules5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f

CyberArk authentication

PAM commonly uses a login endpoint that returns a session token for subsequent requests, while CyberArk Identity may use OAuth 2.0-oriented access tokens and Conjur uses its own identity and token model. Exact endpoints, grants, scopes, and permissions depend on the deployment.

Martini implementation pattern

Martini implementation pattern: authentication is isolated in a reusable workflow or service boundary, credentials and tokens are kept in secure environment configuration, and the main workflow re-authenticates only when required by session expiration or token validity.

Implementation sequence

Load product-specific credentials from secure configuration
Call the documented authentication endpoint
Store the session or access token in workflow context
Call only endpoints permitted for the integration identity
Detect expiration or authentication failures
Re-authenticate and retry only the safe failed operation

Scheduled CyberArk synchronization

Broad webhook coverage for CyberArk object changes was not confirmed. Scheduled polling is therefore a practical mechanism for Account, Safe, Platform, identity, and audit synchronization when the selected product does not expose a suitable callback.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that retrieves pages of CyberArk data, uses timestamps, filters, object versions, or hashes where supported, compares the results with persisted checkpoints, and performs idempotent target updates.

Implementation sequence

Start the workflow on a defined schedule
Load the last successful synchronization checkpoint
Retrieve changed CyberArk objects using supported filters
Process all response pages
Compare stable identifiers and change markers
Upsert target objects and record the new checkpoint

Common CyberArk integration patterns

Pattern 1: Automate privileged-access requests

When to use this pattern

Use this pattern when ServiceNow or another request system needs to validate and coordinate access to a CyberArk Safe or Account. The workflow should enforce approval and permission rules before invoking any permitted CyberArk operation.

Integration direction
ServiceNow
Martini
CyberArk
Example Mapping
CyberArk FieldCanonical FieldTarget Field
request.numberrequestIdcorrelationId
requestedUserprincipalIdUser
safeNamesafeIdentifierSafe
accountNameaccountIdentifierAccount
Martini implementation pattern

Martini receives the request through an API or workflow trigger, validates the requested user, Safe, Account, and operation, calls the appropriate CyberArk REST API, and returns the result to ServiceNow. Permission and validation failures are routed for review, while transient failures use bounded retries.

Martini capabilities used
  • workflows
  • API consumption
  • API exposure
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize CyberArk account inventory

When to use this pattern

Use this pattern to populate a CMDB, asset inventory, or governance repository with CyberArk Accounts, Safes, Platforms, and selected ownership or status metadata without retrieving secret values.

Integration direction
CyberArk
Martini
CMDB
Example Mapping
CyberArk FieldCanonical FieldTarget Field
Account.idsourceObjectIdconfigurationItem.externalId
Account.nameaccountNameconfigurationItem.name
Safe.namesafeNameconfigurationItem.vaultContainer
Platform.namemanagementPlatformconfigurationItem.platform
Martini implementation pattern

A scheduled Martini workflow authenticates to the applicable CyberArk API, retrieves paginated collections, applies server-side filters where available, maps objects to the CMDB model, and performs idempotent upserts. Deleted or disabled objects are handled explicitly and checkpoints are committed only after successful processing.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination handling
  • data mapping
  • checkpointing
  • idempotent processing
  • error handling

Pattern 3: Stream CyberArk audit activity to security analytics

When to use this pattern

Use this pattern when CyberArk audit, authentication, account-management, or privileged-session activity must be normalized for Splunk or Microsoft Sentinel. Exact audit endpoints and retention behavior must be confirmed for the selected product.

Integration direction
CyberArk
Martini
Splunk
Example Mapping
CyberArk FieldCanonical FieldTarget Field
eventIdeventIdevent.id
eventTimeoccurredAtevent.time
useractoruser.name
operationactivityTypeevent.action
Martini implementation pattern

Martini polls supported CyberArk audit or activity endpoints, normalizes event fields, adds workflow and correlation metadata, redacts sensitive values, and sends the result through the target platform's ingestion API. Checkpoints, duplicate detection, and bounded retries support reliable delivery.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data transformation
  • redaction rules
  • checkpointing
  • retry handling

Pattern 4: Coordinate CyberArk Identity with an identity provider

When to use this pattern

Use this pattern when CyberArk Identity and Microsoft Entra ID or Okta both participate in user, group, application, or role administration. Define the system of record and conflict rules before enabling bidirectional changes.

Integration direction
CyberArk Identity
Martini
Microsoft Entra ID
Example Mapping
CyberArk FieldCanonical FieldTarget Field
user.ididentityIduser.id
user.userNameloginNameuser.userPrincipalName
group.idgroupIdgroup.id
role.nameroleNamerole.displayName
Martini implementation pattern

Martini retrieves changes from each applicable product API, maps product-specific identity objects to a canonical model, applies ownership and deprovisioning rules, and updates only approved fields. Stable identifiers and relationship tracking prevent duplicate provisioning after retries.

Martini capabilities used
  • API consumption
  • workflows
  • data mapping
  • business rules
  • idempotency
  • error handling

Applications commonly integrated with CyberArk

CyberArk is commonly positioned within privileged-access, security-monitoring, identity, and enterprise workflow architectures. The exact integration direction and supported objects depend on whether the customer uses PAM, Privilege Cloud, CyberArk Identity, or Conjur and on the permissions available to the integration identity.

Application Scenario Direction Martini Pattern
ServiceNow Automate privileged-access requests, approvals, account provisioning, and incident updates using CyberArk account and Safe information. ServiceNow → Martini → CyberArk Martini receives a ServiceNow request, validates the requested user, system, Safe, and permissions, calls the applicable CyberArk REST API, and returns the operation status or approved metadata to ServiceNow. Permission failures and validation errors are routed separately from transient API failures.
Splunk Centralize CyberArk audit and privileged-activity data for security monitoring, investigation, and compliance reporting. CyberArk → Martini → Splunk A scheduled Martini workflow retrieves supported CyberArk audit or activity data, normalizes event fields, removes sensitive values, and submits the result through Splunk's ingestion interface. Checkpoints and retry handling prevent unnecessary replay.
Microsoft Sentinel Send CyberArk authentication, account-management, and privileged-session activity into Microsoft security analytics workflows. CyberArk → Martini → Microsoft Sentinel Martini polls the relevant CyberArk audit or activity API, maps events to the target security schema, enriches them with correlation metadata, and writes them to Microsoft Sentinel using its supported ingestion endpoint.
Microsoft Entra ID Coordinate identity, group, application, and privileged-access administration when CyberArk Identity and Entra ID are both deployed. CyberArk Identity → Martini → Microsoft Entra ID Martini compares users, groups, applications, or role assignments according to the defined system of record, applies allow-list and deprovisioning rules, and performs idempotent updates through the applicable APIs.
Okta Coordinate workforce identity and access lifecycle data with CyberArk Identity or privileged-access processes. CyberArk Identity → Martini → Okta A scheduled or API-led Martini workflow retrieves changes from the selected identity system, maps users and groups to the CyberArk Identity model, applies ownership rules, and records target identifiers for safe retries.
Jira Link privileged-access requests, remediation tasks, or security findings with CyberArk account and policy information. Jira → Martini → CyberArk Martini receives or polls Jira work items, validates the requested CyberArk object and operation, invokes permitted CyberArk APIs, and posts status, identifiers, and review outcomes back to Jira.
Salesforce Support workflows that protect or provision privileged integration accounts used by Salesforce-connected enterprise applications. CyberArk → Martini → Salesforce Martini retrieves only the CyberArk metadata or credential material explicitly required by the use case, applies strict masking and authorization rules, and invokes the relevant Salesforce API without exposing secrets in logs or unrelated payloads.
AWS Reconcile privileged cloud credentials and governance metadata across CyberArk and AWS environments. CyberArk → Martini → AWS Martini coordinates product-specific CyberArk API calls with AWS APIs, maps account and role identifiers, applies ownership and rotation rules, and uses controlled retries for transient service or throttling responses.

How to build a CyberArk integration in Martini

Objective

Establish the product boundary before implementation. PAM, Privilege Cloud, Identity, and Conjur have different API hosts, object models, permissions, and authentication flows.

Instructions in Martini

  • Identify the CyberArk product, edition, version, tenant, and API host
  • Create least-privilege CyberArk credentials or client configuration
  • Store credentials, client secrets, API keys, and tokens in Martini secrets or environment configuration
  • Confirm Safe, Account, audit, identity, or platform permissions required by the workflow

Objective

Select an event-driven or scheduled entry point based on the capabilities confirmed for the customer's CyberArk deployment.

Instructions in Martini

  • Use a Martini API when an upstream application submits a request
  • Use a supported CyberArk callback only when the selected product documents the required event
  • Use a scheduler for polling, inventory synchronization, or audit retrieval when callbacks are unavailable
  • Persist a checkpoint for recurring synchronization

Objective

Call the relevant product-specific CyberArk APIs and retrieve only the fields required for the business process.

Instructions in Martini

  • Authenticate with the documented CyberArk method
  • Retrieve resources such as Safes, Accounts, Platforms, Users, Roles, or audit activity
  • Handle pagination, filtering, session expiration, and authorization responses
  • Avoid retrieving secret values when metadata is sufficient

Objective

Coordinate CyberArk calls with approvals, target-system operations, and conditional business logic in a maintainable Martini workflow.

Instructions in Martini

  • Sequence authentication, validation, CyberArk calls, and target writes
  • Branch permission, validation, not-found, throttling, and service-availability outcomes
  • Use correlation identifiers and preserve source-to-target relationships
  • Keep PAM, Identity, and Conjur configurations separate

Objective

Convert product-specific CyberArk responses into a canonical model for downstream applications, databases, or security platforms.

Instructions in Martini

  • Map stable CyberArk identifiers to target external IDs
  • Normalize timestamps, status values, users, Safe names, and platform metadata
  • Redact secrets and sensitive fields before logging or sending payloads
  • Apply schema validation before target-system writes

Objective

Enforce authorization, ownership, approval, and deprovisioning rules before creating or changing privileged-access data.

Instructions in Martini

  • Validate requested users, Safes, Accounts, Roles, and permitted operations
  • Apply system-of-record rules for identity synchronization
  • Treat password operations as non-idempotent unless CyberArk documents otherwise
  • Route permission and validation failures for review rather than indefinite retries

Common CyberArk data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
SafesLogical containers used to organize and protect privileged Accounts and associated secrets.ServiceNow, CMDBs, governance repositories, Splunk, Microsoft SentinelMartini retrieves Safe metadata through the applicable CyberArk API, applies permission-aware mappings, and performs idempotent target upserts without retrieving secrets unnecessarily.
AccountsPrivileged credentials, secrets, or connection details managed by CyberArk.ServiceNow, CMDBs, AWS, Salesforce, security platformsMartini can synchronize Account metadata or invoke permitted password-management operations. Secret values are requested only when required and are excluded from logs and unrelated payloads.
Account groupsGroups of related Accounts used for organization and management.Governance repositories, CMDBs, identity platformsMartini maps group identifiers and membership relationships, preserves source-to-target keys, and handles additions, removals, and retries deterministically.
PlatformsConfiguration templates defining account management, password changes, verification, and reconciliation behavior.CMDBs, governance repositories, operational reportingMartini synchronizes platform metadata and uses platform identifiers to validate downstream account-management rules.
UsersCyberArk users who may have access to Safes and administrative functions.ServiceNow, Microsoft Entra ID, Okta, governance repositoriesMartini maps users using stable identifiers, applies system-of-record rules, and separates authorization failures from transient API errors.
RolesPermission assignments used in CyberArk Identity and other CyberArk products; the model varies by product.Microsoft Entra ID, Okta, governance repositoriesMartini handles Roles only through the selected product's documented API, with product-specific mappings and explicit authorization checks.

Authentication and security considerations

Product-specific authentication

CyberArk PAM and Privilege Cloud commonly use a login endpoint that returns a session token. CyberArk Identity and Conjur use separate authentication models, including OAuth 2.0-oriented flows, access tokens, API keys, or product-specific tokens where applicable. The exact endpoint, grant, scope, and permission model must match the deployment.

Secret and token protection

  • Store credentials, client secrets, API keys, and session tokens in Martini secrets or secure environment configuration.
  • Do not place authentication responses or CyberArk secret values in workflow definitions, source control, logs, metrics, or error messages.
  • Use least-privilege CyberArk identities with only the Safe, Account, audit, identity, or platform permissions required.
  • Request credential material only when necessary and apply strict access controls to workflows that can retrieve or rotate passwords.

Authorization and auditability

A technically valid API request can fail because of Safe membership, Account access, platform permissions, or product-specific API authorization. Record object IDs, correlation IDs, operation types, status codes, timestamps, and target identifiers without recording secrets.

Operational considerations for CyberArk integrations

Pagination and throttling

Large Safes and Account inventories require pagination and server-side filtering where supported. CyberArk SaaS and cloud APIs may apply tenant-specific limits, so Martini workflows should control concurrency and use backoff for transient 429 and 5xx responses.

Synchronization and idempotency

Persist checkpoints for scheduled polling and use stable CyberArk identifiers with deterministic target keys. Avoid duplicate Accounts, Users, or Groups after retries. Treat password-management operations as non-idempotent unless the selected API explicitly documents idempotency.

Schema and version changes

CyberArk APIs vary across PAM, Privilege Cloud, Identity, Conjur, and product versions. Use product-specific contracts, test against the customer's actual tenant or installation, and account for changes to fields, status values, response formats, and authentication methods.

Testing and monitoring

  • Test authentication, Safe permissions, pagination, session expiration, missing objects, throttling, and target-system failures.
  • Separate permission and validation failures from transient failures so they are not retried indefinitely.
  • Monitor workflow execution results and retain operational correlation data without sensitive credential content.
  • Commit synchronization checkpoints only after the corresponding target writes succeed.

Why use Martini instead of scripts or point-to-point integrations?

Reusable orchestration

Scripts often combine authentication, pagination, mapping, retries, and target writes in code that becomes difficult to govern. Martini workflows make these steps explicit and reusable while supporting custom logic when product-specific behavior requires it.

Controlled API integration

Martini can consume CyberArk REST APIs and expose controlled REST APIs to request systems or downstream applications. This separates CyberArk product contracts from consumers and provides a consistent boundary for authorization, validation, and response handling.

Reliable synchronization

Scheduled workflows can manage checkpoints, idempotent upserts, bounded retries, and error routing for CyberArk inventories and audit activity. This is more maintainable than separate point-to-point scripts for every target system.

Secure operations

Environment configuration, secrets management, redaction, and workflow-level controls help keep CyberArk credentials and returned secret values out of source code, logs, and unrelated integrations.

Frequently asked questions

How can CyberArk be integrated with enterprise systems?

CyberArk can be integrated primarily through its product-specific REST APIs. PAM and Privilege Cloud APIs support authentication, Safes, Accounts, Platforms, users, permissions, selected password-management operations, and product-specific audit data. CyberArk Identity and Conjur use separate APIs and authentication models. Scheduled polling is often appropriate when a required webhook or callback is unavailable.

Can Martini integrate with CyberArk?

Yes. Martini can integrate with CyberArk by consuming the relevant PAM, Privilege Cloud, Identity, or Conjur APIs, securely handling their authentication models, orchestrating workflows, mapping objects, and writing results to enterprise applications or databases. No native Martini CyberArk connector was verified in the supplied information.

Do I need a connector to integrate CyberArk with Martini?

No dedicated CyberArk connector is required. Martini can use CyberArk's confirmed native REST APIs and product-specific authentication methods, with scheduled workflows or supported callbacks where available. The implementation must match the customer's CyberArk product, edition, API version, and authorization model.

Is there any extra Lonti cost to integrate CyberArk with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate CyberArk. The integration is subject to the provisioned capacity of the Martini environment. Separate CyberArk, cloud infrastructure, database, or other third-party costs may apply based on subscriptions, usage, and deployment model.

Which CyberArk APIs and integration methods should be used?

Use the REST API documented for the specific CyberArk product and version. PAM and Privilege Cloud are generally integrated through REST with session-based authentication, while CyberArk Identity and Conjur have distinct API and token models. GraphQL and current SOAP APIs were not confirmed, and direct database access is not recommended.

Can CyberArk changes trigger Martini workflows?

Do not assume universal webhook support for CyberArk changes. Event, audit, notification, and callback capabilities vary by product and deployment. If a suitable callback is documented, Martini can receive it; otherwise, a scheduled workflow can poll APIs using filters, timestamps, object versions, or hashes.

How does Martini synchronize CyberArk data?

Martini can run scheduled workflows that retrieve paginated CyberArk objects, apply supported filters, compare stable identifiers and change markers, map data to a canonical model, and perform idempotent upserts. Checkpoints help avoid repeated processing, while deleted and disabled objects should be handled explicitly.

How does Martini handle CyberArk errors, retries, and sensitive data?

Martini can distinguish authentication, authorization, validation, not-found, throttling, session-expiration, service-availability, and target-system failures. Transient errors can use bounded backoff retries, while permission and validation failures should be routed for review. Credentials, tokens, and returned secrets should be stored securely, redacted from logs, and excluded from unrelated payloads.