The IFS Cloud OData REST API, explained

IFS Cloud exposes its data and operations through OData REST APIs organised as projections. A projection is a published surface over the underlying model — a set of entities, fields and actions intended for a particular purpose. Integrating with IFS means working through these projections correctly, and the details matter.

Projections and entity sets

The first challenge is simply finding the right surface. The data you want lives in a specific projection and entity set, with specific key fields. Knowing which projection holds purchase requisitions, or which entity set carries work-order operations, is half the work — and it is not always obvious from a screen name.

Querying: $select, $filter, $expand

OData gives you a rich query language. You shape responses with $select, filter with $filter, pull related data with $expand, sort with $orderby, and page with $top and $skip. Used well, this is precise and efficient.

The catch is enums. Many IFS fields are enumerations, and a filter has to use the valid enum value, not the label a user sees. Get the enum wrong and the query returns nothing — or the wrong thing.

Writing safely: ETags and defaults

Writes are where correctness really bites. IFS uses ETags for optimistic concurrency: to update or delete a record safely you must send the current ETag, or risk overwriting someone else's change. On create, many entities expect server-resolved defaults — the _Default() call — before the record is valid.

These are not optional niceties; they are how you avoid data integrity problems in a live ERP.

Doing things: bound actions

Plenty of IFS operations are not simple field updates — they are actions: release an order, approve an invoice, cancel a line. In OData these are bound actions invoked against an entity. A correct integration calls the action, rather than trying to mimic its effect by patching fields, which would skip IFS business logic.

Why this is hard by hand — and how AI helps

None of this is impossible, but all of it is fiddly, and every new integration repeats the same archaeology: find the projection, read the spec, resolve the enums and required fields, handle ETags, call the right action, add auth and paging. That is why IFS integration work is slow.

An IFS-native app builder encodes these conventions. It discovers the projection and spec, resolves enums and required fields from live metadata, and generates OData calls with ETags, defaults and bound actions handled — so the integration is correct from the start.