.png)
OutSystems Integration Guide
Integrate OutSystems applications with enterprise systems through application-specific REST APIs, SOAP services, callbacks, files, and secure workflows.
OutSystems integration options at a glance
OutSystems primarily integrates through REST APIs that applications can consume or expose, with JSON and other HTTP payloads defined by application-specific Structures and API contracts. SOAP Web Services remain relevant for legacy enterprise services, while REST endpoints can also be implemented as webhook receivers or callback endpoints. File and binary exchanges are possible through multipart, binary, base64, or external URL patterns, depending on the application. Authentication may use OAuth 2.0, Basic Authentication, API keys, bearer tokens, custom headers, or certificates. Martini can consume these endpoints, expose APIs for OutSystems to call, orchestrate workflows, transform payloads, and manage retries and reconciliation.
| Integration point | Supported by OutSystems? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | OutSystems applications consume external REST APIs and expose REST endpoints for other systems. API methods, Structures, authentication, and payloads are application-specific. | Martini can consume OutSystems REST APIs or expose REST APIs for OutSystems applications to call, then map, validate, enrich, and route the data. |
| SOAP APIs | Yes | OutSystems can consume WSDL-based SOAP Web Services, particularly for legacy enterprise integrations. | Martini can consume OutSystems SOAP services or provide SOAP integration where the surrounding architecture requires it, including XML transformation and error handling. |
| Webhooks / outbound callbacks | Limited | OutSystems applications can expose REST endpoints that act as webhook receivers or callback endpoints. Universal outbound event coverage for all Entity changes is not confirmed. | Martini can expose callback endpoints, receive application-specific notifications, retrieve current data, and reconcile events when replay or event coverage is available. |
| Bulk / async / batch APIs | Limited | Applications can implement custom batch or asynchronous REST endpoints, but no standardized OutSystems-wide bulk API was confirmed. | Martini can orchestrate batch requests, track job identifiers and status endpoints, bound concurrency, and retry eligible failures. |
| File / attachment APIs | Limited | OutSystems application logic can handle file and binary data through multipart, binary, base64, or external URL contracts. | Martini can transfer, validate, transform, and route file payloads according to the specific API contract and content-type requirements. |
| Database access | Limited | OutSystems applications use their own data models and can integrate with external databases, but direct database coupling depends on deployment, schema ownership, and platform support. | Martini can use database integration where appropriate, while generally preferring the OutSystems API to avoid coupling to managed application schemas. |
| Authentication | Yes | Consumed and exposed services may use OAuth 2.0, Basic Authentication, API keys, bearer or JWT-style tokens, custom headers, and potentially client certificates. | Martini can configure API authentication, secure environment-specific credentials, apply authorization controls, and keep secrets outside workflow logic. |
How OutSystems exposes data and business events
OutSystems REST APIs
REST is OutSystems' primary standards-based integration mechanism. Applications can consume external REST APIs or expose endpoints with application-defined methods, request parameters, response Structures, authentication, and JSON or other HTTP payloads.
Martini implementation pattern
Martini integration pattern: Martini consumes the relevant OutSystems REST API or exposes a Martini REST API for OutSystems to call. The workflow authenticates, retrieves or accepts the application payload, validates the contract, maps it to a canonical model, orchestrates target-system calls, and returns a normalized response.
Implementation sequence
OutSystems SOAP Web Services
OutSystems supports consuming SOAP Web Services from WSDL definitions. SOAP is relevant when an OutSystems application communicates with legacy enterprise systems or exposes a SOAP-dependent service.
Martini implementation pattern
Martini integration pattern: Martini consumes the OutSystems SOAP service where available, uses the WSDL-defined operations and XML payloads, transforms the response, and routes the result to other systems or back to an OutSystems API.
Implementation sequence
OutSystems callbacks and webhook-style notifications
An OutSystems application can expose REST endpoints that function as callback or webhook receivers. Universal outbound notifications for every Entity change are not confirmed, so event coverage depends on explicit application implementation.
Martini implementation pattern
Martini integration pattern: Martini exposes a protected REST endpoint for confirmed OutSystems callbacks, validates the notification, retrieves the current application resource when necessary, and uses correlation or reconciliation logic to avoid duplicate processing.
Implementation sequence
OutSystems batch and asynchronous APIs
OutSystems applications can implement custom batch or asynchronous endpoints, but no standardized vendor-wide bulk API was confirmed. Job identifiers, status endpoints, and retry behavior are application-specific.
Martini implementation pattern
Martini integration pattern: Martini submits bounded batches or starts an asynchronous OutSystems job, stores the request and correlation identifiers, polls or receives status updates where supported, and routes completed or failed items independently.
Implementation sequence
OutSystems file and attachment exchanges
OutSystems application logic can handle files and binary data through multipart form data, binary bodies, base64 payloads, or external storage URLs, depending on the defined API contract.
Martini implementation pattern
Martini integration pattern: Martini receives or retrieves the file according to the contract, validates content type and size, transforms or routes the payload, and records transfer status without embedding binary data unnecessarily in logs.
Implementation sequence
Common OutSystems integration patterns
Pattern 1: Synchronize OutSystems Entities with Salesforce
When to use this pattern
Use this pattern when an OutSystems application manages customer or service processes while Salesforce remains authoritative for Accounts, Contacts, Leads, or Opportunities. The integration should define the source identifier, ownership rules, and conflict behavior before enabling bidirectional synchronization.
Integration direction
Example Mapping
| OutSystems Field | Canonical Field | Target Field |
|---|---|---|
| Entity.ExternalId | customer.externalId | Salesforce Account.External_Id__c |
| Entity.Name | customer.name | Salesforce Account.Name |
| Entity.Email | customer.email | Salesforce Contact.Email |
Martini implementation pattern
Martini consumes the OutSystems REST API on a schedule or through confirmed callbacks, maps application-specific Entities to a canonical customer model, validates required fields, upserts Salesforce data, and returns or stores Salesforce identifiers. Transient failures are retried with backoff, while duplicate and conflicting updates are routed for reconciliation.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- scheduled synchronization
Pattern 2: Orchestrate OutSystems processes with SAP S/4HANA
When to use this pattern
Use this pattern when OutSystems provides a user-facing process and SAP S/4HANA performs ERP processing for customers, materials, sales orders, or invoices. It is suitable for synchronous validation with asynchronous processing when SAP or the OutSystems action may take longer to complete.
Integration direction
Example Mapping
| OutSystems Field | Canonical Field | Target Field |
|---|---|---|
| Structure.CustomerCode | customer.id | SAP Business Partner |
| Structure.MaterialCode | order.lines[].productId | SAP Material |
| Structure.Quantity | order.lines[].quantity | SAP Sales Order Item Quantity |
Martini implementation pattern
Martini receives an OutSystems request, validates and enriches the payload, transforms it into the selected SAP API contract, and calls SAP. It normalizes SAP responses for OutSystems, stores correlation identifiers, and handles validation errors separately from retryable transport or dependency failures.
Martini capabilities used
- REST API exposure
- workflow orchestration
- data transformation
- validation
- business rules
- retry handling
Pattern 3: Create ServiceNow work from OutSystems callbacks
When to use this pattern
Use this pattern when an OutSystems application initiates a request or approval process and ServiceNow should track the resulting incident, request, or work item. Confirm which OutSystems business actions generate callbacks because Entity changes do not automatically imply universal event delivery.
Integration direction
Example Mapping
| OutSystems Field | Canonical Field | Target Field |
|---|---|---|
| Structure.RequestType | serviceRequest.type | ServiceNow Request Type |
| Structure.Description | serviceRequest.description | ServiceNow Short Description |
| Structure.CorrelationId | serviceRequest.sourceId | ServiceNow Correlation ID |
Martini implementation pattern
Martini exposes a protected callback endpoint, validates the OutSystems notification, retrieves additional data when required, creates or updates the ServiceNow item, and sends the resulting identifier or status back to OutSystems. Idempotency keys and correlation identifiers prevent duplicate work items.
Martini capabilities used
- REST API exposure
- webhook reception
- data mapping
- idempotency
- business rules
- error handling
Pattern 4: Scheduled reconciliation of OutSystems application data
When to use this pattern
Use this pattern when event coverage is incomplete or the application requires a reliable periodic comparison with another system. It is appropriate for incremental synchronization when the OutSystems API provides a timestamp, version, change marker, or other reconciliation field.
Integration direction
Example Mapping
| OutSystems Field | Canonical Field | Target Field |
|---|---|---|
| Entity.UpdatedAt | record.lastModifiedAt | Dynamics 365 modifiedon |
| Entity.Identifier | record.sourceId | Dynamics 365 external identifier |
| Entity.Status | record.status | Dynamics 365 statecode |
Martini implementation pattern
A scheduled Martini workflow retrieves OutSystems data page by page, preserves pagination state, maps records to the target model, and compares source identifiers or change markers. It writes updates to Dynamics 365, records checkpoints, retries transient failures, and reports items that require manual reconciliation.
Martini capabilities used
- scheduler triggers
- API consumption
- pagination handling
- mapping and transformation
- checkpointing
- monitoring
Applications commonly integrated with OutSystems
OutSystems applications commonly act as custom user experiences or process layers around established enterprise platforms. The exact integration contract remains application-specific, so Martini implementations should be based on the relevant OutSystems API definition, sample payloads, or service documentation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer, account, lead, opportunity, or service data managed by an OutSystems application with Salesforce. | OutSystems → Martini → Salesforce | Martini consumes the OutSystems REST API, maps application Entities or Structures to Salesforce API payloads, applies validation and deduplication rules, and retries transient failures. |
| SAP S/4HANA | Connect custom OutSystems processes and user experiences with SAP master data and transactions such as customers, materials, sales orders, or invoices. | OutSystems → Martini → SAP S/4HANA | Martini validates the OutSystems request, transforms it into the selected SAP API contract, orchestrates the call, and returns normalized status or error information to OutSystems. |
| ServiceNow | Create and update incidents, requests, approvals, or service-process data initiated by OutSystems applications. | OutSystems → Martini → ServiceNow | Martini receives an OutSystems API request or callback, maps it to ServiceNow fields, stores correlation details, and sends status updates back through the OutSystems API. |
| Microsoft Dynamics 365 | Coordinate custom OutSystems applications with Dynamics 365 customer, sales, and service data. | OutSystems → Martini → Microsoft Dynamics 365 | Martini mediates REST-based calls, maps application-specific Entities to Dynamics 365 payloads, and applies idempotency, retry, and reconciliation rules. |
| Workday | Exchange worker, organizational, or business-process data between Workday and an OutSystems application. | Workday → Martini → OutSystems | Martini retrieves or receives Workday data, transforms it into the OutSystems Structures expected by the application, validates required fields, and records synchronization state. |
| Jira | Create and synchronize issues, work items, and delivery status from OutSystems business applications. | OutSystems → Martini → Jira | Martini receives an OutSystems request, maps it to Jira fields, records the Jira identifier, and returns status or failure details to the originating application. |
| Microsoft Entra ID | Use centralized identity and authorization for OutSystems applications and integration endpoints. | Microsoft Entra ID → Martini → OutSystems | Martini coordinates token-based authentication and protected API calls while keeping client credentials, tokens, and environment-specific settings in secure configuration. |
| Oracle Database | Connect OutSystems workflows with Oracle data and enterprise processes where API-based integration or controlled database access is required. | OutSystems → Martini → Oracle Database | Martini prefers the OutSystems API contract, but can orchestrate controlled database operations where the deployment and ownership model support them, with transaction and schema boundaries explicitly defined. |
How to build a OutSystems integration in Martini
Objective
Establish the API or service contract and configure environment-specific authentication without embedding credentials in workflow logic.
Instructions in Martini
- Confirm the OutSystems REST or SOAP endpoint, WSDL, API definition, sample payloads, and application owner.
- Configure OAuth 2.0, Basic Authentication, API keys, bearer tokens, custom headers, or certificates as required.
- Store credentials and endpoint settings in secure environment-specific configuration.
Objective
Select the event, callback, API request, or schedule that starts the integration based on the OutSystems application's actual capabilities.
Instructions in Martini
- Use a Martini REST API when OutSystems initiates the process.
- Receive only confirmed callback or webhook-style notifications at a protected endpoint.
- Use a scheduler when event coverage is incomplete or reconciliation is required.
Objective
Receive the OutSystems payload or retrieve the current resource needed to complete processing reliably.
Instructions in Martini
- Validate callback signatures, correlation identifiers, and required request fields where applicable.
- Retrieve the current Entity or Structure when a notification contains only a reference.
- Implement the application's pagination and checkpoint behavior for scheduled reads.
Objective
Coordinate OutSystems with downstream applications while keeping transport, business, and dependency concerns separate.
Instructions in Martini
- Route the request through a Martini workflow.
- Call target APIs or services in the required order.
- Use correlation identifiers and bounded concurrency for long-running or batch operations.
Objective
Convert application-specific OutSystems Entities and Structures into canonical and target-system payloads.
Instructions in Martini
- Map only fields confirmed by the OutSystems API contract.
- Transform JSON, XML, file, and binary representations according to the endpoint requirements.
- Normalize identifiers, dates, statuses, and nested structures before writing the target payload.
Objective
Enforce validation, ownership, deduplication, and idempotency rules before committing changes.
Instructions in Martini
- Validate required fields and business constraints.
- Define source identifiers, upsert behavior, and duplicate handling.
- Separate non-retryable validation or business errors from transient failures.
Common OutSystems data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Applications | Deployable OutSystems solutions containing user interfaces, business logic, data models, and integration definitions. | Martini, Salesforce, SAP S/4HANA, ServiceNow, Microsoft Dynamics 365 | Martini treats the application as the owning context for endpoint contracts and coordinates calls without assuming standardized business objects. |
| Modules | Reusable Service, Web, or Mobile components containing implementation logic and integration definitions. | OutSystems applications, Martini APIs and workflows | Martini integrates with the APIs or callbacks exposed by the relevant module and records module-specific contract and version information. |
| Entities | Application data-model objects used to persist business data, with exposure determined by the application design. | Salesforce, SAP S/4HANA, ServiceNow, databases | Martini maps Entities only from the confirmed application API contract and applies identifiers, validation, deduplication, and reconciliation rules. |
| Structures | Typed request and response structures used for payloads, mappings, and service contracts. | REST APIs, SOAP services, enterprise applications | Martini transforms Structures into canonical or target payloads, validates required fields, and handles schema differences. |
| REST APIs | Application-specific methods for retrieving, creating, updating, or processing data over HTTP. | Martini, Salesforce, SAP S/4HANA, ServiceNow, Microsoft Dynamics 365 | Martini consumes or exposes the API, configures authentication, manages pagination and retries, and orchestrates downstream actions. |
| SOAP Web Services | WSDL-based operations used when an OutSystems application communicates with legacy or SOAP-dependent systems. | Martini and legacy enterprise platforms | Martini consumes the service definition, maps XML requests and responses, and separates transport, validation, and business errors. |
Authentication and security considerations
Application-specific authentication
OutSystems integrations may use OAuth 2.0, Basic Authentication, API keys, bearer or JWT-style tokens, custom headers, and client certificates where supported. The exact method depends on whether OutSystems is consuming or exposing the service.
Secure configuration
Store credentials, tokens, client secrets, API keys, certificates, scopes, audiences, and environment-specific URLs in secure configuration rather than workflow mappings or payloads.
API protection
Protect Martini APIs and callback endpoints with appropriate authentication and authorization. Confirm token lifetime, refresh behavior, required scopes, and custom headers with the OutSystems application owner.
Operational considerations for OutSystems integrations
Contracts and schema changes
OutSystems applications define their own Entities, Structures, methods, and response types. Obtain the current API definition and establish versioning, change notification, backward compatibility, and contract testing practices.
Pagination and throttling
Confirm whether pagination uses page parameters, offsets, cursors, or a custom response structure. Use bounded concurrency and exponential backoff for throttling, including HTTP 429 responses or infrastructure-specific limits.
Idempotency and retries
Define source identifiers, correlation IDs, upsert behavior, or Martini-side state tracking before retrying create or update operations. Do not blindly retry non-idempotent requests when the first response is unknown.
Long-running and asynchronous work
Prefer job identifiers and status endpoints for unpredictable processing times where the application supports them. Separate transport errors, authentication failures, validation errors, business-rule failures, and downstream dependency errors.
Files and environments
Confirm whether files use multipart content, binary bodies, base64 values, or external URLs. Use separate endpoints, credentials, and configuration for development, test, and production environments.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration across systems
Martini provides a workflow layer between OutSystems and enterprise applications, allowing teams to coordinate API calls, callbacks, files, databases, and messaging without embedding every dependency in the OutSystems application.
Reusable transformation and rules
Mappings, validation, canonical models, routing rules, idempotency, and enrichment can be maintained as reusable integration assets rather than duplicated across point-to-point implementations.
Operational control
Martini workflows provide a consistent place to manage authentication, retries, error classification, logging, monitoring, reconciliation, and environment-specific deployment configuration.
API-led flexibility
Martini can consume OutSystems REST or SOAP services and expose controlled APIs for OutSystems applications to call. This supports an API-led architecture without requiring a dedicated vendor connector.
Frequently asked questions
OutSystems integrates primarily through application-defined REST APIs that can consume external services or expose endpoints for other systems. It also supports WSDL-based SOAP Web Services, application-specific callback endpoints, and file or binary API contracts. Authentication may use OAuth 2.0, Basic Authentication, API keys, bearer tokens, custom headers, or certificates depending on the implementation.
Yes. Martini can consume REST APIs exposed by OutSystems, consume SOAP services where applicable, receive callbacks through exposed REST endpoints, and expose REST APIs for OutSystems applications to call. Martini can then orchestrate workflows, transform payloads, apply business rules, and integrate with other enterprise systems.
No. A dedicated OutSystems connector is not required. Martini can use OutSystems' confirmed native integration mechanisms, including REST APIs, SOAP Web Services, application-specific callbacks, file contracts, and the authentication methods configured for those endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate OutSystems. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from OutSystems, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs are the primary recommended mechanism for new integrations because OutSystems applications can expose and consume application-specific REST contracts. SOAP is appropriate for legacy services, while callbacks, batch endpoints, and file exchanges should be used only when explicitly implemented and documented by the application.
OutSystems applications can expose REST endpoints that act as webhook receivers or callback endpoints, but universal outbound notifications for every Entity change are not confirmed. Event coverage, delivery behavior, replay, and retry support depend on the specific application implementation and selected business events.
Martini can synchronize OutSystems data through callbacks, API-led requests, or scheduled workflows. Scheduled synchronization can paginate through REST results and preserve checkpoints, while reliable incremental processing requires an application-supported timestamp, version, change marker, or reconciliation strategy.
Martini maps application-specific Entities and Structures into canonical and target-system models, applies validation and business rules, and distinguishes authentication, transport, validation, business, and downstream errors. Retryable failures can use bounded retries and backoff, while idempotency keys, source identifiers, correlation IDs, and checkpoints help prevent duplicate processing.
Related Martini documentation
Workflows
Transformation
Integrate OutSystems with Martini
Use Martini to connect application-specific OutSystems APIs and services with the rest of your enterprise landscape through secure, maintainable workflows.