# How to Call SyteLine IDOs from an External Application > Source: https://netray.co/erp-help/syteline-ido-soap-web-service-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer SyteLine exposes its IDO layer as a SOAP web service, commonly published through an IDORequestHandler endpoint, so an external .NET application, middleware platform, or script can Load, Update, Delete, and Invoke methods on the same IDOs the SyteLine client itself uses. You call it like any SOAP service: reference the WSDL, authenticate, and pass the IDO name, method, and parameters in the request. ## Kind advanced ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module Integration - IDO Web Services ## Query How to call SyteLine IDOs from outside SyteLine using web services ## Alternate Queries - syteline soap api integration - idorequesthandler.asmx how to use - call syteline ido from external application - syteline web service integration c# ## Applies To SyteLine 8.x, 9.x, CloudSuite Industrial (CSI) 10.x on-prem SOAP integration; CSI cloud tenants commonly also use ION API/BODs for integration ## Steps ### Consume the IDO SOAP service from external code **Items:** Confirm the IDO web service is enabled for your SyteLine instance and note its base URL, typically an IDORequestHandler endpoint published from the SyteLine application or web server. Add a service reference in Visual Studio from the WSDL, or, for non-.NET clients, build SOAP envelopes by hand against the published operations. Authenticate using the credential mechanism your environment expects for web service calls - a dedicated integration user account is strongly preferred over reusing an interactive user's login. Call Load to read a filtered set of rows from an IDO, passing a query or filter expression the same way the client would when opening a browse. Call Update, Insert, or Delete to write changes, and check the IDO-level error and result payload rather than assuming a successful SOAP response also means the business logic succeeded. For custom operations, call Invoke against a custom IDO method the same way you would a built-in one, passing the parameters defined on that method's Methods tab. Log the raw request and response payloads during development so you can see exactly which IDO validation or extension-class error came back when a call is rejected. ## Sections ### What the IDO web service actually is **Body:** The SOAP endpoint is a thin wrapper over the same IDO runtime the SyteLine client itself talks to, so anything reachable through a form - reading a filtered list of orders, updating a field, running a custom method - is also reachable programmatically through the same IDO calls made interactively. This is why it has been the standard integration point for middleware - EDI translators, custom .NET utilities, older iPaaS connectors - for years, long before ION API existed as an alternative for cloud tenants. ### Authentication and a dedicated integration account **Body:** Use a dedicated service account scoped to only the IDOs and operations the integration needs, both for audit clarity - you can tell integration traffic apart from a real user in logs - and so a credential change for a human user does not silently break an automated integration. Some environments require the service account to hold an appropriate license or user seat, which surprises teams that assumed a service account would be free; confirm licensing before committing to the design. ### Error handling - SOAP success is not IDO success **Body:** A SOAP call can return a valid, successful transport response while the IDO itself rejected the operation - a validation failure inside a BeforeUpdate extension hook, for example. Integration code must inspect the IDO result or error structure in the payload, not just the transport-level status, or failed writes will silently look like they succeeded. ### SOAP versus ION API for CSI cloud **Body:** For CloudSuite Industrial tenants hosted by Infor, ION API and BOD-based integration is generally the sanctioned path for new cloud-to-cloud integrations, while the classic SOAP IDO service remains common for on-prem installs and for legacy integrations that predate ION. Before building new integration work against SOAP on a CSI cloud tenant, check with Infor or your implementation partner on which path is currently supported and preferred for that scenario. ## Pitfalls - Treating a successful SOAP response as success without checking the IDO-level result payload for a business validation error. - Reusing an interactive user's login for the integration account, so a password reset or license reassignment silently breaks the integration. - Not handling IDO-level locking or concurrency errors - an integration that just fails hard on these instead of retrying can drop transactions. - Passing filter or query syntax that does not match what the target IDO expects, which usually returns an empty result set rather than a clear syntax error. - Building new integrations against the classic SOAP endpoint on a CSI cloud tenant without checking whether ION API/BOD is the currently required path. - Not logging raw request and response payloads during development, making an extension-class rejection far harder to diagnose after the fact. ## Ai Angle SyteRay can generate the client-side integration code for a specific IDO call - the WSDL reference, the request shape, and the error-payload handling - from a description of what the integration needs to do, and can flag when a target IDO has an extension class or custom method that might reject the call under conditions not obvious from the IDO's field list alone. For teams already on ION API, it can also help decide which integration path fits a given cloud-to-cloud scenario. ## Faq ### Do I need a SyteLine license to call the web service? **Answer:** In most environments the integration or service account still needs an appropriate license or user seat, since it is consuming the same IDO runtime under the hood. Confirm licensing requirements for your specific environment before building the integration. ### Can I use the SOAP IDO service from a non-.NET language? **Answer:** Yes - since it is a standard WSDL-described SOAP service, any language or platform with SOAP client support, including Java, Python, or integration platforms like Boomi or BizTalk, can consume it, not just .NET. ### Why does my Load call return zero rows when I know data exists? **Answer:** Almost always a filter or query expression that does not match what that IDO expects, or a site and security context on the integration account that excludes the rows. Test the same filter interactively against the IDO first to confirm it returns the expected rows. ### Is the SOAP IDO service still relevant on CloudSuite Industrial? **Answer:** It is often still available for on-prem-style integrations, but Infor generally steers new CSI cloud integration work toward ION API and BODs. Check current guidance for your tenant before committing new development to the classic SOAP endpoint. ## Search terms syteline soap web service, idorequesthandler, syteline ido web service integration, call syteline from external app, syteline api c#, syteline middleware integration, syteline load update invoke soap, syteline integration account --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json