# M3 API Error: Not Authorized to Program > Source: https://netray.co/erp-help/m3-mvxapi-soap-not-authorized-to-program-error > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System infor-m3 ## Erp Infor M3 (M3 Business Engine) ## Module MvxAPI / M3 API Gateway ## Query M3 API SOAP call fails with Not authorized to program ## Alternate Queries - 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 ## Applies To Infor M3 Business Engine 10.x-14.x, all MI program calls over MvxSOAPAdapter, m3api-rest and ION API ## Steps ### Resolve a Not authorized to program error **Items:** Confirm 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. Check that user's record for its assigned authority group (User. Open, program MNS150) rather than assuming authority is per-user. Open 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. Check 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. If 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. For 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. After 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. Re-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. ## Sections ### Authentication succeeding is not the same as authorization **Body:** 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 **Body:** 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. **Code:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Can I authorize a program for an individual user instead of through an authority group? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms M3 API not authorized error, MvxAPI authorization error, M3 authority group MNS405, M3 API service user permissions, ION API grant M3, M3 MI program authority, M3 API 401 not authorized, M3 CONO DIVI authority scope, M3 API integration user setup, MNS150 MNS405 M3 security --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json