Which API should be used?

I'm a .NET developer that has recently moved into a role where I will be developing applications to aid in facilitating administrative interactions and providing administrative information about multiple Mongoose-based products, environments, and versions. Poking around Infor Xtreme and mongoose.infor.com, I've noticed that there are multiple APIs to interact with Mongoose. I imagine this is due to different API philosophies and legacy code persisting throughout time. I'd rather not write code tailored to a specific API that is either on its way out or isn't very mature. Can anyone comment on which API should be used for which purposes?

Find more posts tagged with

API Usage

Accepted answers

Rees Howel

Suggest you use the Mongoose REST API. The .NET Web Service which still ships with Cloudsuite Industrial is based on SOAP and will probably be deprecated at some point, so that's probably best avoided

Welcome To Solutions Development.docx

Legacy Contributor

REST API is for developers who don't necessarily have access to the CSI software, but want to write an integration to an external application that will extract or post data to CSI. There is three flavors of the IDO Request Service API, one that is SOAP-based (chapter 2 of the Integrating IDOs with External Applications guide), one that is .NET-based (chapter 3 of the Integrating IDOs with External Applications guide), and one that is ASP.NET-based using the IDO Web Service (chapter 5 of the Integrating IDOs with External Applications guide). I agree the SOAP-based and IDO Web Service-based ones should be considered deprecated, as the REST API replaces the need for those two interfaces to the Mongoose Framework.

The .NET-based one however is how the core product communicates itself. It uses the .dll libraries (IDOProtocol, IDORequestClient, MGShared, WSEnums, WSFormServerProtocol) to make requests to the IDO Request Service. These .dlls are only available if you are a licensed customer.

For the .NET method, you get the dlls in one of three ways: 1) Install an Administrative client which installs the developer tools including a locally installed version of the smart client, the development IDO Request Server, and the Configuration, Form Sync, and Metadata utilities. 2) Copy the dll files from the SyteLine directory on the Utility Server. 3) Install a Smart Client and copy the dll files from the AppData directory where the Smart Client is installed.

If you have ever written Form Scripts, the .NET method will be familiar, because it uses the same LoadCollection request/response, UpdateCollection request/response, and Invoke methods as Form Script uses.

All comments

Rees Howel

Welcome To Solutions Development.docx

Legacy Contributor

Thanks, Tim. That is super helpful information.

Legacy Contributor

Do you know if we need to pay extra licences for these integrations? Maybe one CSI Transactional Named User per API/DLL, or one for all of them? Or we can just request an additional Automation Product Key at no cost?

Legacy Contributor

For the integration, no. What account type you use depends on your app. Most data you are going to want to access will be user based, which will require you to create a sign in page and log in through the API with the user provided credentials, using a user license. If the information is not based on user-level permissions, then you could use an automation account and license. But you can only assign one set of IDO permissions to that account. So you may need more than one automation license (not free) to have separate accounts with the appropriate permissions. Although you could give that account read-only access to all the IDOs you would use in your application, I still wouldn't consider the application secure with a single account that had broad access - read-only or not. A lot of people cheat in this area and that is why you see businesses getting hacked.

Legacy Contributor

@tim-boyden we're getting there with our new website, trying to align our best way to push/pull data and transactions between Syteline 9.01.01 on-premise and a custom-built Episerver-based website.
So I understand it's the REST API from CSI/Mongoose.

Now what I'm not sure is: which exact documentation should I use?
The "Infor Mongoose Integrating IDOs with External Applications" PDF guide I just fetched on my Infor Support Portal is already 5 years old (dated 2016) and never mentions "REST"...
The only mention of SOAP is in code/method examples from Chapter 5, which is "Using the .NET Web Service API".

"Chapter 2: Using XML IDO Request and Response Documents" kinda looks like it could be REST... but according to your answer it's the deprecated SOAP-based API.

"Chapter 3: Stand-alone application communications" is .NET DLLs via ASP but doesn't look like REST to me (?)... is it the one you're recommending? Is it really REST?

I'm confused.

Legacy Contributor

It was undocumented unless "you knew a guy" in CSI versions before CSI 10. Attached is what I got from development a long time ago. There is an error in the document for the URLs where they show a rest/ URL segment. Omit that and the calls will work. Also undocumented is an endpoint that gives API v2 like json responses. The URL for that call is:

https://{{hostname}}/IDORequestService/MGRestService.svc/js/{{IDO}}/{{IDO Property List}}/adv?filter={{filter}}&orderby={{order}}&rowcap={{0 = unlimited or row count}}&readonly={{true or false}}

I am also attaching the Swagger document that you can import into Postman.

[View:/cfs-file/__key/communityserver-discussions-components-files/79/Mongoose-REST-Web-Service.pdf:320:240]

[View:/cfs-file/__key/communityserver-discussions-components-files/79/MGRestServiceSwagger.zip:320:240]

Legacy Contributor

Excellent, Thank you so much!

Copyright © 2025 Infor. All rights reserved.