Ellipse Gradient for Header

PingOne Integration Guide

Integrate PingOne with enterprise systems through REST APIs, OAuth 2.0, selective webhook notifications, and orchestrated identity workflows.

PingOne integration options at a glance

PingOne provides versioned REST APIs for Users, Groups, Populations, Applications, Environments, roles, policies, and selected audit resources. OAuth 2.0 bearer tokens, client credentials, authorization code with PKCE, scopes, and administrative roles control access. Selected PingOne scenarios support webhook-style notifications, while unsupported event types may require scheduled polling or reconciliation. Bulk directory import and export operations are available for applicable resources. Martini can consume these APIs, expose inbound endpoints, map PingOne JSON, orchestrate provisioning workflows, and apply bounded retries, pagination, deduplication, and environment-specific configuration.

Integration pointSupported by PingOne?Common use casesHow Martini supports it
REST APIsYesManage Users, Groups, Populations, Applications, Environments, roles, policies, tokens, and selected audit resources through versioned Platform APIs.Martini can consume PingOne REST APIs from workflows, map JSON payloads, expose controlled APIs, and orchestrate multi-step provisioning.
Webhooks / outbound callbacksLimitedReceive notifications for selected PingOne event and platform scenarios; coverage is not universal across resources or events.Martini can expose an inbound REST endpoint and trigger a workflow that validates, deduplicates, retrieves authoritative state, and routes the change.
Bulk / async / batch APIsLimitedUse selected bulk user import or export operations for large directory workloads where the applicable endpoint supports the target operation.Martini can invoke bulk endpoints, process results, and fall back to paginated controlled API calls where bulk coverage is unavailable.
File / attachment APIsLimitedFile-oriented operations may support selected bulk directory import or export scenarios; no general-purpose attachment API was confirmed.Martini can process supported file exchanges and transform the results, but should not assume general PingOne attachment handling.
AuthenticationYesAuthenticate API access with OAuth 2.0 bearer tokens using client credentials or authorization code with PKCE, scopes, and administrative permissions.Martini can store credentials and environment identifiers securely, obtain tokens, apply required scopes, and handle expiration without exposing secrets.
SDKsLimitedPing Identity provides developer resources and API documentation, but REST APIs are the primary portable integration surface for Martini.Martini can make standards-based HTTP calls without requiring a PingOne-specific SDK and can encapsulate reusable API logic in workflows or services.
Database accessNoDirect customer database or SQL access is not a standard PingOne integration method.Martini should use PingOne REST APIs and supported audit or notification interfaces rather than attempting direct database access.

How PingOne exposes data and business events

PingOne REST APIs

PingOne's primary integration surface is its versioned Platform REST API. The APIs support directory, application, environment, policy, role, token, and selected audit operations, including searches with filters and pagination.

Martini implementation pattern

Martini implementation pattern: a workflow obtains an OAuth 2.0 token, calls the relevant PingOne endpoint, follows pagination or continuation information, maps the JSON response, applies business rules, and writes the result to a target system or exposes it through a controlled Martini API.

Implementation sequence

Obtain an OAuth 2.0 access token
Call the applicable PingOne REST endpoint
Follow pagination until the bounded read is complete
Map PingOne JSON to the target model
Apply validation and lifecycle rules
Write the result and record the correlation ID

PingOne webhook notifications

PingOne supports webhook-style notifications for selected event and platform scenarios, but notification coverage is selective rather than universal. A notification may identify a change without containing the complete current resource.

Martini implementation pattern

Martini implementation pattern: expose an inbound REST endpoint, validate the request according to the PingOne configuration, deduplicate the notification, retrieve authoritative state from PingOne when required, and route the resulting change to downstream systems.

Implementation sequence

Receive the PingOne notification
Validate the request and notification context
Check the event or resource deduplication key
Retrieve the current PingOne resource when necessary
Apply downstream business rules
Acknowledge or record the processing result

PingOne bulk operations

PingOne provides bulk-oriented directory operations for selected import and export scenarios. Availability and limits depend on the resource and API version, so the applicable operation must be confirmed before implementation.

Martini implementation pattern

Martini implementation pattern: submit or retrieve the supported bulk operation, monitor its result where applicable, validate imported data, and reconcile individual outcomes. If bulk coverage is unavailable, the workflow uses paginated reads and controlled writes.

Implementation sequence

Select the supported bulk operation
Submit or retrieve the bulk payload
Monitor the operation or result status
Validate successful and failed objects
Map results to the target system
Retry eligible failures and report permanent errors

Scheduled PingOne synchronization

Scheduled polling is appropriate for resource changes or event types that are not covered by a configured PingOne notification. It can also provide periodic reconciliation for missed events and partial failures.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a bounded workflow that reads filtered and paginated Users, Groups, Applications, or audit data, compares checkpoints, applies mappings, and records the new checkpoint only after successful processing.

Implementation sequence

Start the scheduled synchronization
Load the last successful checkpoint
Read filtered PingOne collections page by page
Transform and reconcile each object
Write successful changes to the target
Store the checkpoint and report exceptions

Common PingOne integration patterns

Pattern 1: Provision employees to PingOne

When to use this pattern

Use this pattern when Workday or another authoritative HR source controls employee identity lifecycle. It covers creation, updates, group or application assignment, and disablement when an employee leaves.

Integration direction
Workday
Martini
PingOne
Example Mapping
PingOne FieldCanonical FieldTarget Field
workerIdexternalIdentityIdUser.externalId
workEmailemailUser.email
employmentStatuslifecycleStatusUser.enabled
departmentorganizationalGroupGroup membership
Martini implementation pattern

A Martini workflow receives or retrieves worker changes, validates required attributes, resolves the target Population and Groups, searches for an existing User, and performs an idempotent create or update. It disables the User for termination events and routes missing references, validation failures, and authorization errors to separate operational handling.

Martini capabilities used
  • workflows
  • API consumption
  • OAuth 2.0 configuration
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize PingOne identities to enterprise applications

When to use this pattern

Use this pattern when Salesforce, ServiceNow, Jira, or another application requires synchronized Users and Groups. Scheduled reconciliation can supplement selective PingOne notifications.

Integration direction
PingOne
Martini
ServiceNow
Example Mapping
PingOne FieldCanonical FieldTarget Field
User.ididentityIdServiceNow user identifier
User.emailemailServiceNow email
User.enabledactiveServiceNow active
Group.nameaccessGroupServiceNow group or role
Martini implementation pattern

Martini reads filtered and paginated Users and Groups, maps them to the target model, applies group-to-role and deactivation rules, and writes changes to the application. Stable identifiers, checkpoints, reconciliation, and per-object retry handling prevent duplicate or partial synchronization.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination orchestration
  • data mapping
  • business rules
  • retry handling

Pattern 3: Process selected PingOne event notifications

When to use this pattern

Use this pattern when the required PingOne event type supports webhook-style notification. It provides lower-latency processing while retaining a REST lookup for authoritative resource state.

Integration direction
PingOne
Martini
Salesforce
Example Mapping
PingOne FieldCanonical FieldTarget Field
eventIdsourceEventIdintegration event key
resourceIdidentityIdSalesforce user identifier
eventTypechangeTypeprovisioning action
User.enabledactiveSalesforce active
Martini implementation pattern

A Martini API receives the notification, validates and deduplicates it, retrieves the current User, Group, Application, or policy state, and applies downstream rules. The workflow acknowledges safely, retries transient API failures, and sends unsupported or malformed events to an exception path.

Martini capabilities used
  • API exposure
  • webhook triggers
  • workflows
  • API consumption
  • idempotency rules
  • error handling

Pattern 4: Report PingOne audit activity

When to use this pattern

Use this pattern when security, compliance, or operations teams need selected PingOne administrative or audit information in a SIEM, warehouse, or compliance repository.

Integration direction
PingOne
Martini
SIEM
Example Mapping
PingOne FieldCanonical FieldTarget Field
eventTimeoccurredAtevent timestamp
actorinitiatedByactor identity
eventTypeactivityTypeevent category
environment.idsourceEnvironmenttenant identifier
Martini implementation pattern

A scheduled Martini workflow reads time-windowed and paginated audit data, normalizes event fields, masks unnecessary sensitive values, and writes the result to the target repository. Checkpoints, late-arriving event handling, retention awareness, and bounded retries support reliable reporting.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • JSON transformation
  • data mapping
  • privacy rules
  • monitoring

Applications commonly integrated with PingOne

PingOne commonly participates in enterprise identity, access, provisioning, federation, and audit architectures. Martini can coordinate PingOne APIs with the following named applications, while the precise protocol and provisioning model depends on the application edition and customer configuration.

Application Scenario Direction Martini Pattern
Salesforce Provide workforce or customer sign-on, synchronize users and groups, and automate access changes. Salesforce → Martini → PingOne Use REST APIs or inbound lifecycle inputs to normalize identity attributes, resolve PingOne Populations and Groups, and create, update, or disable Users with idempotent matching and retry handling.
ServiceNow Support sign-on, user provisioning, group or role synchronization, and access governance. ServiceNow → Martini → PingOne Orchestrate ServiceNow and PingOne API calls, map users and groups to the required models, apply lifecycle rules, and record correlation identifiers for reconciliation.
Workday Use authoritative worker and employment data to create, update, or disable PingOne Users. Workday → Martini → PingOne Receive or retrieve worker changes, transform employment attributes, resolve target Populations and Groups, and run idempotent provisioning or deprovisioning workflows.
Microsoft Entra ID Coordinate identities, federation, or access between PingOne and Microsoft cloud environments. Microsoft Entra ID → Martini → PingOne Implement the selected federation, provisioning, or REST-based synchronization design with explicit conflict rules, environment configuration, and controlled retries.
Okta Support identity coexistence, migration, directory synchronization, or consolidation projects. Okta → Martini → PingOne Read and normalize identities and groups from both platforms, apply authoritative-source and conflict rules, then synchronize changes through PingOne REST APIs with reconciliation.
Jira Provide sign-on and automate access based on PingOne Groups or application assignments. Jira → Martini → PingOne Map PingOne identity and group changes to Jira's selected integration interface, validate access rules, and handle duplicate notifications or failed assignments.
AWS Federate workforce access to AWS accounts and roles and coordinate identity lifecycle or group-based authorization. AWS → Martini → PingOne Coordinate PingOne identity and group data with AWS access configuration, apply account and role rules, and retain execution and audit context.

How to build a PingOne integration in Martini

Objective

Establish environment-specific access to PingOne using OAuth 2.0 and least-privilege permissions.

Instructions in Martini

  • Configure the PingOne environment ID, API base URL, token URL, client ID, and client secret as protected environment values.
  • Use client credentials for server-to-server administration or authorization code with PKCE for user-facing flows.
  • Request only the scopes required by the workflow and keep development, test, and production credentials separate.

Objective

Select an event, webhook, API, or schedule that matches the required latency and PingOne coverage.

Instructions in Martini

  • Use a webhook-style notification only when the required PingOne event is supported.
  • Use a Martini API endpoint for inbound notifications or external lifecycle requests.
  • Use a scheduler for polling, audit retrieval, bulk processing, or periodic reconciliation.

Objective

Read the authoritative PingOne resource or notification context needed by the integration.

Instructions in Martini

  • Call the relevant PingOne REST endpoint after acquiring a valid bearer token.
  • Implement filters, bounded pagination, and continuation handling for Users, Groups, Applications, or audit resources.
  • Retrieve current resource state after a notification when the notification does not contain a complete representation.

Objective

Coordinate PingOne calls, target-system calls, branching, and operational state in a maintainable workflow.

Instructions in Martini

  • Separate token acquisition, resource retrieval, transformation, target writes, and exception handling into clear workflow stages.
  • Use conditional routing for create, update, disable, missing-reference, and retryable-error paths.
  • Record correlation IDs and checkpoints so executions can be traced and resumed safely.

Objective

Convert PingOne JSON and identity structures into the target application's data model.

Instructions in Martini

  • Map stable identifiers, attributes, enabled state, Populations, Groups, Applications, and role assignments explicitly.
  • Normalize dates, status values, group membership, and optional fields before writing downstream.
  • Preserve required source identifiers for reconciliation and duplicate detection.

Objective

Enforce lifecycle, access, validation, and privacy policies before changes are committed.

Instructions in Martini

  • Validate required identity attributes and references to Populations or Groups.
  • Apply group-to-role, employment-status, deactivation, and least-privilege rules.
  • Classify validation and authorization failures as non-retryable unless the underlying condition changes.

Common PingOne data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
UsersCreate, update, search, enable, disable, and assign directory identities to Groups or Populations.Workday, Salesforce, ServiceNow, Microsoft Entra ID, OktaMartini matches Users by stable external identifiers, paginates searches, maps attributes, applies lifecycle rules, and retries transient failures.
GroupsRepresent membership used for authorization, application assignment, policy evaluation, or administration.Salesforce, ServiceNow, Jira, AWS, OktaMartini resolves group identifiers, maps membership to target roles or groups, and reconciles additions, removals, and duplicate events.
PopulationsSegment Users and related directory operations within a PingOne environment.Workday, Salesforce, ServiceNow, internal identity storesMartini makes Population selection configurable, validates references before provisioning, and treats missing or cross-environment identifiers as non-retryable errors.
ApplicationsDefine OIDC, OAuth, SAML, and other configured applications using PingOne for authentication or authorization.Salesforce, ServiceNow, Jira, AWS, Microsoft Entra IDMartini can retrieve or update supported application configuration through REST workflows while protecting secrets and separating environment settings.
EnvironmentsOrganize PingOne identities, applications, policies, configuration, and administrative resources at tenant level.Configuration repositories, deployment pipelines, audit storesMartini keeps environment IDs, API URLs, credentials, and mappings externalized so development, test, and production remain isolated.
Roles and assignmentsControl administrative access to PingOne administration and APIs.Governance repositories, audit platforms, internal access systemsMartini can synchronize or report selected assignments, enforce least-privilege rules, and restrict administrative workflows by scope.

Authentication and security considerations

OAuth 2.0 and permissions

PingOne APIs generally use OAuth 2.0 bearer tokens. Client credentials suit server-to-server administration, while authorization code with PKCE is appropriate for user-facing application flows. Scopes, PingOne application permissions, and administrative roles should be limited to the workflow's responsibilities.

Protected configuration

Store client IDs, client secrets, token URLs, environment identifiers, and API base URLs in protected Martini environment configuration or secrets management. Keep credentials and resource identifiers isolated across development, test, and production.

Inbound notifications

Protect Martini endpoints used for PingOne notifications and validate requests according to the configured PingOne notification mechanism. Avoid logging tokens, secrets, authentication data, or unnecessary personal attributes.

Operational considerations for PingOne integrations

Pagination and rate limits

PingOne collections may be paginated. Use server-side filters where supported, preserve pagination state, and implement bounded loops. Apply exponential backoff with bounded retries for throttling and suitable transient server failures.

Idempotency and reconciliation

Use stable external identifiers for Users and Groups, check for existing Users before creation, and deduplicate notification processing. Scheduled reconciliation helps correct missed events and partial failures.

Environments and versions

PingOne resources are environment-specific and APIs are versioned. Keep environment IDs and API configuration externalized, pin integrations to the tested API version, and test optional-field or schema changes before deployment.

Monitoring and error handling

Classify token, permission, validation, duplicate, missing-reference, throttling, and service errors as retryable or non-retryable. Record affected objects and correlation IDs, monitor workflow outcomes, and avoid indefinite retries for permanent failures.

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

Orchestration beyond point-to-point calls

Martini coordinates token acquisition, PingOne API calls, target-system writes, conditional routing, checkpoints, and exception handling in maintainable workflows rather than scattering logic across scripts.

Reusable transformation and policy logic

Mappings, lifecycle rules, group-to-role decisions, validation, and reconciliation can be implemented consistently across PingOne integrations and reused for multiple applications.

Operational control

Martini supports API-led, scheduled, bulk, and event-driven designs with bounded retries, idempotency controls, protected configuration, monitoring, and environment-specific deployment settings. This helps teams adapt when PingOne notification coverage or resource schemas differ by use case.

Frequently asked questions

How can PingOne be integrated with enterprise systems?

PingOne can be integrated through its versioned REST APIs, OAuth 2.0 bearer authentication, selected webhook-style notifications, and applicable bulk directory import or export operations. Systems can synchronize Users, Groups, Populations, Applications, roles, and selected audit data through API-led, event-driven, or scheduled workflows.

Can Martini integrate with PingOne?

Yes. Martini can consume PingOne REST APIs, obtain OAuth 2.0 access tokens, expose endpoints for selected PingOne notifications, process JSON, and orchestrate provisioning, synchronization, reconciliation, and audit workflows.

Do I need a connector to integrate PingOne with Martini?

No dedicated PingOne connector is required. Martini can use PingOne's confirmed native integration mechanisms, including REST APIs, OAuth 2.0 authentication, selected webhook-style notifications, and applicable bulk or file-based operations.

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

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

Which PingOne integration methods should be used?

Use the PingOne Platform REST APIs as the primary method for Users, Groups, Populations, Applications, Environments, roles, policies, and selected audit resources. Use OAuth 2.0 for access, selected webhooks for supported event scenarios, bulk operations for applicable large directory workloads, and scheduled synchronization for unsupported or reconciliation use cases.

Are PingOne webhooks or event notifications available?

PingOne supports webhook-style notifications for selected event and platform scenarios, but coverage is not universal. Martini can receive supported notifications through an exposed API and should retrieve authoritative PingOne state, deduplicate events, and use scheduled polling where the required event is not covered.

How does Martini synchronize PingOne data?

Martini can run event-driven, scheduled, bulk, or API-led synchronization workflows. It can paginate through Users and Groups, apply stable-identifier matching, map attributes and group membership, handle enablement or deactivation, checkpoint successful reads, and reconcile missed or partial changes.

Can Martini expose an API façade for PingOne?

Yes. Martini can expose a controlled REST API that hides PingOne endpoint details, applies authentication and authorization policies, validates inputs, orchestrates multiple PingOne calls, and returns a canonical response to internal or external applications.

Related Martini documentation

APIs

Triggers

Workflows

Security

Operations

Connect PingOne with Martini

Use Martini to build secure, maintainable PingOne integrations for identity lifecycle, access synchronization, event processing, and audit reporting.

EXPLORE MARTINI
BOOK A DEMO