Connecting external systems to SyteLine with the Mongoose IDO REST API

Why the API, not SQL

Integrations that write straight to SyteLine's tables skip everything SyteLine does on save: validations, triggers, event handlers, and the business rules inside the IDOs. That's how integrations create records the application then can't handle. The REST API goes through the IDO layer, so a record created by your web shop or MES is checked the same way as one keyed in on a form.

It's also the only option in multi-tenant CloudSuite Industrial, where there's no direct database access.

Find the right IDO and property names first

The API works with IDO and property names, not table columns or screen labels. Before writing any code:

1. Open the form your integration mirrors, for example Items, and note the IDO behind it.
2. Open the IDOs form, find that IDO, and list its properties.
3. Use those exact property names in every request.

Guessing from screen labels or SQL column names is the most common cause of "property not found" failures.

Two API versions

Version 2 also generates Swagger documents per IDO, at /IDORequestService/ido/dynamic/api-docs-collection/{IDOName}. Open these on your own server. They describe every operation, its parameters and example request bodies for exactly the version you're running. The examples below use the documented version 1 patterns. Check paths against your server before building.

Step 1: Get a security token (direct calls)

Version 1:

GET http://server/IDORequestService/MGRESTService.svc/json/token/CSI_DALS
userid: integration_user
password: ********

CSI_DALS is an example configuration name from the application server. Use yours. The JSON response contains Message and Token.

Version 2 also has a token request, GET /IDORequestService/ido/token/{config}, which can take the username and password in headers or in the path. Use headers. Credentials in a URL end up in web server logs.

Send the token in the Authorization header on every later call.

Through ION API, which is the usual route in cloud, you don't call the token service. You authenticate with OAuth 2.0 against ION API, send the bearer token in Authorization, and add X-Infor-MongooseConfig with the configuration name.

Step 2: Load records

Version 1 "advanced" load, with filter and sort:

GET http://server/IDORequestService/MGRESTService.svc/json/SLItems/Item,Description,ProductCode/adv?filter=ProductCode%20%3D%20'FG'&orderby=Item&recordcap=100
Authorization: <token>

The parameters that matter:

The standard JSON response returns Items as an array of rows, in the same order as your property list, plus Message and MessageCode (0 means success).

Don't use recordcap=0 on big IDOs. Page through with loadtype and bookmark instead. Pulling an entire transaction table in one call is slow for you and for everyone using SyteLine.

Step 3: Update records

An update sends an Action, the item's ItemId, and the Properties being changed:

{
  "Action": 2,
  "ItemId": "<the _ItemId value returned when you loaded the record>",
  "Properties": [
    { "Name": "Description", "Value": "New description", "Modified": true, "IsNull": false }
  ]
}

• Action: 1 insert, 2 update, 4 delete.
• ItemId: identifies the exact record. Take it from the load response rather than building it yourself. Loads marked read-only (ro=True) don't return it.
• Modified: true marks the properties you're changing. IsNull: true writes a null.

A successful update responds with a Message and MessageCode.

Step 4: Invoke IDO methods

Some work isn't a simple insert or update, such as releasing something, running a calculation, or posting. SyteLine does these through IDO methods, and the API can call them (InvokeMethod). Prefer an existing IDO method to recreating its logic in your integration. The method already does it the way SyteLine expects.

Habits that keep integrations healthy

• A dedicated user per integration, with permission only for the IDOs it needs. Never use an administrator's or a real person's account. When it misbehaves, you can see exactly what it did, and switch it off on its own.
• Ask for few properties, page through results. Small, frequent requests beat one enormous one.
• Log every non-success Message. SyteLine's own error text is usually the fastest way to the fix.
• Retry sensibly. A busy system can fail a request that succeeds a moment later, for example a deadlock victim. Retry a couple of times with a pause, then alert.
• Keep tokens safe and out of URLs and code. Store credentials in a secrets store and rotate them when people leave.
• Test against a non-production configuration before pointing anything at live data.

Building your own API endpoint

SyteLine also includes a REST API Wizard that builds an API around a chosen IDO operation, such as a Load Collection with fixed properties, filter and order. It produces a Swagger document and base URL. For simple read integrations, that can be quicker and safer than hand-building requests.

FAQ

Does SyteLine have a REST API?

Yes. The Mongoose IDO Request Service exposes SyteLine's IDOs over REST, so you can load, update and invoke methods on the same objects the forms use.

How do I authenticate to the SyteLine REST API?

For direct calls, request a security token for a configuration and send it in the Authorization header. Through ION API, use an OAuth 2.0 bearer token and the X-Infor-MongooseConfig header.

Why does my SyteLine API call only return 200 records?

The default record cap is typically 200. Set recordcap explicitly, and page through larger sets with loadtype and bookmark instead of loading everything at once.

Can I write to SyteLine tables directly instead of using the API?

You shouldn't. Direct writes bypass SyteLine's validations and business logic. Use the IDO REST API or IDO methods.