Ellipse Gradient for Header

Mendix Integration Guide

Integrate Mendix Platform APIs and application-specific REST, SOAP, OData, and callback interfaces with enterprise workflows and systems.

Mendix integration options at a glance

Mendix supports Platform and Developer Portal REST APIs, as well as REST, SOAP, and OData services published by individual applications. A Mendix application can also consume external services and implement selected callback or webhook-style behaviors, although event coverage and payload contracts are application-specific. Platform deployment operations may be asynchronous and require status polling. Martini can consume these APIs, authenticate with OAuth 2.0 or application-configured methods, transform JSON and XML, orchestrate scheduled or event-driven workflows, and expose REST APIs for Mendix applications to call. File-document exchanges are possible through application-specific endpoints, while direct database access is not the default integration boundary.

Integration pointSupported by Mendix?Common use casesHow Martini supports it
REST APIsYesUse Mendix Platform and Developer Portal APIs for application lifecycle and deployment operations, or consume REST services published by a specific Mendix application.Martini can consume Mendix REST endpoints, map JSON payloads, apply business rules, and expose reusable REST APIs or workflows around them.
SOAP APIsYesMendix can publish and consume WSDL-defined SOAP web services for XML-based enterprise integration.Martini can consume the WSDL-defined service, send XML requests, transform responses, and handle SOAP authentication and faults.
OData servicesYesMendix applications can expose selected application data through OData, subject to configured entities, associations, query options, and access rules.Martini can retrieve OData entity sets, apply application-supported filters and pagination, and transform results for downstream systems.
Webhooks / outbound callbacksLimitedSelected Mendix applications or platform features can implement callbacks through application logic, custom REST services, or selected lifecycle capabilities; universal event coverage is not confirmed.Martini can expose an authenticated REST API to receive callbacks, validate payloads, deduplicate events, and route them through workflows.
Bulk / async / batch APIsLimitedBatch and asynchronous behavior depends on the exposed REST or OData service and application design. Platform deployment operations may require later status checks.Martini can orchestrate pagination or batches, persist operation identifiers, poll status with bounded backoff, and distinguish submitted from completed operations.
File / attachment APIsLimitedMendix FileDocument entities may be exposed through application-specific REST or other services, but there is no universal attachment API.Martini can retrieve or receive files, validate metadata and content types, transform or route content, and deliver it to approved targets.
AuthenticationYesPlatform APIs use OAuth 2.0-based authorization patterns, while applications may use Basic Authentication, tokens, OAuth 2.0, user roles, or custom security logic.Martini can store credentials and secrets securely, configure API authentication, and separate authorization settings across Mendix environments.
Database accessNot confirmedDirect database access is not the default Mendix integration contract and depends on deployment architecture; API, OData, SOAP, file, or messaging boundaries are preferred.Martini can connect to databases where separately authorized and supported, but the Mendix application’s published interfaces should normally be used instead.

How Mendix exposes data and business events

Mendix REST APIs

Mendix provides Platform and Developer Portal REST APIs and allows individual applications to publish application-specific REST services. The resources, filters, schemas, and permissions depend on whether the target is the platform or a particular deployed application.

Martini implementation pattern

Martini implementation pattern: Martini authenticates to the selected REST interface, retrieves or submits JSON, validates the response, maps application-specific fields, and orchestrates downstream systems through a workflow or exposed API.

Implementation sequence

Authenticate with the Mendix Platform API or application REST service
Retrieve the current resource or receive the request
Validate the response and application-specific fields
Map JSON data to the canonical or target model
Apply business rules and write the result
Persist identifiers, status, and diagnostic context

Mendix SOAP APIs

Mendix supports publishing and consuming SOAP web services using WSDL-defined operations and XML messages. The service contract and authentication configuration are supplied by the individual application team.

Martini implementation pattern

Martini implementation pattern: Martini consumes the WSDL-defined service, constructs XML requests, handles SOAP faults, transforms XML into the target representation, and coordinates retries or compensating actions.

Implementation sequence

Load the Mendix service contract and authentication requirements
Call the WSDL-defined SOAP operation
Parse the XML response or SOAP fault
Transform the result into the target structure
Apply validation and business rules
Record the response status and retry eligible failures

Mendix OData services

Mendix applications can expose selected entities through OData. Available entity sets, associations, query options, pagination, and access rules are configured by the application team rather than standardized across all Mendix applications.

Martini implementation pattern

Martini implementation pattern: Martini retrieves supported OData pages, applies confirmed filters and ordering, maps entity sets into a canonical model, and checkpoints progress for scheduled synchronization.

Implementation sequence

Confirm the published entity sets and supported query options
Authenticate and request the first page
Follow the documented pagination or continuation mechanism
Map OData entities and associations
Apply incremental-sync and validation rules
Store the checkpoint and write downstream changes

Mendix callbacks and webhook-style notifications

Mendix does not provide universal webhook coverage for every application event. A Mendix application can implement callbacks through microflows, custom REST services, or selected platform capabilities, with event coverage and retry semantics agreed for the specific solution.

Martini implementation pattern

Martini implementation pattern: Martini exposes an authenticated REST API, validates the inbound callback, derives an idempotency key, routes supported events, and returns an appropriate response to the Mendix caller.

Implementation sequence

Receive the callback at a Martini API endpoint
Authenticate and validate the request
Check the event identifier or business-key fingerprint
Route the supported event to a workflow
Map and write the event to downstream systems
Return the response and record processing status

Mendix Platform deployment operations

Mendix Platform deployment operations can be asynchronous. A submitted operation may require later status checks before it is classified as completed, failed, or canceled.

Martini implementation pattern

Martini implementation pattern: Martini selects the application and environment, submits an authorized deployment request, stores the returned operation identifier, polls with bounded backoff, and notifies release systems when the terminal state is known.

Implementation sequence

Identify the Mendix application and target environment
Submit the authorized deployment operation
Store the external operation identifier
Poll deployment status with bounded backoff
Classify the terminal deployment result
Notify the release or operations system

Common Mendix integration patterns

Pattern 1: Orchestrate Mendix deployments

When to use this pattern

Use this pattern when release approval, CI/CD, or change-management processes need to initiate and monitor Mendix deployments across development, test, acceptance, or production environments.

Integration direction
Microsoft Azure DevOps
Martini
Mendix
Example Mapping
Mendix FieldCanonical FieldTarget Field
releaseIdrelease.identifierDeployment.releaseReference
applicationIdapplication.identifierApp.id
environmentIdenvironment.identifierEnvironment.id
operationStatusdeployment.statusDeployment.status
Martini implementation pattern

A Martini workflow receives an approved release request, calls the Mendix Platform API with environment-specific authorization, stores the asynchronous operation identifier, polls with bounded retries, and updates Azure DevOps or another release system. It distinguishes transport errors, authorization failures, validation errors, and terminal deployment failures.

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

Pattern 2: Synchronize Mendix application objects

When to use this pattern

Use this pattern when a deployed Mendix application exposes REST or OData services for customers, orders, cases, or other application-specific objects that must be synchronized with an enterprise system.

Integration direction
Mendix
Martini
Salesforce
Example Mapping
Mendix FieldCanonical FieldTarget Field
applicationObject.idbusinessObject.externalIdSalesforce.ExternalId
applicationObject.modifiedDateaudit.modifiedAtSalesforce.LastModifiedDate
applicationObject.statusbusinessObject.statusSalesforce.Status
applicationObject.namebusinessObject.displayNameSalesforce.Name
Martini implementation pattern

A scheduled Martini workflow retrieves filtered pages or changed objects using the application’s documented timestamps, markers, or query options. It maps the application-specific schema, applies create-or-update rules, records checkpoints and external identifiers, and retries transient responses without duplicating writes.

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

Pattern 3: Process Mendix business callbacks

When to use this pattern

Use this pattern when a Mendix application is designed to call an external endpoint after selected events such as an approved order, completed case, or changed customer object.

Integration direction
Mendix
Martini
ServiceNow
Example Mapping
Mendix FieldCanonical FieldTarget Field
eventIdevent.idServiceNow.CorrelationId
eventTypeevent.typeServiceNow.RequestType
objectIdbusinessObject.externalIdServiceNow.ExternalReference
occurredAtevent.occurredAtServiceNow.SourceTimestamp
Martini implementation pattern

Mendix calls a Martini-exposed REST API. Martini authenticates and validates the request, checks the event identifier or business-key fingerprint, routes approved event types, maps the payload to ServiceNow, and returns a controlled response while placing retryable failures into an operational recovery path.

Martini capabilities used
  • API exposure
  • authentication and authorization
  • workflows
  • data mapping
  • idempotency rules
  • error handling

Pattern 4: Exchange Mendix documents

When to use this pattern

Use this pattern when a Mendix application exposes FileDocument operations and documents must be transferred with metadata to SharePoint or another controlled repository.

Integration direction
Mendix
Martini
SharePoint
Example Mapping
Mendix FieldCanonical FieldTarget Field
fileNamedocument.nameSharePoint.Name
mimeTypedocument.contentTypeSharePoint.ContentType
fileSizedocument.sizeSharePoint.Size
documentIddocument.externalIdSharePoint.DocumentId
Martini implementation pattern

Martini retrieves or receives the application-specific file representation, validates MIME type, size, naming, and authorization, transfers the content to SharePoint, and records the target identifier. The workflow uses bounded retries and avoids duplicate uploads with a document key or checksum where available.

Martini capabilities used
  • workflows
  • API consumption
  • file handling
  • data validation
  • mapping
  • business rules
  • retry handling

Applications commonly integrated with Mendix

Mendix applications are frequently positioned between user-facing processes and enterprise systems of record. The exact objects and mappings depend on the individual Mendix application’s domain model and published interfaces.

Application Scenario Direction Martini Pattern
Salesforce Synchronize customers, contacts, opportunities, service cases, or workflow data between a Mendix portal or application and Salesforce. Mendix → Martini → Salesforce Martini consumes the Mendix REST or OData service, maps application-specific objects to Salesforce payloads, applies create-or-update rules, and routes validation or API failures for retry and review.
SAP S/4HANA Connect Mendix procurement, order, product, inventory, finance, or field-service applications with SAP master and transactional data. Mendix → Martini → SAP S/4HANA A scheduled or callback-driven workflow retrieves Mendix objects, transforms them into SAP-compatible structures, applies business validation, and records external identifiers and processing status.
ServiceNow Connect Mendix employee, customer, asset, or operational applications with ServiceNow incidents, requests, changes, and catalog processes. Mendix → Martini → ServiceNow Martini receives Mendix callbacks or polls published services, maps the event or object to ServiceNow, enforces idempotency, and handles downstream errors through bounded retries.
Microsoft Dynamics 365 Synchronize customer, sales, service, and business-process information between Mendix applications and Dynamics 365. Mendix → Martini → Microsoft Dynamics 365 Martini orchestrates REST calls in both directions, normalizes application-specific Mendix data, applies ownership and status rules, and stores correlation identifiers for updates.
Jira Link Mendix delivery, approval, issue, and operational workflows with Jira issues and project data. Mendix → Martini → Jira A Martini workflow converts selected Mendix events or deployment outcomes into Jira issue operations, maps priorities and statuses, and prevents duplicate issue creation using a business key.
SAP SuccessFactors Connect Mendix employee-facing applications with employee, organization, and HR process data while respecting HR data restrictions. SAP SuccessFactors → Martini → Mendix Martini retrieves authorized SuccessFactors data, validates target application access, transforms the response into the Mendix application schema, and logs restricted-field failures without exposing sensitive values.
Microsoft Azure DevOps Connect Mendix development or deployment workflows with Azure DevOps work items, pipelines, and release processes. Mendix → Martini → Microsoft Azure DevOps Martini calls Mendix Platform APIs for deployment status, correlates operations with Azure DevOps work items or releases, and routes asynchronous completion or failure notifications.
SharePoint Exchange documents and metadata between Mendix file-document workflows and enterprise collaboration or document-management sites. Mendix → Martini → SharePoint Martini retrieves or receives Mendix file content, validates MIME type and metadata, transfers it to SharePoint, and records document identifiers and checksum or retry information.

How to build a Mendix integration in Martini

Objective

Identify whether the integration targets Mendix Platform APIs or a deployed Mendix application, then obtain the applicable API contract and authorization requirements.

Instructions in Martini

  • Confirm the organization, project, application, and environment scope.
  • Choose OAuth 2.0, Basic Authentication, token-based, or application-specific security as documented.
  • Store client secrets, tokens, and certificates in Martini secrets management.
  • Separate development, test, and production endpoint configuration.

Objective

Select a schedule, inbound callback, API request, or deployment event based on the Mendix capability confirmed for the use case.

Instructions in Martini

  • Use a scheduler for polling REST or OData resources.
  • Expose a Martini REST API when the Mendix application will call back.
  • Use a workflow trigger for release or deployment orchestration.
  • Confirm event coverage and retry semantics before treating callbacks as reliable events.

Objective

Call the Mendix interface with controlled pagination, filtering, and authorization, or receive and validate an inbound application request.

Instructions in Martini

  • Use the published REST, SOAP, or OData contract rather than assuming a universal schema.
  • Capture page, continuation, timestamp, marker, or operation identifiers.
  • Respect application-specific entity access rules and service-account permissions.
  • Handle asynchronous deployment responses separately from completed results.

Objective

Coordinate Mendix calls, target-system operations, business decisions, and asynchronous status checks in a maintainable Martini workflow.

Instructions in Martini

  • Separate transport, validation, transformation, and target-write stages.
  • Use correlation identifiers across Mendix and downstream systems.
  • Add bounded polling and backoff for asynchronous operations.
  • Route terminal failures to an operational notification or recovery process.

Objective

Convert application-specific Mendix JSON, XML, OData, or file metadata into a canonical and target-system representation.

Instructions in Martini

  • Base mappings on the published application API or OData metadata.
  • Normalize dates, identifiers, statuses, enumerations, and associations.
  • Transform SOAP XML or document metadata where required.
  • Validate required fields before writing to the target.

Objective

Enforce authorization, duplicate detection, create-or-update behavior, and business validation before side effects occur.

Instructions in Martini

  • Use event identifiers, business keys, or request fingerprints for idempotency.
  • Define handling for missing, renamed, or restricted domain-model attributes.
  • Apply environment-specific and status-based routing rules.
  • Do not expose sensitive HR, document, or application data beyond approved recipients.

Common Mendix data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrganizationRepresents the Mendix organization that owns applications and manages users and permissions in Platform API workflows.Identity administration, release management, governance platformsMartini retrieves organization data through authorized Platform APIs and preserves organization context for permission-aware workflows.
ProjectRepresents a Developer Portal project used for collaboration, planning, and application lifecycle management.Jira, Microsoft Azure DevOps, portfolio and release systemsMartini maps project identifiers and lifecycle information to external work-management records and stores correlation keys.
App / ApplicationRepresents a Mendix application registered in the Developer Portal or a deployed application exposed through application-specific services.Catalogs, release systems, monitoring and governance toolsMartini uses application identifiers and published API contracts to route calls and select environment-specific configuration.
EnvironmentRepresents a development, test, acceptance, or production runtime environment associated with an application.Change management, CI/CD, operations platformsMartini uses environment identifiers to target deployments, separate credentials, and apply environment-specific business rules.
DeploymentRepresents an application delivery operation or deployment record, which may complete asynchronously.Azure DevOps, Jira, ServiceNow, release-management platformsMartini submits or observes deployment operations, persists operation identifiers, polls status, and routes terminal failures.
Branch or application versionIdentifies the source-code or model version used in application development and deployment workflows.Source control, CI/CD, release and approval systemsMartini maps version references to release records and validates that the requested version and target environment are compatible.

Authentication and security considerations

Interface-specific authentication

Mendix Platform APIs use OAuth 2.0-based authorization patterns with permissions scoped to organizations, projects, applications, and environments. A deployed Mendix application may instead use Basic Authentication, tokens, OAuth 2.0, Mendix users and roles, or custom authentication logic.

Least privilege and secrets

  • Obtain the application API contract and security configuration before implementation.
  • Use separate credentials for development, test, and production.
  • Store client secrets, access tokens, and certificates in Martini secrets management.
  • Apply entity access rules and service-account permissions appropriate to the data being exchanged.

Inbound protection

When Mendix calls a Martini API, validate authentication, authorization, request structure, event identifiers, and any agreed signature or replay controls. Avoid credentials in query parameters and validate TLS certificates.

Operational considerations for Mendix integrations

Pagination and incremental synchronization

Confirm pagination, continuation, sorting, and filtering for every REST or OData service. Do not assume that custom Mendix REST services follow OData conventions. Use a reliable timestamp, sequence, status marker, or application-provided change mechanism for incremental synchronization.

Asynchronous operations

Deployment requests may return before completion. Persist the external operation identifier, poll with bounded retries and backoff, and distinguish submitted, completed, failed, and canceled states.

Reliability and idempotency

  • Use event identifiers, business keys, or request fingerprints to prevent duplicate processing.
  • Apply controlled concurrency and exponential backoff for throttling and transient server errors.
  • Separate transport failures from validation and terminal business failures.
  • Record Mendix request identifiers, operation identifiers, checkpoints, and target identifiers.

Schema and document changes

Mendix domain models and generated API schemas are application-specific and can change with deployments. Test against each target environment, validate required fields and enumerations, and agree on versioning. For FileDocument exchanges, define file size, MIME type, naming, retention, authorization, and retry rules.

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

Reusable orchestration

Martini provides a maintainable workflow layer for Mendix API calls, callbacks, deployment polling, downstream writes, and operational notifications instead of scattering logic across scripts or point-to-point mappings.

Controlled transformation

Because Mendix business objects are application-specific, Martini can centralize mappings from published REST, OData, SOAP, or file contracts into canonical and target-system models. Validation and business rules remain visible and reusable.

Operational reliability

  • Use secure environment configuration and secrets management.
  • Apply retries, backoff, idempotency, and asynchronous status handling consistently.
  • Expose controlled APIs for Mendix callbacks and enterprise consumers.
  • Preserve logs, correlation identifiers, checkpoints, and failure context for support and audit.

Frequently asked questions

How can Mendix be integrated with enterprise systems?

Mendix can integrate through Platform and Developer Portal REST APIs, application-published REST or OData services, WSDL-based SOAP web services, application-generated callbacks, and file-document endpoints. The appropriate method depends on whether the target is the Mendix platform or a specific application and on the interfaces that application exposes.

Can Martini integrate with Mendix?

Yes. Martini can consume Mendix Platform REST APIs, application REST and OData services, and SOAP services, and can receive requests through a Martini-exposed REST API when a Mendix application is configured to call it. Martini can also orchestrate deployment status checks, mappings, validation, and downstream writes.

Do I need a connector to integrate Mendix with Martini?

No dedicated Mendix connector is required. Martini can use Mendix’s confirmed native integration mechanisms, including REST, SOAP, OData, application callbacks, Platform APIs, and configured authentication methods.

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

Lonti does not charge an additional per-connector or per-vendor fee to integrate Mendix. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Mendix, infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.

Which Mendix integration methods should architects use?

REST is the primary choice for Mendix Platform APIs and application-published services. OData can be useful when an application exposes suitable entity sets and query capabilities, while SOAP remains relevant for WSDL-based enterprise services. The application team should confirm the contract, permissions, pagination, and versioning policy.

Does Mendix provide webhooks or event notifications?

Mendix does not provide universal webhook coverage for every application event. A specific application can implement callbacks through microflows, custom REST services, or selected platform capabilities. Martini can receive these requests, but event types, signatures, retries, and payloads must be confirmed for the implementation.

How does synchronization work when Mendix has application-specific objects?

Martini synchronizes the objects exposed by the individual application’s REST or OData contract. A scheduled workflow can use documented filters, modification timestamps, status markers, or change logs, then map the results to a canonical model and target system while storing checkpoints and external identifiers.

How does Martini handle Mendix errors, retries, and duplicate requests?

Martini can distinguish transport, authorization, validation, SOAP fault, throttling, and terminal business errors. Workflows can use bounded retries and backoff for transient failures, while event identifiers, business keys, or request fingerprints provide idempotency controls for callbacks and create-or-update operations.

Related Martini documentation

APIs

Workflows

Transformation

Security

Operations

Connect Mendix with your enterprise systems

Use Martini to build secure, maintainable Mendix integrations across Platform APIs, application services, callbacks, deployments, and downstream systems.

EXPLORE MARTINI
BOOK A DEMO