# How to Create an .ionapi File and Service Account in Infor OS > Source: https://netray.co/erp-help/infor-os-ionapi-file-service-account-create-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer An .ionapi file is a JSON credentials file you download from ION API after registering an Authorized App of type Backend Service and creating a service account for it. It carries the tenant, client id, client secret, the token and authorization endpoints, and the service account keys that your scripts or integrations use to request an OAuth 2.0 access token. ## Kind how-to ## System infor-os ## Erp Infor OS (ION API) ## Module ION API / Authorized Apps ## Query how to create .ionapi file Infor OS service account ION API ## Alternate Queries - Infor ION API backend service authorized app - download ionapi credentials Infor OS - Infor ION API service account access key secret key - ION API client id client secret saak sask ## Applies To Infor OS multi-tenant cloud (CloudSuite) and Infor OS on-premises with ION API; menu names vary slightly by release ## Steps ### Create the credentials **Items:** - Sign in to Infor OS Portal with a user who holds the IONAPI-Administrator security role, then open the ION API application from the apps menu. - Choose Authorized Apps and select the add (+) button to register a new application. - Set the Name (for example ERP_Reporting_Svc), pick the type Backend Service, and give it a clear description so the next administrator knows its purpose. - Save. ION API shows the Client ID and Client Secret for the app and lets you download the .ionapi file for the application itself. Keep this separate from the service account keys. - Open User Management in Infor OS, create a user of type Service Account, and assign only the security roles the integration needs (for example the roles for the IDO, M3 API or IDM access it will call). - On the service account, use the option to create access keys. The dialog returns a Service Account Access Key and a Service Account Secret Key. The secret key is shown only once, so copy it now. - Back in ION API, download the .ionapi file and confirm it contains the service account key fields, or add them if your script keeps them separately. - Store the file in a secrets vault, never in source control, and test by requesting a token from the pu/ token endpoint named in the file. ## Sections ### What is inside an .ionapi file **Body:** The file is plain JSON. The fields you will use most are ti (the tenant id), cn (the client name), ci (client id), cs (client secret), iu (the base ION API URL for the tenant), pu (the base URL for the authorization server), oa (authorization endpoint path), ot (token endpoint path), or (revoke path), saak (service account access key) and sask (service account secret key). A trailing version field and the ev field for the environment are also present. Because the client secret and the service account secret are both in the same file, treat it like a password. Anyone who holds it can call every API the service account is entitled to, from any machine, until you revoke the keys. Rotate by deleting the access key on the service account and creating a new one, then update the file where it is stored. **Code:** { "ti": "ACME_PRD", "cn": "ERP_Reporting_Svc", "dt": "12", "ci": "ACME_PRD~xxxxxxxx", "cs": "", "iu": "https://mingle-ionapi.inforcloudsuite.com", "pu": "https://mingle-sso.inforcloudsuite.com:443/ACME_PRD/as/", "oa": "authorization.oauth2", "ot": "token.oauth2", "or": "revoke_token.oauth2", "ev": "U1234567", "v": "1.0", "saak": "", "sask": "" } ### Requesting a token with the password grant **Body:** Backend services use the OAuth 2.0 password grant, where the service account access key is the username and the secret key is the password. You POST to pu plus ot with grant_type=password and send the client id and client secret using HTTP Basic authentication or in the form body. The response contains access_token, token_type Bearer and expires_in. Call the API gateway at iu followed by the tenant id and product path, for example iu/TENANT/M3/m3api-rest/v2/execute/MMS200MI/GetItmBasic, with the header Authorization: Bearer plus the token. Refresh by requesting a new token before expiry rather than caching a token for days, because expired tokens return 401. **Code:** curl -s -X POST "https://mingle-sso.inforcloudsuite.com:443/ACME_PRD/as/token.oauth2" \ -u "ACME_PRD~xxxxxxxx:CLIENT_SECRET" \ -d "grant_type=password" \ -d "username=SERVICE_ACCESS_KEY" \ -d "password=SERVICE_SECRET_KEY" ### Choosing the right Authorized App type **Body:** Backend Service is for server to server jobs with no human present: nightly extracts, middleware, and AI agents. Web Application and Mobile or Desktop types are for interactive sign in, where a user consents and the app receives an authorization code. Pick the type that matches how the caller authenticates, because you cannot switch a registered app between flows without re-registering it. Scope the service account tightly. The account inherits whatever its security roles allow in each downstream product, so a reporting integration should not hold the same roles as an administrator. If you need separate audit trails per integration, create one Authorized App and one service account per integration instead of sharing one file. ## Pitfalls - Losing the Service Account Secret Key: it is displayed once. If you did not save it, create a new access key. - Using the client secret as the password. The password grant uses the service account secret key (sask) as the password and the access key (saak) as the username. - Committing the .ionapi file to Git or pasting it into a chat or ticket. Treat it like a production password and rotate it if it leaves the vault. - Giving the service account administrator roles because it is faster. Calls then succeed everywhere, which hides missing role design and widens the blast radius. - Hard coding the token endpoint from another tenant. The pu value is tenant specific, so always read it from the file. ## Ai Angle When an AI assistant calls Infor through ION API, it should use a dedicated service account with read-only roles and a short lived token, and the credentials should live in the vault the model runtime reads, never in a prompt. ERPray connects through this kind of service account, shows the query it ran, and respects the ERP roles attached to the account, so an assistant can only see what the account is entitled to see. ## Faq ### Where do I download the .ionapi file in Infor OS? **Answer:** Open ION API from the Infor OS apps menu, go to Authorized Apps, select your registered Backend Service app and use the download option for the credentials file. You need the IONAPI-Administrator role to see the Authorized Apps screen. ### Can I reuse one .ionapi file for several integrations? **Answer:** You can, but it is poor practice. Every call is then attributed to the same account, you cannot revoke one integration without breaking the rest, and the role set grows to the union of all needs. Create one app and service account per integration. ### How long does an ION API access token last? **Answer:** The expires_in value in the token response tells you. It is typically in the range of minutes to a couple of hours depending on tenant configuration. Request a new token before it lapses instead of assuming a fixed lifetime. ### Do I need a service account for the OAuth password grant? **Answer:** Yes for Backend Service apps. The service account supplies the access and secret keys that act as username and password, and its security roles decide what the token may do in M3, SyteLine, LN, IDM or other products. ## Search terms create ionapi file, Infor ION API service account, ION API backend service, ionapi saak sask, Infor OS authorized apps, ION API client id client secret, Infor OS OAuth password grant, IONAPI-Administrator role, Infor ION API token endpoint, Infor OS service account keys --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json