Error fixInfor M3 (M3 Business Engine)MvxAPI / M3 API Gateway

M3 API Error: Not Authorized to Program

Error
M3 API SOAP call fails with Not authorized to program

Also searched as

  • M3 MI program not authorized error fix
  • MvxSOAPAdapter authorization error M3
  • M3 API Gateway 401 not authorized
  • M3 user missing function authority for API program

Short answer

Not authorized to program (or the equivalent transaction-level authorization error) means the M3 user ID the integration authenticates as can log in fine but has not been granted access to that specific MI program, transaction, or company/division through its authority group. Fixing it means adding the program/transaction to the integration user's authority group in M3, not changing anything in the calling code.

Applies to: Infor M3 Business Engine 10.x-14.x, all MI program calls over MvxSOAPAdapter, m3api-rest and ION API

Resolve a Not authorized to program error

  1. 1Confirm the exact user ID the integration is authenticating as - many teams assume it is a named person's ID when it is actually a dedicated service/API user, or vice versa.
  2. 2Check that user's record for its assigned authority group (User. Open, program MNS150) rather than assuming authority is per-user.
  3. 3Open the authority group (Authority Group. Open, program MNS405) and confirm the specific MI program and transaction combination (for example OIS100MI, transaction Add) is included, not just the underlying interactive program.
  4. 4Check company (CONO) and division (DIVI) scoping on the authority group - a user can be authorized for a program in company 100 and still get rejected calling the same program in company 200.
  5. 5If the call is failing only for certain transactions within a program (List works, Add does not), the authority group likely grants read-level transactions but not write-level ones - add the specific transaction explicitly.
  6. 6For ION API calls, also check the ION API authorization/grant configured in Infor OS - a valid M3 user authority does not bypass a missing or expired ION API grant for that flow or service account.
  7. 7After updating the authority group, have the user log out and back in (or refresh the service account's token) since M3 can cache authority at the session level.
  8. 8Re-test with the exact same program/transaction/company combination that originally failed to confirm the fix rather than testing a different transaction that happened to already work.

Authentication succeeding is not the same as authorization

This error confuses people because the connection itself works - credentials are accepted, the SOAP/REST call reaches M3, and you get a structured error response rather than an HTTP-level failure. That is expected: M3 authenticates the user first, then separately checks whether that user's authority group grants access to the specific program and transaction being called. A user can be perfectly valid and still be rejected for a specific MI call because nobody added that program to their authority group when the integration was built.

This is a deliberate design, not a bug: M3's authority model is meant to let an admin grant an integration user access to exactly the programs and transactions it needs (read-only List access to items, for example) without opening up Add/Chg/Del on programs the integration was never meant to touch.

Where API authority actually lives

Authority for MI programs is granted through the same Authority Group mechanism (MNS405) used for interactive M3 menu access, not a separate API-only permission table. This means the fastest way to see what an integration user can call is to open their authority group in MNS405 and look at the list of authorized programs and transactions, filtering to the MI program name you are troubleshooting. If the authority group is shared with interactive users, be careful about adding broad write access just to unblock one integration - create or clone a dedicated authority group scoped to the integration's actual needs instead.

MNS150 (Users) -> find the API/service user
  -> Authority Group field points to e.g. "APIUSER"

MNS405 (Authority Group) -> open "APIUSER"
  -> Programs/Transactions tab
  -> confirm OIS100MI / Add is listed, with CONO/DIVI scope

ION API adds a second authorization layer

When the call comes through ION API rather than a direct MvxAPI/SOAP connection, there are two authorization checks in the path: the ION API grant configured in Infor OS (which service account or OAuth client is allowed to reach the M3 endpoint at all) and the underlying M3 user authority described above. A Not authorized error from an ION-routed call can originate from either layer, so check the ION API authorized services/grants list in Infor OS before spending time only on the M3 side.

Common pitfalls

  • !Assuming a working password means full authorization - authentication and per-program authority are checked separately.
  • !Editing the authority group used by interactive staff to unblock an integration, which grants that integration far more access than it needs.
  • !Forgetting CONO/DIVI scoping - authority can be correct for one company and still fail in another company the integration also needs to reach.
  • !Not distinguishing List-level (read) authority from Add/Chg/Del-level (write) authority when only some transactions on a program are failing.
  • !Chasing the M3 authority group when the real block is the ION API grant for the service account, in ION-routed integrations.
  • !Forgetting to have the user or service account re-authenticate after an authority group change, since M3 can cache authority within an active session.

How an ERP-grounded AI assistant handles this

ERPray connects to M3 using its own scoped service account with an authority group limited to what its grounded Q&A and agent actions actually need, and when a requested action would need a program or transaction outside that scope, it says so explicitly rather than failing silently, which makes the difference between an authentication problem and an authorization gap obvious from the first response.

See ERPray

Frequently asked questions

Can I authorize a program for an individual user instead of through an authority group?

No - M3's standard security model grants program/transaction access through authority groups, and users inherit access from the group assigned on their user record. Create or clone a group if you need authority tailored to one integration or one person.

Why does the error say 'Not authorized' instead of a normal 401?

The M3 API Gateway returns this as a structured MI response (errorType/errorMessage) rather than an HTTP 401, because authentication already succeeded - the failure is at the M3 authorization layer, one step further in, not at the connection layer.

Does authorizing a program automatically authorize all its transactions?

Not necessarily - depending on how the authority group entry is configured, it can be scoped to specific transactions within a program. If List works but Add does not, the group most likely lists the transactions explicitly rather than granting the whole program.

Is there a log that shows exactly which authority check failed?

The MI response's errorMessage is usually the most direct signal. For deeper investigation, M3's audit/security logs (or Infor OS logs for ION-routed calls) can show the authorization decision, but the authority group review in MNS405 is almost always faster for a straightforward missing-grant case.

Related

Error fix

M3 API Error: Record already exist

Record already exist means the MI Add transaction you called is trying to insert a key that is already present in the target M3 table, most often because a prior call succeeded and was retried, or because the key fields you built do not match what you think they match. Read the errorField and errorFieldGroup attributes on the response to see exactly which key field M3 flagged, then either switch to the matching Chg (change) transaction or fix the key construction in the caller.

Advanced

Paging M3 API MI List Transactions Past the Default Record Limit

M3 List transactions (the read/browse transaction most MI programs expose, such as CRS610MI.LstByNumber or OIS100MI.LstOrderHead) cap the rows returned per call using the MaxReturnedRecords input field, and by default many clients leave it low or unset, which looks like the API silently truncating results. Set MaxReturnedRecords explicitly, then loop the call using the last key values from the previous page as the starting position until fewer rows than the limit come back.

How-to

How to Build a Grid Mapping in M3 Enterprise Collaborator (MEC)

M3 Enterprise Collaborator (MEC) moves data between an external format (EDI, flat file, XML) and M3's own API by chaining a collection step (getting the document in), a grid mapping step (field-level transformation from source structure to M3 API call structure), and a delivery step (executing the mapped MI transaction). Building a new mapping means defining the source document structure, building the grid that maps each source field to its M3 API field, and testing with representative sample documents before going live.

How-to

How to Add a Personalization Script to an M3 H5 Panel

M3 H5 lets an administrator attach a JavaScript personalization script to a specific panel of a specific program, using the MForms client API to read fields, react to panel and field events, and adjust the UI (hide fields, set defaults, validate input) without modifying the underlying M3 program. Scripts are written and attached through Personalization mode in H5, saved against the panel/program combination, and deployed to the users or roles who should see the behavior.

How-to

How to Create a New Item in M3 (MMS001)

A new item in M3 is created in two stages: item basic data in MMS001 (Item. Open), which defines company-wide attributes such as description, item group and unit of measure, then facility-level data in MMS002 (Item/Facility. Connect), which attaches the item to a specific warehouse or plant with purchasing, planning and costing parameters. An item is not usable for orders, purchasing or MRP until both stages are complete.

How-to

How to Enter a Customer Order in M3 (OIS100)

OIS100 (Customer Order. Open) is the primary M3 program for entering and maintaining customer orders, built as a header-then-line workflow: you first create the order header with customer, order type and delivery terms, then add order lines that each carry their own item, quantity, price and delivery date defaulted from customer and item agreements.

AI for ERP

AI for Infor M3: A Practical Path from MI Programs to a Private Assistant

Add grounded AI to Infor M3: natural-language answers over MI programs and MEC, agents for distribution and manufacturing, on-prem or private cloud in Europe.

AI for ERP

AI Agents Over Infor ION API, BODs, and the Infor Data Lake

Build AI agents on Infor ION API Gateway, BODs, and Data Lake, alongside or instead of Infor's own GenAI features, with your choice of model and hosting.

Stuck on Infor M3 (M3 Business Engine)?

Talk to engineers who work inside Infor M3 (M3 Business Engine) every week, and who build private AI that answers these questions from your own ERP data.

Talk to an ERP engineerBrowse ERP Help
All ERP Help articles