.png)
Infor M3 Integration Guide
Integrate Infor M3 with enterprise applications through M3 REST APIs, Infor OS API Gateway, ION API, configured events, files, and scheduled workflows.
Infor M3 integration options at a glance
Infor M3 integrations are primarily built with M3 REST APIs exposed through the Infor OS API Gateway or ION API. OAuth 2.0, client credentials, API access policies, tenant configuration, and M3 permissions control access. Selected M3 application events can participate in ION event-driven workflows, although event coverage and payloads depend on the environment. File exchange and batch processing may support migration, EDI, or high-volume operations, while older SOAP-style interfaces may exist in some deployments. Martini can authenticate securely, call M3 transactions, receive configured event notifications, schedule incremental synchronization, transform JSON or file data, and expose controlled APIs for downstream applications.
| Integration point | Supported by Infor M3? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs through Infor OS API Gateway or ION API | Yes | Use M3 transaction APIs for Customers, Items, orders, suppliers, inventory, shipments, and other configured program-level operations. Available transactions depend on the M3 release, modules, and API configuration. | Martini can obtain OAuth 2.0 tokens, call configured M3 endpoints, transform responses, apply business rules, and write results to downstream applications or expose them through a Martini API. |
| Authentication and API access policies | Yes | Infor OS and ION API use OAuth 2.0, commonly with client credentials for service-to-service integrations. Tenant, API policy, application authorization, and M3 permissions control access. | Martini can keep client credentials, tokens, endpoints, and environment values in protected configuration and use authenticated API workflows with controlled authorization. |
| Events and ION workflows | Limited | Selected M3 application events can initiate ION workflows or deliver event-style notifications. Coverage, payload completeness, delivery, and retry behavior are event-specific. | Martini can receive configured event or callback traffic, retrieve the authoritative M3 object when an event contains only an identifier, and handle duplicates, ordering, and transient failures. |
| File exchange and document flows | Limited | Files may support bulk exchange, migration, EDI, reporting, or legacy processes through ION, file services, managed transfer, or customer-specific endpoints. | Martini can orchestrate file-based workflows, parse and transform approved file formats, validate rows, and route rejected or incomplete files for correction. |
| Bulk, asynchronous, or batch processing | Limited | Some M3 transactions and surrounding ION or file processes support batch-style work, but there is no confirmed generic bulk API for every M3 object. | Martini can use scheduled workflows, pagination, controlled concurrency, incremental selection, and batch-oriented paths where the specific M3 API supports them. |
| SOAP and older web-service interfaces | Legacy | Some older M3 or surrounding Infor deployments may expose web-service-style interfaces. REST through Infor OS API Gateway or ION API is the preferred starting point for new integrations. | Where a customer confirms an available SOAP interface, Martini can consume it using a standards-based SOAP workflow, while keeping the interface isolated for future migration. |
| File and attachment handling | Limited | Document and attachment handling may be available through Infor OS, ION, or configured M3 processes, but exact APIs vary by module and environment. | Martini can move approved files or document payloads, map metadata, validate content, and connect file processing to the related M3 business transaction. |
| Direct database access | Not confirmed | Direct database integration is not a preferred general-purpose M3 boundary because it can bypass M3 authorization, validation, business rules, and transaction processing. | Martini can connect to approved databases where the architecture explicitly permits it, but M3 APIs, ION services, events, and approved exports should generally be preferred. |
How Infor M3 exposes data and business events
Infor M3 REST APIs
M3 REST APIs are the principal integration mechanism and commonly expose transactions corresponding to M3 programs and panels through the Infor OS API Gateway or ION API. Exact operations, fields, company context, and permissions depend on the customer environment.
Martini implementation pattern
Martini implementation pattern: Martini obtains an OAuth 2.0 token, calls the configured M3 transaction, validates the response, maps it to a canonical or target schema, and orchestrates downstream writes or API responses.
Implementation sequence
Infor ION application events
M3 can participate in event-driven processing through Infor ION application events and workflows. Event availability is configuration-dependent, and an event may contain a full payload or only an identifier.
Martini implementation pattern
Martini implementation pattern: Martini receives the configured event or callback, deduplicates it, retrieves current M3 state when necessary, retries transient availability failures, and routes the normalized result to downstream systems.
Implementation sequence
Infor M3 file and batch processing
Infor environments may use ION document flows, file services, managed file transfer, or customer-specific endpoints for bulk exchange, migration, EDI, reporting, and legacy processes. Availability is environment-specific.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves an approved file, validates its structure and business content, processes rows in controlled batches, and produces an auditable result with rejected items separated from successful work.
Implementation sequence
Legacy Infor M3 SOAP interfaces
Some older M3 or surrounding Infor deployments may expose SOAP or web-service-style interfaces. These interfaces require confirmation for the specific release and deployment model and are not the preferred starting point for new work.
Martini implementation pattern
Martini implementation pattern: Where a confirmed SOAP interface is required, Martini consumes the service, maps XML request and response structures, applies the same validation and retry controls, and keeps the legacy boundary isolated from the rest of the workflow.
Implementation sequence
Common Infor M3 integration patterns
Pattern 1: Synchronize Customers and Items to downstream applications
When to use this pattern
Use this pattern when M3 is the source of truth for customer or product master data and downstream applications require consistent, incrementally updated values. A scheduled API extraction can be combined with event processing and reconciliation.
Integration direction
Example Mapping
| Infor M3 Field | Canonical Field | Target Field |
|---|---|---|
| Customer number | customer.externalId | Account.externalId |
| Customer name | customer.name | Account.name |
| Item number | product.externalId | Product.productCode |
| Unit of measure | product.unitOfMeasure | Product.unitOfMeasure |
Martini implementation pattern
Martini runs a scheduled or event-triggered workflow, retrieves pages of M3 Customers or Items, applies change-date and eligibility rules where supported, maps the payload to a canonical model, and performs idempotent target upserts. Invalid records are isolated, transient failures are retried with backoff, and a reconciliation path identifies missed changes.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- pagination
- error handling
Pattern 2: Synchronize customer order status
When to use this pattern
Use this pattern when a commerce, CRM, portal, or service application needs current M3 order lifecycle information. ION events can provide a near-real-time trigger, while scheduled API queries provide a fallback and reconciliation mechanism.
Integration direction
Example Mapping
| Infor M3 Field | Canonical Field | Target Field |
|---|---|---|
| Order number | order.externalId | Order.orderNumber |
| Order status | order.status | Order.fulfillmentStatus |
| Allocation status | order.allocationStatus | Order.allocationStatus |
| Delivery date | order.deliveryDate | Order.expectedDeliveryDate |
Martini implementation pattern
Martini receives a configured ION notification or polls M3, retrieves the current Customer order and related lines, translates M3 lifecycle states into target states, and publishes only meaningful changes. Because events may precede data availability or arrive more than once, the workflow uses correlation keys, delayed retries, and idempotent updates.
Martini capabilities used
- event-driven workflows
- scheduled workflows
- API consumption
- state mapping
- business rules
- retry handling
Pattern 3: Exchange purchase orders with supply chain applications
When to use this pattern
Use this pattern when M3 purchase orders and Suppliers must be exchanged with Infor Nexus, SAP S/4HANA, NetSuite, or another approved procurement endpoint. It supports both outbound purchase order distribution and inbound acknowledgements or receipts where the required M3 transactions exist.
Integration direction
Example Mapping
| Infor M3 Field | Canonical Field | Target Field |
|---|---|---|
| Purchase order number | purchaseOrder.externalId | PurchaseOrder.orderNumber |
| Supplier number | supplier.externalId | TradingPartner.supplierId |
| Requested delivery date | purchaseOrder.requestedDate | PurchaseOrder.requestedDeliveryDate |
| Receipt status | purchaseOrder.receiptStatus | PurchaseOrder.receiptStatus |
Martini implementation pattern
Martini retrieves or receives M3 Purchase Orders, validates supplier and company context, transforms headers and lines into the target model, and sends the result through the target API or approved file route. Responses are correlated to the source transaction, while validation errors are quarantined and transport failures follow bounded retries.
Martini capabilities used
- workflow orchestration
- API consumption
- file processing
- data mapping
- validation
- error handling
Pattern 4: Synchronize inventory and fulfillment information
When to use this pattern
Use this pattern when a commerce platform, warehouse application, or customer-facing service needs M3 inventory, warehouse, shipment, or fulfillment information. The design should explicitly define whether the target receives balances, reservations, movements, or availability.
Integration direction
Example Mapping
| Infor M3 Field | Canonical Field | Target Field |
|---|---|---|
| Item number | inventory.itemId | InventoryItem.sku |
| Facility | inventory.facilityId | Inventory.facilityCode |
| Warehouse | inventory.warehouseId | Inventory.locationCode |
| Available quantity | inventory.availableQuantity | Inventory.available |
Martini implementation pattern
Martini calls the relevant M3 item, facility, warehouse, inventory, or shipment transactions on an event or controlled schedule, normalizes quantities and location context, applies source-of-truth rules, and publishes updates. Reconciliation workflows detect missed events, negative adjustments, stale values, and target write failures.
Martini capabilities used
- scheduled workflows
- API consumption
- data transformation
- business rules
- reconciliation
- monitoring
Applications commonly integrated with Infor M3
Infor M3 commonly participates in enterprise landscapes that include supply chain, warehouse, customer-facing, finance, service, and analytics applications. The exact ownership of business objects and integration direction should be confirmed for each deployment.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Infor WMS | Exchange items, facilities, inventory, shipments, warehouse activities, and fulfillment status between M3 and warehouse operations. | Infor M3 → Martini → Infor WMS | Martini can consume M3 APIs and WMS APIs, normalize item and order identifiers, apply warehouse and facility rules, and route execution updates back to the owning system. |
| Infor Nexus | Coordinate supplier, order, shipment, logistics, and trading-partner information across the supply chain. | Infor M3 → Martini → Infor Nexus | A Martini workflow can retrieve M3 purchase and shipment data, map it to the required Nexus model, process acknowledgements or status updates, and isolate retryable transport failures from business validation errors. |
| Salesforce | Synchronize customer context, product information, customer orders, fulfillment status, and service-facing updates. | Infor M3 → Martini → Salesforce | Martini can use scheduled or event-triggered M3 reads, map Customers, Items, and Customer orders to Salesforce objects, and apply explicit ownership rules before sending status or customer updates. |
| ServiceNow | Provide operational, asset, order, fulfillment, or equipment context to service and support processes. | Infor M3 → Martini → ServiceNow | Martini can consume selected M3 events or scheduled extracts, validate the business context, create or update ServiceNow records, and return selected workflow outcomes to M3 where supported. |
| SAP S/4HANA | Coordinate finance, procurement, supply chain, or corporate master data where M3 and SAP operate together. | Infor M3 → Martini → SAP S/4HANA | Martini can provide a canonical mapping layer between M3 transactions and SAP APIs or approved interfaces, with domain-specific routing, correlation identifiers, and reconciliation workflows. |
| Oracle NetSuite | Exchange customers, products, orders, invoices, and financial information in organizations operating both platforms. | Infor M3 → Martini → Oracle NetSuite | A Martini workflow can retrieve or receive M3 business changes, transform them into NetSuite API payloads, enforce domain ownership, and record source and target identifiers for idempotent updates. |
| Shopify | Receive commerce orders and publish product availability, inventory, fulfillment, and status information. | Shopify → Martini → Infor M3 | Martini can receive Shopify order events or poll APIs, validate customer and item mappings, submit supported M3 order transactions, and publish fulfillment or inventory updates back to Shopify. |
| Microsoft Power BI | Supply curated M3 operational, inventory, order, and finance data for reporting and analytics. | Infor M3 → Martini → Microsoft Power BI | Martini can extract approved M3 API or file data, normalize it into an analytics-ready model, store or publish it through an approved data service, and run scheduled reconciliation. |
How to build a Infor M3 integration in Martini
Objective
Establish the M3 integration boundary through the customer’s Infor OS API Gateway or ION API configuration and confirm the exact tenant, environment, transactions, and permissions.
Instructions in Martini
- Configure the M3 endpoint and tenant-specific values in protected Martini configuration.
- Use OAuth 2.0 client credentials where the integration runs service to service.
- Confirm API policies, M3 permissions, company, division, facility, and warehouse context.
- Keep secrets and tokens out of mappings, payloads, and logs.
Objective
Select an event, callback, schedule, or approved file intake based on the required latency, event coverage, volume, and M3 transaction behavior.
Instructions in Martini
- Use configured ION events only for verified business events.
- Use a scheduled workflow when events are unavailable or reconciliation is required.
- Define polling windows, change indicators, pagination, and concurrency limits.
- Treat file and batch mechanisms as environment-specific.
Objective
Receive the event or file and retrieve the authoritative M3 object when the notification contains only a key, status, or incomplete payload.
Instructions in Martini
- Validate the incoming event, callback, or file before processing.
- Call the specific M3 transaction required for the business object.
- Use pagination or continuation mechanisms documented for that transaction.
- Retry transient not-yet-available and network failures with bounded backoff.
Objective
Build the Martini workflow that coordinates M3 calls, target calls, state handling, business rules, and failure paths as a maintainable integration asset.
Instructions in Martini
- Separate transport, validation, transformation, and business processing stages.
- Store correlation identifiers and processing state.
- Route permanent validation failures to an operational correction path.
- Use reusable workflow logic for shared authentication, mapping, and error handling.
Objective
Convert M3 program- and transaction-oriented payloads into a canonical model or target-specific schema while preserving business context.
Instructions in Martini
- Map M3 identifiers, company, division, facility, and warehouse values explicitly.
- Transform dates, quantities, units of measure, statuses, and nested order lines.
- Preserve source identifiers for idempotent updates and reconciliation.
- Validate required fields before sending downstream requests.
Objective
Apply ownership, eligibility, lifecycle, and retry rules so that M3 business semantics are not reduced to simple field copying.
Instructions in Martini
- Distinguish order creation, allocation, shipment, invoicing, cancellation, and completion.
- Separate warnings, business validation errors, duplicates, and transport failures.
- Prevent repeated processing through deterministic keys and durable state.
- Define which system owns each customer, item, order, inventory, and status field.
Common Infor M3 data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Customers | Synchronize customer master data, addresses, payment terms, credit information, and sales settings; commonly associated with CRS610. | Salesforce, Shopify, Oracle NetSuite, SAP S/4HANA, data platforms | Martini retrieves or receives customer changes, applies company and division context, maps stable M3 identifiers, and performs validated idempotent upserts. |
| Suppliers | Exchange supplier master data, purchasing terms, addresses, and supplier-specific settings; commonly associated with CRS620. | Infor Nexus, SAP S/4HANA, Oracle NetSuite, procurement applications | Martini maps supplier identifiers and terms, validates required fields, routes business errors for correction, and records source-to-target correlation. |
| Items | Synchronize product descriptions, units of measure, item groups, and planning attributes; commonly associated with MMS200. | Infor WMS, Shopify, Salesforce, Microsoft Power BI, data platforms | Martini transforms item and unit models, applies publication or eligibility rules, and isolates invalid items without stopping the full synchronization. |
| Facilities and warehouses | Exchange item, inventory, planning, replenishment, and logistical attributes by facility or warehouse. | Infor WMS, Shopify, supply chain applications, data platforms | Martini preserves facility and warehouse context in mappings and uses configured ownership rules when reconciling location-specific values. |
| Customer orders | Process sales order headers, lines, delivery details, pricing, allocation, and fulfillment status; commonly associated with OIS100 and OIS101. | Shopify, Salesforce, Infor WMS, customer portals, Oracle NetSuite | Martini validates customer and item references, maps line-level data, distinguishes order lifecycle states, and uses correlation keys and retry rules for writes. |
| Purchase orders | Exchange purchase order headers, lines, supplier information, delivery dates, and receipt status; commonly associated with PPS200 and PPS201. | Infor Nexus, SAP S/4HANA, Oracle NetSuite, supplier applications | Martini transforms purchase order and supplier data, applies approval and ownership rules, and supports acknowledgement, receipt, and reconciliation flows where transactions are available. |
Authentication and security considerations
OAuth 2.0 and client credentials
Infor OS API Gateway and ION API commonly use OAuth 2.0, with client credentials suited to service-to-service integrations. API access policies and authorized applications must be configured in the customer’s Infor environment.
Tenant and M3 permissions
Endpoints, credentials, API subscriptions, companies, divisions, facilities, warehouses, programs, transactions, and data permissions are environment-specific. Martini workflows should make this context explicit rather than embedding assumptions.
Protected configuration
- Store client IDs, client secrets, tokens, and endpoint values in protected Martini configuration.
- Use least-privilege access for M3 and Infor OS identities.
- Avoid logging customer, supplier, pricing, financial, and authentication data unnecessarily.
Operational considerations for Infor M3 integrations
Pagination and load
M3 transactions may return large result sets. Use the pagination or continuation mechanism for the specific API, controlled concurrency, and schedules appropriate to the customer environment. Do not assume a generic rate limit.
Events and consistency
ION events may contain only identifiers or may arrive before related M3 data is available. Retrieve authoritative state, retry transient availability failures, and handle duplicates, out-of-order delivery, and changes between publication and retrieval.
Idempotency and retries
Use stable M3 identifiers and deterministic upsert rules. Retry network, gateway, and temporary service failures with bounded backoff, but route M3 validation errors, duplicates, and business warnings according to explicit handling rules.
Schema and environment differences
M3 releases, installed modules, API configurations, and customer extensions can change available fields and transactions. Test mappings against each target environment and preserve company, division, facility, and warehouse context.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond scripts
Martini provides a maintainable workflow layer for M3 API calls, ION event handling, scheduled synchronization, target-system writes, business rules, and reconciliation rather than scattering logic across one-off scripts.
Reusable integration assets
Teams can reuse authentication, mappings, transformations, validation, error paths, and API façade patterns across Customers, Items, orders, suppliers, inventory, and fulfillment flows.
Operational control
Martini separates transient failures from business errors, supports controlled retries and idempotent processing, and provides workflow monitoring and troubleshooting capabilities for integrations that must remain reliable as M3 environments evolve.
Frequently asked questions
Infor M3 is commonly integrated through M3 REST APIs exposed by the Infor OS API Gateway or ION API. Organizations can also use selected ION application events and workflows, scheduled API synchronization, approved file or batch processes, and legacy web-service interfaces where confirmed. OAuth 2.0, API policies, tenant configuration, and M3 permissions govern access.
Yes. Martini can consume Infor M3 REST APIs through Infor OS API Gateway or ION API, authenticate using the customer’s OAuth 2.0 configuration, receive configured event or callback traffic, run scheduled synchronization, transform M3 data, and orchestrate downstream applications. No native Martini connector is established in the supplied research.
No. A dedicated Infor M3 connector is not required. Martini can use M3’s confirmed native integration mechanisms, including REST APIs through Infor OS or ION API, configured ION events, approved files, and supported authentication methods.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Infor M3. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Infor, infrastructure providers, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs exposed through the Infor OS API Gateway or ION API are the preferred starting point for new API-led integrations. ION application events can support selected event-driven scenarios, while scheduled workflows and approved file or batch processes may be appropriate for reconciliation or large-volume exchange. SOAP should generally be treated as a legacy option requiring environment confirmation.
M3 can participate in event-driven processing through Infor ION application events and workflows, but it should not be described as providing a webhook for every object or transaction. Event availability, payload completeness, delivery method, retries, and ordering depend on the M3 release, enabled modules, and customer configuration.
Martini can run scheduled workflows or respond to configured events, call the relevant M3 transaction, paginate results, map data into a canonical or target model, and perform idempotent writes. Important flows should combine event processing with scheduled reconciliation to identify missed events, failed messages, and status mismatches.
Yes. Martini can expose a controlled REST API that abstracts M3 transactions from downstream applications. The façade can authenticate callers, validate and transform requests, apply business rules, invoke the appropriate M3 API through Infor OS or ION API, and return a governed response without exposing internal M3 details.
Related Martini documentation
APIs
Transformation
Plan your Infor M3 integration
Use Martini to connect Infor M3 APIs, ION events, scheduled workflows, files, and downstream enterprise applications through a controlled and maintainable integration layer.