.png)
ProcessMaker Integration Guide
Integrate ProcessMaker workflows with enterprise applications through REST APIs, bearer-token authentication, selected event notifications, and file operations.
ProcessMaker integration options at a glance
ProcessMaker’s primary integration mechanism is its REST API, which supports process definitions, requests, tasks, users, groups, and related resources through JSON exchanges. ProcessMaker also supports file and attachment operations subject to deployment version and permissions. Some configurations provide webhook-style notifications or outbound callbacks for selected events, but coverage should be verified before relying on them for every state change. API access uses OAuth 2.0-style bearer tokens with deployment-specific clients, scopes, and permissions. Martini can consume these APIs, receive callbacks through exposed REST APIs, orchestrate workflows, map payloads, transfer files, and use scheduled reconciliation where event coverage is incomplete.
| Integration point | Supported by ProcessMaker? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve processes, requests, tasks, users, groups, and related resources; start requests; update or complete tasks; exchange JSON payloads. | Martini can consume ProcessMaker REST endpoints from workflows, map JSON payloads, apply business rules, and expose normalized APIs for downstream systems. |
| Webhooks and outbound callbacks | Limited | Receive selected process, task, approval, or completion notifications where the deployment and configuration provide the relevant event capability. | Martini can expose a REST API or webhook-triggered workflow, authenticate and validate notifications, retrieve the full resource when necessary, and route the result. |
| File and attachment APIs | Yes | Upload and download documents associated with requests, tasks, forms, or process activity, subject to permissions and deployment-specific endpoints. | Martini can orchestrate binary transfers, preserve metadata, validate content types, detect duplicates, and retry transient failures. |
| Authentication | Yes | Authenticate API calls using OAuth 2.0-style access tokens and bearer-token authorization, with deployment-specific clients, scopes, and permissions. | Martini can store endpoints, client settings, tokens, and secrets in secure environment configuration and send bearer authorization with API requests. |
| Pagination and incremental synchronization | Yes | Retrieve larger collections of processes, requests, tasks, users, or groups without assuming that one response contains all results. | Martini can schedule paginated workflows, maintain checkpoints or timestamps, bound concurrency, and reconcile missed changes. |
| Bulk, asynchronous, and batch APIs | Not confirmed | A general-purpose ProcessMaker bulk API was not confirmed; larger transfers should use pagination, filtering where available, scheduling, and checkpoints. | Martini can implement controlled batch orchestration using REST calls, but endpoint-specific asynchronous behavior must be verified. |
| Database access | Not confirmed | Direct access to ProcessMaker internal application tables was not confirmed and is not recommended as the standard integration method. | Martini should use the documented REST API rather than reading or writing internal ProcessMaker tables directly. |
| GraphQL APIs | Not confirmed | No current official ProcessMaker GraphQL interface was confirmed. | Martini should not assume GraphQL support for ProcessMaker and should use the documented REST API instead. |
How ProcessMaker exposes data and business events
ProcessMaker REST APIs
ProcessMaker’s REST API is the primary documented programmatic interface for processes, requests, tasks, users, groups, and related resources. It supports JSON exchanges, process starts, task operations, status retrieval, and file operations where the deployed API and permissions allow them.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with the configured bearer token, calls the required ProcessMaker endpoint, validates the response, maps ProcessMaker data to a canonical model, and writes the result to the target system. For state-changing operations, Martini stores correlation identifiers and checks for prior completion before retrying.
Implementation sequence
ProcessMaker Webhooks and callbacks
Some ProcessMaker product configurations provide webhook-style or outbound event capabilities for selected events. Coverage may vary by version and configuration, and notifications may contain only an identifier rather than the complete business payload.
Martini implementation pattern
Martini implementation pattern: expose a controlled REST API or webhook-triggered workflow, authenticate and validate the notification, deduplicate it, and retrieve the current ProcessMaker request or task when the event payload is incomplete. Scheduled reconciliation supplements events that are unavailable or missed.
Implementation sequence
ProcessMaker File and attachment APIs
ProcessMaker workflows and requests can contain documents and files. File operations are subject to endpoint availability, object permissions, file-size limits, and deployment version; binary content should not be treated as ordinary JSON.
Martini implementation pattern
Martini implementation pattern: retrieve or receive file metadata, download or upload binary content through the documented API, validate filename, MIME type, and size, and transfer the file to the target application. The workflow records source and target IDs, hashes or duplicate keys, and retry history.
Implementation sequence
Scheduled ProcessMaker synchronization
A general-purpose bulk API was not confirmed. Scheduled, paginated REST synchronization is therefore appropriate for approval monitoring, reconciliation, and larger transfers where event coverage is incomplete.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that reads the last successful checkpoint, requests ProcessMaker pages, filters or compares changes, updates target systems idempotently, and advances the checkpoint only after successful processing. Rate-aware concurrency and backoff protect the ProcessMaker deployment.
Implementation sequence
Common ProcessMaker integration patterns
Pattern 1: Start ProcessMaker requests from enterprise applications
When to use this pattern
Use this pattern when Salesforce, ServiceNow, SAP S/4HANA, Workday, or another source application needs to initiate a controlled approval or business process in ProcessMaker. It provides a normalized API contract while preserving the ProcessMaker request identifier for later status synchronization.
Integration direction
Example Mapping
| ProcessMaker Field | Canonical Field | Target Field |
|---|---|---|
| sourceReference | businessCorrelationId | request correlation field |
| requester | requesterIdentity | request submitter |
| requestData | processInput | process start data |
| approvalType | processRoute | selected process definition |
Martini implementation pattern
Martini exposes or consumes the source application API, validates required fields, applies approval-routing rules, and maps the payload to the ProcessMaker process-start operation. It persists the source and ProcessMaker identifiers before returning a normalized response. If a timeout occurs after submission, the workflow checks the correlation ID before attempting another start.
Martini capabilities used
- APIs
- workflows
- data mapping
- business rules
- secure configuration
- error handling
Pattern 2: Synchronize ProcessMaker approvals to business applications
When to use this pattern
Use this pattern when downstream applications need current request or task status and event coverage is incomplete or unavailable. It is suitable for approval monitoring across Salesforce, ServiceNow, SAP S/4HANA, and Microsoft Dynamics 365.
Integration direction
Example Mapping
| ProcessMaker Field | Canonical Field | Target Field |
|---|---|---|
| requestId | workflowInstanceId | external approval ID |
| status | approvalStatus | approval lifecycle status |
| task.assignee | approver | assigned approver |
| updatedAt | lastChangedAt | source modified timestamp |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated ProcessMaker requests and tasks using a checkpoint, maps ProcessMaker statuses to the target lifecycle, and updates only changed records. It uses correlation IDs and idempotent writes, retries transient failures with backoff, and performs reconciliation after outages.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination
- data mapping
- idempotency
- retry handling
Pattern 3: Process selected ProcessMaker events through a Martini API
When to use this pattern
Use this pattern when the ProcessMaker deployment exposes an outbound callback for a business event such as process submission, task assignment, approval, or completion. Because event coverage is configuration-dependent, scheduled reconciliation should remain available for critical workflows.
Integration direction
Example Mapping
| ProcessMaker Field | Canonical Field | Target Field |
|---|---|---|
| eventId | sourceEventId | integration event key |
| requestId | workflowInstanceId | business record reference |
| eventType | workflowEvent | target event type |
| status | currentState | lifecycle status |
Martini implementation pattern
Martini receives the callback through an exposed REST API, authenticates and validates it, deduplicates the event, and retrieves the current ProcessMaker request or task when necessary. It applies routing rules and publishes or writes the normalized result, while recording failed deliveries for retry and reconciliation.
Martini capabilities used
- REST APIs
- webhook-triggered workflows
- validation
- data mapping
- business rules
- error handling
Pattern 4: Transfer ProcessMaker documents to enterprise repositories
When to use this pattern
Use this pattern when files associated with ProcessMaker requests or tasks must be stored in Microsoft SharePoint, sent to DocuSign, or transferred to another approved records or business system.
Integration direction
Example Mapping
| ProcessMaker Field | Canonical Field | Target Field |
|---|---|---|
| file.name | filename | document name |
| file.mimeType | contentType | MIME type |
| file.content | binaryContent | document content |
| requestId | sourceWorkflowInstanceId | repository correlation ID |
Martini implementation pattern
Martini retrieves file metadata and binary content from ProcessMaker, validates access and size constraints, calculates or checks a duplicate key, and uploads the document to the target API. It preserves request and task correlation, avoids logging content, and retries only safe or verifiably idempotent transfers.
Martini capabilities used
- API consumption
- file handling
- data mapping
- validation
- duplicate detection
- retry handling
Applications commonly integrated with ProcessMaker
ProcessMaker commonly participates in enterprise approval, request, document, and workflow architectures. The following applications represent practical integration targets; the exact direction and API behavior depend on the ProcessMaker deployment and the adjacent application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Route customer, account, opportunity, or sales approvals through ProcessMaker and return decisions or request status to Salesforce. | Salesforce → Martini → ProcessMaker | Martini exposes or consumes the required API, validates the Salesforce payload, starts or updates a ProcessMaker request, stores correlation identifiers, and synchronizes resulting task or approval status back to Salesforce. |
| ServiceNow | Orchestrate approvals and business requests originating in ServiceNow while returning ProcessMaker decisions and completion status. | ServiceNow → Martini → ProcessMaker | A Martini workflow receives ServiceNow events or retrieves records, maps them to a ProcessMaker request, tracks the request and task identifiers, and writes status updates back after approval or completion. |
| SAP S/4HANA | Manage procurement, finance, master-data, and transaction approvals around SAP processes while preserving workflow decisions in ProcessMaker. | SAP S/4HANA → Martini → ProcessMaker | Martini transforms SAP business data into ProcessMaker request inputs, applies routing and validation rules, starts the workflow, and synchronizes approved or rejected outcomes to SAP. |
| Microsoft Dynamics 365 | Coordinate sales, customer-service, finance, or operational approvals associated with Dynamics records. | Microsoft Dynamics 365 → Martini → ProcessMaker | Martini consumes Dynamics API data or notifications, creates or updates ProcessMaker requests, and maps task outcomes and correlation IDs back to Dynamics. |
| Workday | Route employee, HR, or organizational requests through ProcessMaker and synchronize approval status and identifiers. | Workday → Martini → ProcessMaker | Martini receives or retrieves Workday business data, validates required fields, starts the relevant ProcessMaker process, and performs scheduled or event-assisted status reconciliation. |
| DocuSign | Coordinate document-signature workflows and update ProcessMaker requests with signature status or completed documents. | ProcessMaker → Martini → DocuSign | Martini retrieves eligible ProcessMaker request data and files, submits documents to DocuSign, receives or polls signature status, and records the result or completed document against the ProcessMaker request. |
| Slack | Send workflow notifications or approval prompts to operational teams where the workflow design and Slack APIs support the interaction. | ProcessMaker → Martini → Slack | Martini receives selected ProcessMaker events or polls task status, formats controlled notifications for Slack, and routes supported callbacks through validation and correlation logic. |
| Microsoft SharePoint | Store or retrieve documents associated with ProcessMaker requests and approvals. | ProcessMaker → Martini → Microsoft SharePoint | Martini downloads or uploads binary files through the relevant APIs, preserves filename, MIME type, request ID, and checksum metadata, and applies duplicate detection and retry handling. |
How to build a ProcessMaker integration in Martini
Objective
Establish the ProcessMaker API base URL and authentication configuration for each environment without embedding secrets in workflows.
Instructions in Martini
- Configure the ProcessMaker endpoint as environment-specific secure configuration
- Register or configure the ProcessMaker OAuth client and required permissions
- Store client secrets and token settings in Martini secrets management
- Verify bearer-token expiration and refresh behavior
Objective
Select an event-driven, API-led, or scheduled entry point based on the ProcessMaker deployment’s confirmed capabilities.
Instructions in Martini
- Use a Martini REST API or webhook-triggered workflow for supported callbacks
- Use a scheduler for polling, reconciliation, or larger paginated transfers
- Confirm which ProcessMaker events are available before depending on notifications
- Define a correlation ID for every business transaction
Objective
Receive or retrieve the ProcessMaker process, request, task, user, group, or file data required by the integration.
Instructions in Martini
- Call the documented ProcessMaker REST endpoint
- Handle pagination and continuation conditions explicitly
- Retrieve the complete resource when a callback contains only an identifier
- Treat file content as binary and retain required metadata
Objective
Coordinate validation, enrichment, ProcessMaker operations, downstream calls, and recovery behavior in a maintainable Martini workflow.
Instructions in Martini
- Validate required fields and identifiers before state-changing calls
- Apply routing and status-transition business rules
- Sequence ProcessMaker and target-system operations with correlation context
- Separate authentication, validation, transient, and business failures
Objective
Convert ProcessMaker JSON, statuses, identities, and files into stable canonical and target-specific representations.
Instructions in Martini
- Map request and task fields to a canonical model
- Translate ProcessMaker lifecycle states explicitly
- Normalize user, group, filename, and MIME-type values
- Keep ProcessMaker-specific structures isolated from downstream contracts
Objective
Update enterprise applications or repositories with idempotent operations and clear source references.
Instructions in Martini
- Write only validated and authorized data to the target API
- Store ProcessMaker request and task IDs with target identifiers
- Use duplicate keys or business correlation IDs for safe reprocessing
- Record file transfer metadata and outcomes
Common ProcessMaker data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Processes | Published or configured definitions that describe workflow behavior and available process inputs. | Salesforce, ServiceNow, SAP S/4HANA, Workday | Martini retrieves process metadata when needed, selects the appropriate process, and isolates ProcessMaker-specific definitions from canonical models. |
| Requests | Runtime instances representing submitted business requests or cases. | Salesforce, ServiceNow, SAP S/4HANA, Microsoft Dynamics 365 | Martini starts, retrieves, and correlates requests using business IDs and ProcessMaker request IDs, then maps lifecycle status to target systems. |
| Tasks | Work items assigned to users, groups, or workflow participants for approval or execution. | ServiceNow, Salesforce, Slack, Microsoft Dynamics 365 | Martini reads task assignments and statuses, applies routing rules, and updates downstream applications idempotently. |
| Users | ProcessMaker identities that submit, own, approve, or execute work. | Workday, Microsoft Entra-connected applications, ServiceNow | Martini can query users through supported endpoints and map identity attributes while respecting ProcessMaker permissions. |
| Groups | Collections of users used for assignment, routing, and authorization. | Workday, ServiceNow, Salesforce | Martini can retrieve group information for routing or synchronization and apply explicit mapping rules for target groups. |
| Files | Documents or attachments associated with requests, tasks, forms, or process activity. | Microsoft SharePoint, DocuSign, SAP S/4HANA, records repositories | Martini transfers binary content through documented endpoints, preserves metadata, validates MIME type and size, and records transfer status. |
Authentication and security considerations
OAuth-style bearer authentication
ProcessMaker API access uses OAuth 2.0-style access tokens and bearer-token authorization. The exact grant, client configuration, scopes, and token lifetime depend on the deployment.
Least privilege
Use a dedicated ProcessMaker service identity or OAuth client with only the permissions required for the integration. Confirm how roles, users, scopes, and client privileges affect API access.
Secure configuration
- Store client secrets, access tokens, URLs, and token settings in Martini secure configuration.
- Use separate credentials and endpoints for development, testing, and production where possible.
- Do not log bearer tokens, client secrets, confidential form values, or document content.
Operational considerations for ProcessMaker integrations
Pagination and rate limits
Process, request, task, user, and group collections may be paginated. Use bounded concurrency, checkpoints, and backoff for rate limits or transient 5xx responses.
Idempotency and state
Protect process starts, task completions, file uploads, and downstream updates with correlation IDs, request IDs, event IDs, or payload hashes. Map ProcessMaker statuses explicitly rather than relying only on display labels.
Events and reconciliation
Webhook coverage can vary by version and configuration. Pair important events with scheduled reconciliation so missed or malformed notifications do not leave target systems stale.
Schema and deployment changes
Process definitions, forms, task structures, and custom fields can change. Use explicit mappings, validation, versioned contracts where practical, and testing against the relevant ProcessMaker deployment.
Files and observability
Treat attachments as binary content, validate MIME type and size, preserve metadata, and avoid logging document bodies. Log correlation IDs, request IDs, task IDs, HTTP status codes, and retry outcomes.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond point-to-point calls
Martini coordinates ProcessMaker API calls with enterprise applications, files, validation, business rules, and recovery logic in reusable workflows rather than scattering behavior across scripts.
Stable integration contracts
Martini can expose an API façade that hides ProcessMaker-specific endpoints and process structures from consuming applications. This helps maintain a stable enterprise contract as process definitions or API versions evolve.
Operational control
Centralized mappings, secure configuration, checkpoints, idempotency, retry policies, and workflow logging make integrations easier to test, monitor, troubleshoot, and maintain.
Frequently asked questions
ProcessMaker can be integrated primarily through its REST API for processes, requests, tasks, users, groups, and related resources. Selected product configurations may also provide webhook-style notifications or outbound callbacks, while files can be transferred through supported file endpoints. OAuth 2.0-style bearer tokens provide API authentication, and scheduled REST synchronization can cover gaps in event availability.
Yes. Martini can consume the ProcessMaker REST API, authenticate with bearer tokens, start or query requests, monitor tasks, transfer supported files, and expose an API to receive selected ProcessMaker callbacks. Martini can also schedule polling and reconciliation when event coverage is incomplete.
No. A dedicated ProcessMaker connector is not required. Martini can integrate using ProcessMaker’s confirmed native mechanisms, principally its REST API, OAuth-style bearer authentication, supported file endpoints, and selected webhook or outbound callback capabilities.
Lonti does not charge an additional per-connector or per-vendor fee to integrate ProcessMaker. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from ProcessMaker, infrastructure providers, or other third-party systems depending on subscription, usage, and deployment model.
The REST API should be the default mechanism for new integrations. Use documented file endpoints for attachments and consider webhook-style callbacks for selected events only after confirming coverage, authentication, retries, and payload behavior for the specific deployment. GraphQL and SOAP were not confirmed as current ProcessMaker interfaces.
Some ProcessMaker product configurations support webhook-style or outbound event capabilities, but they should not be assumed to cover every request, task, approval, or state transition. Martini can receive supported callbacks through an exposed API, retrieve the current resource when needed, and combine event processing with scheduled reconciliation.
Synchronization can be event-assisted or scheduled. Martini can receive selected notifications, query ProcessMaker requests and tasks through paginated REST calls, map statuses and assignments, and update target applications idempotently. Checkpoints, correlation IDs, pagination, and reconciliation help prevent missed changes and duplicate updates.
Martini can distinguish authentication, validation, rate-limit, and transient service failures, then apply appropriate retry and backoff policies. For process starts, task completions, and file uploads, workflows should preserve correlation IDs and check whether the operation already succeeded before retrying. Failed messages and outcomes can be logged for investigation and reconciliation.
Related Martini documentation
Workflows
Build a maintainable ProcessMaker integration with Martini
Use Martini to connect ProcessMaker workflows with enterprise applications, APIs, and document systems through secure, observable, and reusable integration workflows.