.png)
Pega Platform Integration Guide
Integrate Pega Platform with enterprise systems through REST and DX APIs, SOAP services, selected outbound notifications, and file attachment operations.
Pega Platform integration options at a glance
Pega Platform provides REST APIs, including the Pega DX API, for creating, retrieving, updating, and processing Cases and related resources. It also supports SOAP-based services, selected webhook-style or outbound notifications, and file or Attachment operations. OAuth 2.0 is the preferred authentication approach for secured APIs, while Basic Authentication may be available for specific services. Martini can consume Pega REST APIs, call SOAP services, receive supported notifications through an exposed API, and orchestrate scheduled workflows for incremental synchronization. Application-specific Case Types, data objects, permissions, API versions, and deployment models should be confirmed before mappings are implemented.
| Integration point | Supported by Pega Platform? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs and Pega DX API | Yes | Create, retrieve, update, and process Cases; access Case Types, Assignments, Attachments, status, and application-specific resources. | Martini can consume Pega REST endpoints, manage request and response mappings, expose a normalized API, and orchestrate multi-step workflows. |
| SOAP APIs | Yes | Connect to Pega services or established enterprise integrations that expose WSDL-based operations. | Martini can consume SOAP services, apply XML mappings, handle service faults, and incorporate SOAP calls into workflows. |
| Webhooks and outbound callbacks | Limited | Receive selected Pega event or outbound notifications where the Pega version, application, and configuration support them. | Martini can expose a webhook-facing API or workflow endpoint, validate notifications, apply idempotency, and retrieve authoritative Case state. |
| File and Attachment APIs | Yes | Upload documents to Cases, retrieve Pega Attachments, and transfer files between Pega and storage or document platforms. | Martini can validate metadata and content, orchestrate upload or download operations, map Attachment identifiers, and retry safely. |
| Authentication | Yes | Secure API access with OAuth 2.0 bearer tokens; Basic Authentication may be available for configured or legacy services. | Martini can store credentials and tokens as secrets, configure authenticated API calls, and keep environment-specific values outside workflows. |
| Scheduled synchronization | Yes | Retrieve changed Cases or data objects over controlled intervals when the target Pega API provides suitable filtering and pagination. | Martini can schedule workflows, follow pagination, maintain checkpoints, throttle requests, and reconcile updates. |
| Database and analytics access | Limited | Use Pega-provided reporting, export, or data-access mechanisms where supported; direct database access is not the preferred general integration method. | Martini can connect to approved databases or APIs, but integrations should use documented Pega interfaces to preserve business rules and upgrade safety. |
| Bulk, asynchronous, and batch APIs | Not confirmed | Pega supports asynchronous business processing, but a universal bulk API for all platform objects was not confirmed. | Martini can implement controlled batching, scheduling, checkpointing, and retries only where the specific Pega API documents the required operations. |
How Pega Platform exposes data and business events
Pega Platform REST APIs
Pega Platform and the Pega DX API provide REST-based access to Cases, Case Types, Assignments, Attachments, and application-specific resources. The available paths, fields, permissions, and API versions depend on the deployed Pega application.
Martini implementation pattern
Martini implementation pattern: Martini authenticates with the configured Pega service, calls the relevant REST resource, maps the response into a canonical model, applies business rules, and writes to downstream systems or returns a normalized API response.
Implementation sequence
Pega Platform SOAP services
Pega supports SOAP service exposure and SOAP-based integrations for established WSDL-oriented enterprise use cases. REST is generally preferred for new integrations when an equivalent Pega API is available.
Martini implementation pattern
Martini implementation pattern: Martini consumes the WSDL-based service, constructs the required XML request, handles SOAP faults, transforms the response, and incorporates the operation into a larger workflow.
Implementation sequence
Pega outbound notifications
Pega supports webhook-style or outbound event notifications for selected configurations and use cases, but coverage is not universal across Case events or objects. Availability depends on version, application, event source, and deployment model.
Martini implementation pattern
Martini implementation pattern: Martini exposes a receiving API or workflow endpoint, validates the notification, applies idempotency controls, and retrieves the authoritative Case state from Pega before updating downstream systems.
Implementation sequence
Pega file and Attachment operations
Pega supports file and Attachment operations associated with Cases and other application objects. File limits, permitted content types, scanning, retention, and access permissions are deployment-specific.
Martini implementation pattern
Martini implementation pattern: Martini validates incoming file metadata and content, identifies the target Case, calls the supported Pega upload or retrieval operation, and records the Attachment identifier and transfer result.
Implementation sequence
Pega scheduled synchronization
Scheduled retrieval is suitable for incremental synchronization when a Pega API provides pagination and usable update filters or timestamps. A universal bulk API for all Pega objects was not confirmed.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow retrieves pages of changed Cases or data objects, transforms each result, writes successful changes downstream, and advances a checkpoint only after processing succeeds.
Implementation sequence
Common Pega Platform integration patterns
Pattern 1: Synchronize Pega Cases to a service platform
When to use this pattern
Use this pattern when Pega manages service requests or other Cases while another service platform needs a synchronized view of status, customer context, or work ownership. It supports incremental processing rather than repeatedly loading the full Case population.
Integration direction
Example Mapping
| Pega Platform Field | Canonical Field | Target Field |
|---|---|---|
| Case ID | caseExternalId | Correlation ID |
| Case Type | caseType | Request Type |
| Status | caseStatus | State |
| Customer data | customerReference | Caller or Customer |
Martini implementation pattern
A scheduled Martini workflow calls the Pega REST API, follows pagination, filters by a stable update value, maps Case fields, and creates or updates the target object. It stores Pega and target identifiers, uses overlap windows for late updates, and routes validation or transient failures to retry and reconciliation handling.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- checkpointing
- business rules
- error handling
Pattern 2: Process Pega notifications and retrieve authoritative Case state
When to use this pattern
Use this pattern where the target Pega configuration can emit webhook-style notifications for selected events and downstream systems need timely updates. The notification is treated as a trigger rather than a complete source of truth.
Integration direction
Example Mapping
| Pega Platform Field | Canonical Field | Target Field |
|---|---|---|
| Case ID | caseExternalId | Case Reference |
| Notification event | eventType | Integration Event |
| Case status | caseStatus | Service Status |
| Customer reference | customerReference | Account or Contact |
Martini implementation pattern
Martini receives the notification through an exposed API, authenticates and validates it, checks event idempotency, and retrieves the current Case through the Pega REST API. Business rules determine whether Salesforce should be created or updated; retries are limited to safe operations and uncertain non-idempotent outcomes are reconciled.
Martini capabilities used
- API exposure
- workflow triggers
- API consumption
- idempotency rules
- data mapping
- retry and reconciliation
Pattern 3: Create Pega Cases from a normalized enterprise API
When to use this pattern
Use this pattern when several external applications need to initiate Pega processes without embedding Pega-specific Case Type mappings in each caller. Martini provides a stable contract while Pega remains the process system.
Integration direction
Example Mapping
| Pega Platform Field | Canonical Field | Target Field |
|---|---|---|
| requestType | caseType | Pega Case Type |
| customerId | customerReference | Customer data object |
| description | caseDescription | Case description |
| priority | priority | Case priority |
Martini implementation pattern
A Martini API validates the normalized request, authorizes the caller, resolves the appropriate Case Type, and calls Pega using OAuth 2.0. It maps Pega validation responses into consistent API errors, returns the Pega Case identifier and initial status, and uses correlation data for reconciliation.
Martini capabilities used
- API exposure
- authentication
- data validation
- API consumption
- data mapping
- error handling
Pattern 4: Transfer documents to Pega Attachments
When to use this pattern
Use this pattern when documents received from an upstream application, file source, or storage platform must be attached to a Pega Case or retrieved from Pega for downstream processing.
Integration direction
Example Mapping
| Pega Platform Field | Canonical Field | Target Field |
|---|---|---|
| fileName | documentName | Attachment name |
| contentType | mimeType | Attachment content type |
| sourceCaseId | caseExternalId | Pega Case ID |
| fileContent | documentContent | Attachment content |
Martini implementation pattern
Martini validates file size, MIME type, metadata, and business ownership before identifying the target Case and invoking the Pega Attachment operation. It records the Attachment identifier, prevents duplicate transfers, and distinguishes upload failures from cases where Pega accepted the file but the response was lost.
Martini capabilities used
- workflow orchestration
- file handling
- data validation
- API consumption
- idempotency
- error handling
Applications commonly integrated with Pega Platform
Pega Platform commonly participates in enterprise workflow and case-management architectures. The following products can be integrated with Pega through their APIs and Pega’s configured REST, SOAP, or application-specific services; exact ownership and direction depend on the deployed Case Types and business process.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer, account, contact, and service information with Pega Cases and customer service workflows. | Salesforce → Martini → Pega Platform | Martini consumes Salesforce and Pega APIs, maps shared customer and service identifiers, applies ownership and conflict rules, and coordinates bidirectional updates with retries and reconciliation. |
| ServiceNow | Coordinate incidents, requests, and operational work with Pega Cases and Assignments. | ServiceNow → Martini → Pega Platform | Martini receives or retrieves ServiceNow work items, maps them to the appropriate Pega Case Type, calls Pega REST APIs, and synchronizes status and identifiers with idempotent workflow processing. |
| SAP S/4HANA | Provide Pega workflows with customer, order, product, billing, or business partner information and send approved transactions back to SAP. | SAP S/4HANA → Martini → Pega Platform | Martini orchestrates SAP and Pega API calls, transforms enterprise master and transaction data, validates Case requirements, and records correlation identifiers for subsequent reconciliation. |
| Oracle ERP Cloud | Exchange financial, supplier, order, and customer information with Pega business processes. | Oracle ERP Cloud → Martini → Pega Platform | A Martini workflow retrieves or receives Oracle data, maps it to Pega data objects and Case fields, applies transaction ownership rules, and handles validation or downstream failures separately. |
| Workday | Use worker and organization data in Pega onboarding, employee-service, and approval workflows. | Workday → Martini → Pega Platform | Martini retrieves Workday data, normalizes worker and organization identifiers, creates or updates Pega Cases, and optionally sends workflow outcomes back after Pega processing. |
| Jira | Create or update Jira issues from Pega Cases or route selected Jira work into Pega-managed processes. | Pega Platform → Martini → Jira | Martini maps Case status, Assignment details, and business identifiers to Jira issue fields, applies routing rules, and prevents duplicate issue creation through stored correlations. |
| Zendesk | Coordinate support tickets, customer interactions, and Pega service Cases. | Zendesk → Martini → Pega Platform | Martini consumes Zendesk and Pega APIs, maps customer and support context, creates or updates Cases according to business rules, and reconciles updates when both systems change. |
| Microsoft Dynamics 365 | Exchange customer, account, opportunity, and service information with Pega customer service workflows. | Microsoft Dynamics 365 → Martini → Pega Platform | Martini orchestrates API calls in either direction, transforms Dynamics and Pega models, validates Case Type requirements, and routes transient failures to controlled retries. |
How to build a Pega Platform integration in Martini
Objective
Establish the Pega endpoint, API version, service package, and authentication configuration for the target deployment.
Instructions in Martini
- Confirm the Pega REST, DX API, SOAP, or notification endpoint
- Configure OAuth 2.0 client credentials where available
- Store credentials, tokens, and URLs in Martini secrets or environment configuration
- Confirm Pega roles, access groups, scopes, and Case permissions
Objective
Select the event-driven or scheduled entry point that matches the synchronization requirement and the capabilities enabled in Pega.
Instructions in Martini
- Use a webhook-facing API only for supported Pega notification scenarios
- Use a scheduler for incremental retrieval and reconciliation
- Define the event, time window, or external API request that starts the workflow
- Document delivery and retry assumptions
Objective
Obtain the authoritative Pega resource while respecting pagination, filtering, and application-specific API contracts.
Instructions in Martini
- Call the relevant Pega REST or DX API resource
- Retrieve the Case after a notification when the payload is incomplete
- Follow documented pagination or continuation controls
- Avoid direct database access unless explicitly approved and documented
Objective
Coordinate Pega calls, target-system calls, transformations, and decision points in a maintainable Martini workflow.
Instructions in Martini
- Separate trigger handling from resource retrieval
- Use reusable workflow logic for common Pega operations
- Apply routing based on Case Type, status, Assignment, or business ownership
- Store Pega and external identifiers for correlation
Objective
Convert Pega Case, Assignment, User, Organization, and Attachment structures into the target application model.
Instructions in Martini
- Map actual fields exposed by the deployed Case Type
- Normalize identifiers, timestamps, status values, and customer references
- Transform JSON or XML payloads as required
- Validate required fields before creating or updating a target object
Objective
Preserve the business behavior of the Pega application and prevent unsafe duplicate or conflicting operations.
Instructions in Martini
- Check Case lifecycle and stage rules
- Apply idempotency using Case IDs, event IDs, or deterministic business keys
- Distinguish create, update, and reconciliation paths
- Respect access-group, user, and service-account permissions
Common Pega Platform data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Cases | Business process instances such as service requests, claims, complaints, or onboarding requests. | CRM, service platforms, data warehouses, ERP systems, and reporting platforms | Martini retrieves or creates Cases through Pega REST or DX APIs, maps Case fields, applies lifecycle rules, and stores external correlation identifiers. |
| Case Types | Definitions of business processes that users or integrations can instantiate. | External intake applications, CRM platforms, portals, and workflow systems | Martini uses the appropriate Case Type as part of request validation and maps normalized input to the fields and starting process supported by the target application. |
| Assignments | Work items assigned to Pega users or groups during Case processing. | ServiceNow, Jira, workforce applications, notifications, and operational dashboards | Martini retrieves or processes Assignment information, applies routing rules, and synchronizes work status where the application API permits. |
| Users | Pega operators or application users who own, process, or receive Assignments. | Identity, HR, service-management, and access-governance systems | Martini maps user identifiers cautiously and respects Pega access groups, roles, and application permissions. |
| Organizations | Business structures used for ownership, routing, and access control. | ERP, HR, identity, CRM, and reporting systems | Martini synchronizes organization references through documented APIs or application services and preserves source-system identifiers. |
| Attachments | Files associated with Cases or other Pega objects. | Document management, cloud storage, email, and downstream processing systems | Martini validates file metadata, transfers content through supported operations, records Attachment identifiers, and prevents duplicate uploads. |
Authentication and security considerations
Authentication
OAuth 2.0 bearer tokens are the preferred pattern for secured Pega APIs and DX API integrations. Basic Authentication may be available for selected service configurations or legacy integrations.
Authorization
Pega access groups, roles, application permissions, service accounts, scopes, and API-specific rules determine which Cases and operations are available.
Martini security
- Store OAuth client credentials, tokens, endpoint URLs, and Basic Authentication values in Martini secrets or environment configuration.
- Use HTTPS for production API traffic.
- Do not place credentials in mappings, request bodies, or source-controlled workflow assets.
- Limit access to Case and Attachment data and avoid logging sensitive payloads.
Operational considerations for Pega Platform integrations
API contracts and pagination
Pega API paths, resources, Case Types, fields, and authentication configuration vary by version, deployment model, application, and DX API version. Confirm the target contract and implement documented pagination rather than assuming a complete result in one request.
Reliability
- Use controlled concurrency and backoff for rate limits, timeouts, and transient 5xx responses.
- Persist checkpoints only after downstream processing succeeds.
- Use Case IDs, event identifiers, and external correlation keys for idempotency.
- Reconcile uncertain outcomes for non-idempotent Case or Attachment operations.
Schema and testing
Customized Case Types, data objects, stages, validations, and access permissions can change integration behavior without changing the endpoint. Maintain versioned mappings and test representative Cases, Attachments, permissions, and failure responses.
Attachments and observability
Define file size, MIME type, scanning, retention, and duplicate-file rules. Capture workflow IDs, Pega correlation identifiers, Case IDs, status codes, retry counts, and timestamps without exposing secrets or unnecessary sensitive Case data.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates Pega API calls, external applications, file operations, business rules, and error paths in workflows rather than scattering logic across scripts or point-to-point integrations.
Stable integration contracts
Martini can expose a normalized API for external callers while keeping Pega Case Type mappings, authentication, and application-specific rules inside the integration layer.
Maintainable data movement
- Map and transform Pega Cases, Assignments, Users, Organizations, and Attachments into target models.
- Reuse workflow logic for authentication, pagination, correlation, retries, and reconciliation.
- Support scheduled, API-led, and selected event-driven patterns.
- Apply consistent monitoring and error handling across Pega and downstream systems.
Frequently asked questions
Pega Platform can be integrated through its REST APIs, including the Pega DX API, SOAP services, selected webhook-style or outbound notifications, and file or Attachment operations. REST is generally preferred for new integrations when the required resource is available. Scheduled workflows can support incremental synchronization using the filtering and pagination capabilities of the specific Pega deployment.
Yes. Martini can consume Pega REST and DX APIs, call Pega SOAP services where required, receive supported Pega webhook-style notifications through an exposed API, and orchestrate file or Attachment transfers. The exact Case Types, resources, authentication configuration, and permissions must be confirmed in the target Pega environment.
No. A dedicated Pega Platform connector is not required. Martini can integrate using Pega’s confirmed native mechanisms, including REST APIs, SOAP services, selected outbound notifications, file operations, and configured authentication methods.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Pega Platform. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Pega, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
Use Pega REST APIs and relevant DX API resources for new integrations when they support the required Case, Assignment, Attachment, or application-specific operation. SOAP remains appropriate for established WSDL-based services. GraphQL was not confirmed as a general-purpose Pega Platform integration method.
Pega supports webhook-style or outbound notifications for selected configurations and use cases, but coverage is not universal. Availability depends on the Pega version, product, event source, application configuration, and deployment model. Martini can receive a supported notification and retrieve the authoritative Case state before processing it.
Martini can run scheduled workflows that retrieve changed Cases or data objects, follow pagination, transform fields, write successful results to a target system, and store checkpoints. The implementation should use stable update information, overlap windows, idempotency controls, and reconciliation for changes that occur during a synchronization run.
Martini can classify authentication, authorization, validation, rate-limit, availability, and downstream errors, then apply workflow error handling and controlled retries. Case and Attachment identifiers, event identifiers, correlation keys, and reconciliation checks help prevent duplicate non-idempotent operations. Uncertain outcomes should be reconciled rather than blindly retried.
Related Martini documentation
APIs
Integrate Pega Platform with Martini
Use Martini to connect Pega Platform APIs, services, notifications, and Attachments with the rest of your enterprise architecture through maintainable workflows and APIs.