# SyteLine IDO API Security Hardening Checklist > Source: https://netray.co/tools/syteline-ido-api-security-hardening-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Accounts, transport, tokens, request hygiene and monitoring checks for exposing the SyteLine IDO request service (REST and SOAP) to integrations and scripts. ## Category developer ## Erp Infor SyteLine ## Audience - Integration developer - IT security - ERP administrator ## Tool **Kind:** checklist **Groups:** #### Accounts **Items:** **Text:** Each integration uses its own dedicated SyteLine user, never sa, an administrator or a named employee **Critical:** true **Text:** Integration user placed in a group that grants only the IDOs and methods it needs through group object authorizations **Critical:** true Separate users per integration so audit and lockout affect one interface only Integration users limited to the sites they need Unused integration users disabled and reviewed each quarter #### Transport **Items:** **Text:** IDORequestService reachable over HTTPS only, with a valid certificate on the server that hosts it **Critical:** true **Text:** No direct internet exposure of IDORequestService; firewall allows only known caller addresses **Critical:** true External callers routed through ION API Gateway using OAuth2 with backend service account credentials (.ionapi files) TLS versions and ciphers on the web server reviewed against your security baseline #### Tokens and secrets **Items:** **Text:** Mongoose security tokens (from the REST token request or the SOAP CreateSessionToken method) held in memory only, never written to logs or files **Critical:** true Integration user passwords rotated on a schedule and the rotation tested end to end **Text:** .ionapi files stored in a secrets vault, not in source control or shared folders **Critical:** true Credentials sent in request headers rather than URL paths where your release supports it, since web servers and proxies log URLs; tokens never written to URLs or logs #### Request hygiene **Items:** Read integrations send readonly=True on load requests Load requests name explicit properties instead of * to return only needed columns **Text:** recordcap set to a sensible limit on large IDOs and never 0 (unlimited) in scheduled jobs **Critical:** true **Text:** Filters built only from validated input, never by concatenating user text into the filter string **Critical:** true Integration code handles REST filter restrictions on functions instead of working around them Method calls (invoke) limited to the specific IDO methods agreed in the interface design #### Monitoring **Items:** Handler on SessionOnLoginFailed alerts on repeated failed logins for integration users Where your release lists the IdoPostRequestQuarantined framework event and an IDO request exclusion list, a handler alerts on requests that match the list LogMonitor and web server logs reviewed for unexpected IDOs or volumes from integration users Owner named for each integration user and its alerts #### Licensing **Items:** How API sessions count against your SyteLine licences confirmed with Infor or your partner before go-live Sessions closed or reused so integrations do not leave idle sessions open **Scoring Note:** Critical items are the ones an auditor or attacker finds first: shared or administrator accounts, plain HTTP or internet exposure, tokens and .ionapi files in the wrong place, unbounded loads and filters built from raw input. Fix those before adding new integrations. ## Content **Intro:** This checklist hardens the SyteLine 9 and CSI 10 IDO request service (IDORequestService) when you expose its REST or SOAP endpoints to integrations and scripts. It covers accounts, transport, tokens, request hygiene, monitoring and licensing. **Sections:** #### How to use it **Body:** Run the checklist once per integration, not once per system, because each caller has its own user, network path and request pattern. Export it to Excel with one column per integration and keep it with the interface design. Re-run it when an integration changes owner, starts calling new IDOs, or moves from internal network access to ION API Gateway. Pair it with the general SyteLine user access audit for the human side. #### Where this lives in SyteLine **Body:** The IDO request service runs on the server that hosts IDORequestService and authenticates callers as SyteLine users. What they can read or invoke is governed by group authorizations on IDOs and methods, maintained on the group authorization forms for your release. REST v2 load requests take parameters such as properties, filter, recordcap and readonly. Login failures raise the SessionOnLoginFailed framework event, so an application event handler can alert on them. **Bullets:** - Group object authorizations: IDO and method access - recordcap and readonly: limit load cost and locking - SessionOnLoginFailed: alert on failed logins - ION API Gateway: OAuth2 for external callers #### Worked example **Body:** A shipping integration reads open orders every five minutes as an administrator, with properties=* and recordcap=0. Hardening gives it a dedicated user in a group with read access to the order IDOs only, a property list of nine columns, readonly=True, a recordcap matched to the largest expected batch, and a filter built from a validated date parameter. The caller moves behind ION API Gateway with a service account and the .ionapi file goes into the vault. A SessionOnLoginFailed handler emails the owner after repeated failures. #### Version differences and gotchas **Body:** Request features differ between Mongoose builds. The IDO request exclusion list and the IdoPostRequestQuarantined event appear in current Mongoose documentation; confirm they exist in your SyteLine 9 or CSI 10 build before relying on them. REST v1 and v2 endpoints take different URL shapes. How API sessions consume licences depends on your agreement, so confirm it with Infor rather than assuming. **Cta:** If you want an AI assistant to use SyteLine data through a locked-down, read-only IDO user on your own servers, we can set that up with these controls built in. **Faq:** #### Does Infor Mongoose have a REST API? **Answer:** Yes. The IDO request service exposes REST endpoints for loading collections, updating collections and invoking IDO methods, alongside the older SOAP web service. Calls run as a SyteLine user, so group authorizations apply. Load requests take parameters such as properties, filter, recordcap and readonly. Check which REST version your build supports. #### How should an integration log in to SyteLine? **Answer:** Use a dedicated SyteLine user per integration, in a group that grants only the IDOs and methods it needs. Obtain a security token at startup and keep it in memory. For callers outside your network, put ION API Gateway in front and authenticate with OAuth2 using a backend service account and a vault-stored .ionapi file. #### What does recordcap do in an IDO load request? **Answer:** recordcap limits how many rows a load returns. A value of 0 means no limit, which on large IDOs can load very large result sets and slow the application server. Set it to the largest batch the integration really needs and page through data with filters, rather than pulling whole tables. #### Can I alert on failed SyteLine logins? **Answer:** Yes. SessionOnLoginFailed is a framework event raised when a login attempt fails. Add an application event handler with a Notify action to alert the integration owner or security team, and keep the condition narrow, for example integration users only, so alerts stay meaningful. ## Search terms infor mongoose rest api, infor mongoose api, syteline ion api, syteline login, idorequestservice security, syteline rest api security, mongoose ido rest v2 --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json