Infor M3 API Integration with MI Programs and REST
Infor M3 exposes its business logic through MI programs, API interfaces named after the program they front, such as MMS200MI for items, OIS100MI for customer orders, CRS610MI for customers, and PPS200MI for purchase orders. Each MI program offers named transactions that add, change, delete, get, and list records while enforcing the same validation as the interactive screens. You reach them through a REST facade, through the ION API Gateway with OAuth, or through the older toolkit connections. This guide covers selecting transactions, authenticating, handling errors, and designing interfaces that survive upgrades.
How MI Programs and Transactions Are Structured
MI transaction names follow strong conventions. Get transactions return one record for a full key, Lst transactions return a filtered set, Add and Upd create and change records, and Del removes them. Inputs and outputs use the same short field names as the underlying M3 tables, so ITNO is the item number and CONO the company. Every MI program publishes metadata describing its transactions, fields, lengths, and mandatory flags, and you should read that metadata rather than guessing from documentation that may lag your release. Generic helpers exist too, including a metadata-driven read interface for straightforward table extracts and an interface for triggering standard M3 export jobs.
- Pull transaction metadata from the target MI program first and generate your data contract from it
- Prefer a Get transaction over a Lst transaction whenever you have the complete key
- Always pass a maximum record limit on list transactions; unbounded lists are the most common M3 API performance incident
- Map field lengths exactly, because M3 will truncate silently rather than reject an oversized value
REST, the ION API Gateway, and Authentication
Modern M3 integrations call the REST facade over MI, where a request identifies the program and transaction in the path and passes input fields as query parameters or a JSON body. In CloudSuite, calls go through the ION API Gateway using OAuth 2.0 credentials issued as a downloadable credentials file containing the client ID, client secret, and token endpoint for your tenant. Your integration exchanges those for a bearer token, caches it until expiry, and refreshes before it lapses. On-premises landscapes may still use direct connections or the older API toolkit, but building against the gateway pattern now removes rework when you move to cloud.
- Store the tenant credentials file in a secret manager, never in source control or an integration config table
- Cache and proactively refresh bearer tokens instead of requesting one per call
- Use a dedicated integration user per interface so audit trails and throttling are attributable
- Set explicit connect and read timeouts; a hung M3 session will otherwise stall the calling queue
Event Hub, MEC, and ION for Outbound Integration
Polling M3 for changes is the wrong default. Event Hub publishes business engine events when records are created, updated, or deleted, and a subscriber can filter to specific tables and operations, for example only updates to the item master or new customer order lines. M3 Enterprise Collaborator handles partner messaging: EDI translation, flat file mapping, and document generation with retry and error queues. ION carries standardized business object documents between M3 and other applications, which is the intended pattern for Infor-to-Infor and for many third-party connectors. Choose Event Hub for near real-time internal triggers, MEC for trading partner formats, and ION for application-to-application document flows.
Error Handling, Throttling, and Interface Design
MI transactions return structured error information rather than exceptions, so your client must inspect every response even when the HTTP status is 200. Build idempotency into every write: record the external reference on the M3 record so a retry can detect that the order already exists instead of creating a duplicate. Batch sensibly, because thousands of single-record calls per minute will saturate API nodes long before the database becomes a problem. Log the full request and response for writes, keep a dead letter queue for failed messages with the business key attached, and give support staff a replay path that does not require a developer.
How Netray Builds and Governs M3 Interfaces
Netray AI agents read MI metadata and generate typed client code, validation, and test fixtures for a target transaction in minutes, which typically cuts integration build effort by forty to sixty percent against hand-coding. A second agent monitors production API traffic and flags unbounded list calls, retry storms, credential expiry risk, and interfaces that would break on the next CloudSuite update. Every generated interface ships with idempotency keys, structured logging, and a replay path by default. For defense and regulated manufacturers, the same agents run entirely inside your network so no M3 payloads leave the environment. Your team keeps the generated code with no runtime dependency on us.
Frequently Asked Questions
What is an MI program in Infor M3?
An MI program is M3's API interface for a business program. Its name is the program name plus MI, so MMS200MI serves item data and OIS100MI serves customer orders. Each MI program exposes named transactions for adding, updating, deleting, retrieving, and listing records, and those transactions run the same validation and business logic as the interactive screens. Using MI transactions is the supported way to write data into M3 from any external system.
How do I authenticate to the Infor M3 REST API in CloudSuite?
CloudSuite M3 API calls go through the ION API Gateway using OAuth 2.0. You create an authorized application in the gateway and download a credentials file containing the client identifier, secret, and token endpoint for your tenant. Your integration requests a bearer token from that endpoint, caches it until shortly before expiry, and includes it on each API call. Store the credentials file in a secret manager and use a distinct integration user per interface.
Should I use Event Hub or polling to detect M3 changes?
Use Event Hub. It publishes events when the business engine creates, updates, or deletes records, and subscribers can filter to specific tables and operations, which gives near real-time notification without repeatedly querying M3. Polling adds constant load, introduces latency equal to the poll interval, and often misses intermediate states. Reserve polling for external systems that cannot receive events, and even then poll a change-tracking view rather than scanning full tables.
Key Takeaways
- 1How MI Programs and Transactions Are Structured: MI transaction names follow strong conventions. Get transactions return one record for a full key, Lst transactions return a filtered set, Add and Upd create and change records, and Del removes them.
- 2REST, the ION API Gateway, and Authentication: Modern M3 integrations call the REST facade over MI, where a request identifies the program and transaction in the path and passes input fields as query parameters or a JSON body. In CloudSuite, calls go through the ION API Gateway using OAuth 2.0 credentials issued as a downloadable credentials file containing the client ID, client secret, and token endpoint for your tenant.
- 3Event Hub, MEC, and ION for Outbound Integration: Polling M3 for changes is the wrong default. Event Hub publishes business engine events when records are created, updated, or deleted, and a subscriber can filter to specific tables and operations, for example only updates to the item master or new customer order lines.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
CapEx Payback and NPV Calculator
Build the payback period, net present value, and lifetime ROI numbers your capital approval request needs for equipment, automation, or ERP investments.
Free ToolERP Disaster Recovery Readiness Assessment
Ten questions on backups, RTO/RPO, restore testing, and failover that score whether your ERP would survive ransomware or a hardware failure.
Free ToolLegacy Report Modernization Calculator
Estimate what it costs to rebuild your actively used legacy reports on a modern platform, what retiring the rest saves, and how fast it pays back.
Building or rescuing M3 interfaces? Netray can generate, harden, and monitor your MI API integrations with AI agents that read your actual transaction metadata.
Related Resources
Infor M3 Technical Architecture: A Practical Guide
Infor M3 technical architecture explained: M3 Business Engine, Infor Grid, database tables, H5 client, and integration layers for on-prem and CloudSuite teams.
Infor M3Infor M3 H5 Client: Personalization and Scripting
Infor M3 H5 client guide: personalization, JavaScript scripting, bookmarks, and deployment patterns that cut clicks per transaction without MAK modifications.
Infor M3Infor M3 Upgrade and CloudSuite Migration
Infor M3 upgrade and CloudSuite migration guide: modification inventory, extensibility rework, data strategy, testing waves, and 9 to 18 month timelines.