Ellipse Gradient for Header

Nintex Integration Guide

Nintex integrates with enterprise systems through product-specific REST APIs, HTTP triggers, selected webhook-style events, file interfaces, and authenticated workflow endpoints.

Nintex integration options at a glance

Nintex integration capabilities vary across Nintex Automation Cloud, Nintex Workflow, Forms, Process Manager, DocGen, and RPA. REST APIs are the primary standards-based option for retrieving workflow, process, task, form, and document-related information or initiating supported operations. Selected products also provide HTTP triggers, webhook-style notifications, or callbacks, although event coverage must be confirmed for each product and event. Files and generated documents may be exchanged through product-specific endpoints or identifiers. Authentication can include API keys or OAuth 2.0 bearer tokens with scopes and tenant permissions. Martini can consume these APIs, receive inbound requests, orchestrate workflows, map payloads, and apply validation, retry, and correlation logic.

Integration pointSupported by Nintex?Common use casesHow Martini supports it
REST APIsYesNintex provides product and platform REST APIs for workflow, process-management, administration, and other product-specific operations. The API family and resource model must be confirmed for the selected Nintex product.Martini can consume Nintex REST APIs from workflows, generate reusable API integration assets from external definitions where available, transform payloads, and expose APIs for downstream consumers.
Webhooks and outbound callbacksLimitedSelected Nintex scenarios support HTTP-triggered or webhook-style event patterns for workflow initiation or product-specific notifications. Coverage is not universal across objects or events.Martini can receive webhook-style requests through APIs or workflow triggers, validate authentication and signatures where applicable, retrieve full resources when notifications contain only identifiers, and start downstream workflows.
Bulk, asynchronous, and batch APIsLimitedAsynchronous or large-volume operations may exist for selected workflow, document-generation, or product APIs, but no universal Nintex bulk API was confirmed.Martini can orchestrate queued or scheduled processing, persist job and pagination state, poll documented status endpoints, and handle completion or failure paths.
File and attachment APIsLimitedFiles, attachments, templates, and generated documents are important in Nintex Forms, Workflow, and DocGen scenarios. Upload and download behavior varies by product and deployment.Martini can map binary content, identifiers, URLs, metadata, or separately retrieved files and route them to supported enterprise endpoints while applying size and retention controls.
AuthenticationYesNintex authentication varies by product and can include API keys, OAuth 2.0 bearer tokens, scopes, tenant permissions, and product-level roles.Martini can store credentials in environment configuration and secrets, call authenticated endpoints, apply authorization headers, and separate credentials by environment or Nintex product.
Scheduled synchronizationYesScheduled retrieval is suitable for Process Manager metadata, workflow status, documents, or other resources when event delivery is unavailable or incomplete.Martini can schedule workflows, paginate through Nintex resources, apply incremental checkpoints, and write synchronized data to enterprise systems.
Database accessNot confirmedDirect access to Nintex-managed operational databases was not confirmed. Documented APIs, exports, reports, or product interfaces should be used instead.Martini can write synchronized Nintex data to a customer-managed database, but it should not assume direct access to Nintex-managed storage.

How Nintex exposes data and business events

Nintex REST APIs

REST is Nintex’s primary standards-based integration mechanism, but API models vary between Automation Cloud, Process Manager, DocGen, and other products. Resources may include workflows, workflow instances, tasks, processes, forms, and documents depending on the selected API family.

Martini implementation pattern

Martini implementation pattern: Martini authenticates to the product-specific Nintex REST API, retrieves or submits the required resource, validates the response, maps it to a canonical model, and persists identifiers and checkpoints for correlation and repeatable synchronization.

Implementation sequence

Identify the Nintex product, tenant, API family, and version
Configure the documented API key or OAuth 2.0 credentials
Call the Nintex REST endpoint from a Martini workflow
Handle pagination, status codes, and rate-limit responses
Map the response into the target system model
Persist resource identifiers, checkpoints, and correlation values

Nintex webhooks and callbacks

Selected Nintex scenarios provide HTTP-triggered or webhook-style event patterns for workflow initiation or product-specific notifications. Event coverage, payload shape, authentication, and retry behavior must be checked per product and event.

Martini implementation pattern

Martini implementation pattern: Martini exposes an authenticated REST endpoint or receives a supported webhook request, validates the event and replay controls, retrieves the full Nintex resource when necessary, and starts an orchestration workflow.

Implementation sequence

Confirm the Nintex product and supported event or HTTP trigger
Expose a Martini REST endpoint for the documented request
Validate authentication, signature, timestamp, and event schema
Extract the resource identifier and correlation key
Retrieve the current Nintex resource when the event is not complete
Route the validated event through the required Martini workflow

Nintex files and documents

Nintex Forms, Workflow, and DocGen scenarios may exchange attachments, templates, generated documents, identifiers, or temporary URLs. File behavior differs by product, including retrieval authentication and link expiration.

Martini implementation pattern

Martini implementation pattern: Martini receives a document reference or generation result, calls the documented Nintex file endpoint, validates content type and size, and routes the file or metadata to the target repository or signature platform.

Implementation sequence

Confirm the Nintex file representation and endpoint
Submit or retrieve the documented document or generation request
Track asynchronous job status when applicable
Download the file using the required authentication
Validate content type, size, and retention requirements
Store or distribute the document and persist its correlation identifier

Nintex scheduled synchronization

Scheduled synchronization is appropriate for Process Manager processes, workflow instances, tasks, or other resources when event coverage is incomplete or unavailable. Pagination and incremental retrieval are required for larger collections.

Martini implementation pattern

Martini implementation pattern: A scheduled Martini workflow retrieves Nintex resources in pages, compares deterministic keys and modified values with the target state, applies business rules, and writes only new or changed objects.

Implementation sequence

Schedule the synchronization workflow at an appropriate interval
Read the stored checkpoint and pagination state
Retrieve the next Nintex page through the documented API
Normalize and validate each resource
Upsert the resource using a deterministic business key
Store the checkpoint and emit operational metrics

Common Nintex integration patterns

Pattern 1: Start a Nintex workflow from an enterprise application

When to use this pattern

Use this pattern when a system such as Salesforce, ServiceNow, SharePoint, or Dynamics 365 must initiate a Nintex approval or business process. Martini provides validation, transformation, correlation, and controlled invocation around the product-specific Nintex endpoint.

Integration direction
Enterprise application
Martini
Nintex
Example Mapping
Nintex FieldCanonical FieldTarget Field
sourceObjectIdbusinessObjectIdworkflow input object identifier
approvalAmountapprovalValueworkflow variable approvalAmount
requesterEmailinitiatorEmailworkflow initiator
Martini implementation pattern

Martini receives an application event or polls the source, validates required fields, applies routing rules, and invokes the documented Nintex REST or HTTP workflow-start mechanism. It stores the Nintex workflow instance identifier, prevents duplicate starts with an idempotency key, and returns or synchronizes status to the source system.

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

Pattern 2: Orchestrate Nintex workflow integrations through Martini

When to use this pattern

Use this pattern when Nintex manages human workflow execution but Martini must coordinate several enterprise APIs, database lookups, transformations, or business rules that should not be embedded in a single Nintex action chain.

Integration direction
Nintex
Martini
Enterprise APIs and databases
Example Mapping
Nintex FieldCanonical FieldTarget Field
workflowInstanceIdprocessCorrelationIdsource and target correlation ID
taskOutcomeapprovalDecisionenterprise approval status
formData.customerReferencecustomerIdcustomer master identifier
Martini implementation pattern

Nintex sends a documented HTTP request or event to a Martini API. Martini authenticates and validates the request, enriches it through enterprise APIs or SQL queries, applies decision rules, writes results to target systems, and returns a normalized response. Failures are categorized for retry or manual review without losing the Nintex correlation identifier.

Martini capabilities used
  • API exposure
  • workflows
  • API consumption
  • SQL integration
  • data transformation
  • business rules
  • error handling

Pattern 3: Synchronize Nintex Process Manager processes

When to use this pattern

Use this pattern when process documentation, owners, or process metadata must be replicated into ServiceNow, SharePoint, a SQL repository, or a governance platform for reporting and operational consistency.

Integration direction
Nintex Process Manager
Martini
ServiceNow
Example Mapping
Nintex FieldCanonical FieldTarget Field
processIdprocessKeyprocess external identifier
processNameprocessTitlename
ownerprocessOwnerowner or responsible group
Martini implementation pattern

A scheduled Martini workflow retrieves Processes and related metadata through the documented Nintex API, follows the product’s pagination model, filters by modification checkpoint, and upserts target objects using the Nintex process identifier. It handles throttling, records rejected records, and retries transient failures.

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

Pattern 4: Generate and distribute Nintex documents

When to use this pattern

Use this pattern when source data from an ERP, CRM, or case-management system must be transformed into a Nintex DocGen request and the resulting document must be stored, signed, or distributed.

Integration direction
Enterprise application
Martini
Nintex DocGen
Example Mapping
Nintex FieldCanonical FieldTarget Field
account.namecustomerNametemplate customerName
invoice.totaldocumentTotaltemplate documentTotal
generatedDocumentIdfileReferencerepository or signature document ID
Martini implementation pattern

Martini retrieves and validates source data, transforms it to the documented Nintex document-generation structure, submits the request, and tracks the asynchronous job where applicable. After completion it retrieves the generated file, validates content metadata, sends it to SharePoint or DocuSign, and retries or dead-letters failures using the job correlation key.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • file handling
  • asynchronous orchestration
  • business rules
  • error handling

Applications commonly integrated with Nintex

Nintex commonly participates in enterprise process, approval, document, and workflow landscapes. The exact integration method depends on the Nintex product, tenant, and APIs available, so each relationship should be validated before implementation.

Application Scenario Direction Martini Pattern
Microsoft SharePoint SharePoint can provide source content, form submissions, documents, and process artifacts for Nintex workflows, while generated outcomes can be returned to SharePoint. Microsoft SharePoint → Martini → Nintex Martini receives a SharePoint event or scheduled extract, maps the business payload, invokes a documented Nintex HTTP or REST endpoint, and stores the workflow instance identifier for status correlation.
Microsoft Teams Teams can surface approval notifications and workflow interactions while Nintex manages the underlying process execution. Nintex → Martini → Microsoft Teams Martini receives a Nintex task or workflow event, transforms it into the Teams-facing request supported by the customer environment, and routes user actions or status updates back to Nintex where documented.
Salesforce Salesforce records can initiate approvals or customer-service processes, with workflow outcomes and generated documents written back to Salesforce. Salesforce → Martini → Nintex A Martini API or scheduled workflow validates Salesforce data, invokes the selected Nintex workflow or document operation, and updates Salesforce with the resulting status, identifier, or document reference.
ServiceNow ServiceNow requests, cases, and approvals can be coordinated with Nintex business processes and workflow execution. ServiceNow → Martini → Nintex Martini consumes ServiceNow API data or events, applies routing and approval rules, calls the appropriate Nintex REST or HTTP endpoint, and synchronizes task or workflow status back to ServiceNow.
SAP S/4HANA SAP master and transaction data can participate in Nintex approvals and business processes. SAP S/4HANA → Martini → Nintex Martini retrieves or receives SAP data through the customer’s supported SAP interface, transforms it into the Nintex request model, starts or updates the documented process, and records correlation identifiers.
Jira Jira issues, change requests, and status information can be coordinated with Nintex approvals and process flows. Jira → Martini → Nintex Martini consumes Jira events or scheduled data, maps issue and approval fields, invokes Nintex through its documented API, and synchronizes resulting task or workflow status with idempotency controls.
DocuSign Documents generated or managed through Nintex processes can be routed for electronic signature, with signature status returned to the workflow. Nintex → Martini → DocuSign Martini retrieves or receives the Nintex document reference, submits the document to the supported DocuSign API, monitors completion, and returns the signature status or envelope identifier to Nintex.
Microsoft Dynamics 365 Dynamics records and cases can initiate process automation, while Nintex results can be written back to the originating business record. Microsoft Dynamics 365 → Martini → Nintex A Martini workflow consumes Dynamics data, validates required fields, invokes the relevant Nintex workflow or document endpoint, and updates Dynamics with the execution result and correlation identifiers.

How to build a Nintex integration in Martini

Objective

Identify the Nintex product, tenant, API family, region, and required permissions before configuring the integration.

Instructions in Martini

  • Confirm whether the target is Automation Cloud, Process Manager, DocGen, Forms, Workflow, or another Nintex product.
  • Select the authentication method documented for that API, such as an API key or OAuth 2.0 bearer token.
  • Store credentials, scopes, tenant settings, and endpoint configuration in Martini environment configuration and secrets.

Objective

Select an event-driven or scheduled entry point that matches the confirmed Nintex capabilities and expected volume.

Instructions in Martini

  • Use a documented Nintex HTTP trigger, webhook-style notification, or callback when available.
  • Expose a Martini REST API when Nintex must initiate a Martini workflow.
  • Use a scheduler when event coverage is unavailable or when controlled synchronization is more appropriate.

Objective

Obtain the complete Nintex resource or event payload while accounting for identifiers, pagination, and asynchronous execution.

Instructions in Martini

  • Validate incoming event authentication, schema, timestamps, and replay controls.
  • Retrieve the full resource when a notification contains only an identifier.
  • Persist pagination, continuation, job, and workflow instance state where required.

Objective

Coordinate Nintex calls, enterprise APIs, database lookups, document operations, and conditional routing in a maintainable Martini workflow.

Instructions in Martini

  • Separate transport, validation, transformation, business rules, and target writes into clear workflow stages.
  • Use correlation values such as source event ID, Nintex workflow instance ID, process ID, or document job ID.
  • Route transient failures to controlled retries and permanent failures to an exception or review path.

Objective

Convert Nintex product-specific payloads into a canonical model and target-specific structures.

Instructions in Martini

  • Map actual objects such as Workflows, Tasks, Processes, Forms, and Documents to target fields.
  • Handle optional fields, changed form variables, new enum values, and different attachment representations.
  • Apply JSON, file, and metadata transformations without placing secrets or sensitive document content in logs.

Objective

Enforce validation, idempotency, permissions, routing, and lifecycle rules before creating or updating downstream resources.

Instructions in Martini

  • Use deterministic business keys or event identifiers to prevent duplicate workflow starts and document requests.
  • Distinguish accepted, running, completed, failed, cancelled, and timed-out operations.
  • Check required permissions and reject invalid or incomplete requests before invoking Nintex.

Common Nintex data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
WorkflowsWorkflow definitions and automations containing triggers, actions, variables, forms, and connected-system operations.ServiceNow, SharePoint, Salesforce, SAP S/4HANA, Microsoft Dynamics 365Martini retrieves or invokes product-specific workflow resources through documented REST or HTTP endpoints, maps configuration or invocation data, and stores product and version context.
Workflow instancesRuntime executions used to correlate requests, monitor progress, and retrieve execution status.ServiceNow, Salesforce, Jira, reporting databasesMartini stores the Nintex workflow instance identifier with the source event and uses documented callbacks, status APIs, or scheduled polling to synchronize lifecycle changes.
TasksHuman or system work items generated during workflow execution, especially for approvals and case processes.ServiceNow, Microsoft Teams, Salesforce, JiraMartini maps task assignments, status, due dates, and business keys, then applies idempotent updates and routing rules in target systems.
FormsDigital forms that collect input and initiate or support workflow execution.SharePoint, Salesforce, Microsoft Dynamics 365, internal databasesMartini validates form submissions, normalizes field names and values, handles optional or changed fields, and forwards approved payloads to downstream APIs.
ProcessesDocumented business processes managed by Nintex Process Manager, including metadata and ownership information.ServiceNow, SharePoint, SQL databases, governance and reporting platformsMartini retrieves paginated process data on a schedule, applies incremental synchronization and deterministic keys, and records changes in the target repository.
Documents and document-generation jobsTemplates, generated files, document metadata, and asynchronous generation requests associated with Nintex DocGen or workflow processes.SharePoint, Salesforce, DocuSign, records repositories, email platformsMartini submits documented generation requests, tracks job status, retrieves files using supported identifiers or URLs, and routes content without exposing sensitive data in logs.

Authentication and security considerations

Product-specific authentication

Nintex authentication varies by product and API. Supported patterns may include API keys, OAuth 2.0 bearer tokens, scopes, tenant permissions, and product-level roles. Credentials issued for one Nintex product should not be assumed to work for another.

Secure Martini configuration

Martini should store API keys, client credentials, tokens, and tenant configuration in environment settings and secrets rather than workflow definitions. Use HTTPS for API communication and apply least-privilege permissions to dedicated integration identities.

Inbound request protection

For Nintex HTTP triggers or webhook-style events, validate authentication, signatures, timestamps, replay protection, payload schemas, and source restrictions where available before starting downstream workflows.

Operational considerations for Nintex integrations

Rate limits and pagination

Confirm limits for the selected Nintex API and handle HTTP 429 responses, Retry-After headers, exponential backoff, and maximum retry counts. Do not assume a first list response contains all Workflows, Processes, Tasks, or workflow instances.

Asynchronous operations

Workflow execution and document generation may be asynchronous. Track accepted, running, completed, failed, cancelled, and timed-out states using documented callbacks, status endpoints, or scheduled polling.

Idempotency and correlation

Use source event IDs, Nintex workflow instance IDs, process IDs, document job IDs, and deterministic business keys to prevent duplicate starts, document requests, or updates.

Schema and file changes

Protect mappings against changed form fields, new enum values, API versions, altered document metadata, and different attachment representations. Confirm file size, content type, URL expiry, authentication, and retention requirements.

Testing and observability

Test each Nintex product and tenant configuration separately. Log request outcomes and correlation identifiers without exposing tokens, passwords, sensitive form values, or confidential document contents.

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

Centralized orchestration

Martini provides a workflow layer for coordinating Nintex with enterprise APIs, databases, files, and other systems instead of embedding every integration concern in point-to-point scripts.

Reusable integration logic

API consumption, validation, mapping, business rules, correlation, retries, and exception handling can be organized into maintainable workflows and reusable services.

Flexible integration styles

Martini can consume Nintex REST APIs, receive supported HTTP requests, expose REST APIs for Nintex or other applications, and support real-time, scheduled, asynchronous, and batch-oriented patterns.

Operational control

Centralized configuration, secrets, logging, error paths, checkpoints, and deployment practices make Nintex integrations easier to monitor and evolve as products, forms, workflows, and schemas change.

Frequently asked questions

How can Nintex be integrated with enterprise systems?

Nintex can be integrated through product-specific REST APIs, documented HTTP workflow triggers, selected webhook-style notifications or callbacks, and file or document endpoints. The appropriate mechanism depends on whether the target is Nintex Automation Cloud, Process Manager, Forms, DocGen, Workflow, or another product.

Can Martini integrate with Nintex?

Yes. Martini can integrate with Nintex by consuming its documented REST APIs, receiving supported HTTP or webhook-style requests, handling product-specific file and document endpoints, and orchestrating workflows with enterprise applications. The API family and authentication method must be confirmed for the selected Nintex product.

Do I need a connector to integrate Nintex with Martini?

No. A dedicated Nintex connector is not required. Martini can use Nintex’s confirmed native integration mechanisms, including REST APIs, documented HTTP triggers or callbacks, supported webhook-style events, authentication methods, and file or document endpoints.

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

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

Which Nintex integration methods should an implementation use?

REST APIs are the primary method to investigate. Selected products also support HTTP-triggered workflows, webhook-style notifications, callbacks, asynchronous operations, and file or document endpoints. No official Nintex GraphQL or current SOAP API was confirmed, so those methods should not be assumed.

Are Nintex events and webhooks available for every object?

No. Nintex supports event-driven patterns in selected scenarios, but coverage is product- and event-specific. The implementation should confirm whether the event is inbound or outbound, whether it includes a full object or identifier, how it is authenticated, and how retries are handled.

How should Nintex data synchronization work?

Synchronization can use callbacks or webhook-style events where available, with scheduled REST API retrieval as a fallback. Martini can paginate through Workflows, Workflow instances, Tasks, Processes, or other supported resources, apply incremental checkpoints and deterministic keys, and upsert target data while handling throttling and retries.

How does Martini handle Nintex mapping, errors, and retries?

Martini maps product-specific Nintex payloads into canonical and target models, applies validation and business rules, and handles transient HTTP failures with controlled retry logic. Idempotency keys, workflow instance identifiers, checkpoints, correlation values, and exception paths help prevent duplicates and support investigation.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Build a maintainable Nintex integration with Martini

Use Martini to connect Nintex products with enterprise applications through authenticated APIs, event-driven workflows, scheduled synchronization, document handling, and reusable transformation logic.

EXPLORE MARTINI
BOOK A DEMO