Infor M3 & CloudSuiteFree checklistPDF, Excel, Word exportInfor M3All Infor M3 tools

Infor M3 MI API and ION API Gateway Security Checklist

This checklist secures integrations into an on-prem Infor M3 13.x system that use MI programs, either directly through the m3api-rest endpoint or through the ION API gateway. It covers accounts, authorization, transport, monitoring and lifecycle.

0%

0 of 26 items complete

8 critical items still open - these are the highest-risk gaps.

Download checklist:

Accounts

Authorization

Transport

Monitoring

Lifecycle

The critical items close the gaps most often found in M3 integration reviews: shared accounts, open API authority, broad table-read programs and secrets in files. Treat any unchecked critical item as an open risk with an owner and date.

Get your M3 integration accounts reviewed

Send us a list of integrations, their M3 users and the MI programs they call and we will flag over-broad access and missing controls.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

Where M3 API security lives

Every MI call runs as an M3 user, defined in MNS150. That user's roles (MNS405, connected in MNS410) and function security (SES400) apply, and API access can be restricted per API program and transaction in Function. Connect API Authorization (SES005). By default, users can reach every API program and transaction, so without SES005 entries an integration account can call far more than it needs. All API programs restrict users to the companies they have access to, and some apply field, facility or warehouse restrictions on top. The ION API gateway adds OAuth 2.0 clients defined in ION API, whose credentials are distributed as .ionapi files.

  • MNS150: user
  • MNS405 / MNS410: roles and user-role connection
  • SES400: function authority by role
  • SES005: API authority by program and transaction

Why EXPORTMI and MDBREADMI deserve attention

EXPORTMI and MDBREADMI are generic MI programs that read M3 table data, which makes them convenient for reporting and lookups and also the easiest way for an integration account to read much more than its purpose. Treat them as privileged. Grant them only to accounts with a reviewed need, prefer specific MI programs such as MMS200MI or OIS100MI transactions where they exist, and alert on unusual use. Remember that hiding a button in a client is usability, not security: the backend authority is what stops a call.

How to use it

Start with the inventory: list every integration, its M3 user, its ION API client if any, and the MI programs it calls. Then go through the groups with the M3 administrator and the integration owner. For Authorization, test with the integration user itself by calling a transaction it should not have and confirming it is refused. Critical items should be closed before a new integration goes live and checked again after every upgrade. Export the result to PDF as evidence for the access review.

Common mistakes

One generic integration user shared by every interface, so nobody can tell which system made a change. .ionapi files committed to a Git repository or left on a shared drive. Test integrations pointing at production with an administrator account. Basic authentication to m3api-rest over HTTP on an internal network that turns out to be less internal than assumed. And API authority that was never reviewed after an upgrade added new transactions to programs the integration already had.

Frequently Asked Questions

How do I restrict which M3 APIs a user can call?

Use Function. Connect API Authorization (SES005) to restrict access per API program and transaction, combined with role-based function security in SES400. Without SES005 restrictions users can access every API program and transaction by default. Test the restriction by calling a disallowed transaction as the integration user.

What is the Infor M3 API gateway?

It is the ION API gateway, part of Infor OS, which publishes M3 MI programs and other Infor APIs as REST endpoints secured with OAuth 2.0. Client credentials are created in ION API and downloaded as .ionapi files. On-prem M3 can also expose MI over REST directly through m3api-rest.

Is it safe to use EXPORTMI for integrations?

It can be, for a reviewed use with a dedicated account, but it reads table data broadly, so it is a common source of over-exposure. Prefer specific MI transactions where they exist, restrict EXPORTMI through API authority to the accounts that need it, and alert on unexpected use or volume.

Where should .ionapi files be stored?

In a secret store or vault, or protected configuration readable only by the integration's service account. Never in source control, email or a shared folder. If a file was exposed, revoke the client secret in ION API, create a new one and distribute it only to the service that needs it.

If you want a private AI assistant to call M3 through read-only, authority-checked MI transactions on your own servers, we can set that up.

ArchRay builder
Design the on-prem AI stack for Infor M3: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

Runs with your ERP

Guides

AI on your ERP

Integrations

Software