Paging M3 API MI List Transactions Past the Default Record Limit
M3 MI List transaction only returns 100 records - how do I page through more
Also searched as
- M3 API MaxReturnedRecords parameter
- M3 API MoreDataExist flag pagination
- how to get more than 100 records from M3 MI List
- M3 API NextStartAt continuation key
Short answer
M3 List transactions (the read/browse transaction most MI programs expose, such as CRS610MI.LstByNumber or OIS100MI.LstOrderHead) cap the rows returned per call using the MaxReturnedRecords input field, and by default many clients leave it low or unset, which looks like the API silently truncating results. Set MaxReturnedRecords explicitly, then loop the call using the last key values from the previous page as the starting position until fewer rows than the limit come back.
Applies to: Infor M3 Business Engine 10.x-14.x, all List-type MI transactions over MvxAPI, m3api-rest and ION API
Page through a full M3 List result set
- 1Identify the List transaction for the program you need (naming is usually LstByNumber, Lst, or Select - check the program's transaction list, not just the program name).
- 2Set MaxReturnedRecords explicitly on every call; do not rely on the adapter default, since m3api-rest, MvxAPI and different ION flow nodes do not all default to the same value.
- 3Send the first call with the starting key fields left at their lowest meaningful value (often blank or zero) to start from the beginning of the range.
- 4Read the returned rows and note the key field values of the last row returned - these become the starting key values for the next call.
- 5Re-issue the List call with those key values as the new starting position; most M3 List transactions are exclusive of the starting key, so the next page begins immediately after it.
- 6Stop looping when the number of rows returned is less than MaxReturnedRecords - that is the standard signal you have reached the end, since M3 List transactions do not return an explicit hasMore flag on most programs.
- 7For high-volume extracts, keep MaxReturnedRecords in the low hundreds rather than maxing it out in one call; very large single responses increase timeout risk on the API Gateway and on ION flows.
- 8If you are calling through ION API, watch the flow's own step timeout separately from the M3 API Gateway timeout - a large List call can exceed the flow timeout even when M3 itself would have returned in time.
Why results look capped at 100
A lot of first M3 integrations hit this because whatever sample code or low-code connector they started from either omits MaxReturnedRecords entirely or hardcodes a small value like 100 as a safe default. The API is not silently dropping data - it is honoring the limit you gave it, explicitly or by omission. Anyone who reports 'M3 API only returns 100 rows no matter what I query' has almost always left this field unset or capped low somewhere in the call chain.
Different adapters behave slightly differently when the field is omitted: some pass through to the underlying MI program's own internal default, others substitute their own connector-level default. If you cannot find where the 100 is coming from, log the exact outbound request XML/JSON so you can see whether your code, your middleware, or the adapter default is responsible.
Key-based paging, not offset paging
M3 List transactions page by key value, not by row offset - there is no SKIP/TAKE style parameter on most programs. This means paging correctness depends on the sort order of the key fields matching a stable, unique sequence; if the underlying data changes between calls (a row is inserted between page 3 and page 4), you can see a duplicate or a gap. For extracts that must be exactly consistent, take a snapshot approach: capture a timestamp or sequence field at the start of the run and filter on it, rather than relying purely on natural key ordering across a long-running paged extract.
Call 1: OIS100MI.LstOrderHead MaxReturnedRecords=200, ORNO="" (start) Response: 200 rows, last ORNO="0000005210" Call 2: OIS100MI.LstOrderHead MaxReturnedRecords=200, ORNO="0000005210" (continue after) Response: 87 rows -> fewer than 200 -> end of set
Where this breaks in low-code tools
Low-code integration platforms (Boomi, Workato, Power Automate connectors, and similar) that wrap M3 API often hide the MaxReturnedRecords field behind a generic 'batch size' setting, or worse, do not expose it at all and silently apply their own default. When an extract in one of these tools looks truncated, check the connector's advanced or raw-parameter view before assuming the M3 side is at fault - most of these tools do let you pass MaxReturnedRecords through if you dig into the raw call configuration.
Common pitfalls
- !Assuming there is an offset or page-number parameter - M3 List transactions page by last key value, not by row number.
- !Leaving MaxReturnedRecords unset and blaming the API for a silent 100-row cap that actually came from a connector default.
- !Using a non-unique or non-sequential field as the paging key, which can produce duplicate or skipped rows across pages.
- !Setting MaxReturnedRecords too high in one call to 'avoid paging', which increases timeout risk on the API Gateway or the calling middleware.
- !Not accounting for data changing between page calls in a long-running extract, causing inconsistent snapshots.
- !Treating a page returning zero rows as an error rather than the normal end-of-data condition.
How an ERP-grounded AI assistant handles this
When a report or agent built on ERPray needs a full M3 dataset rather than a single lookup, it handles the List-transaction paging loop itself - setting MaxReturnedRecords, tracking the continuation key, and stopping at the natural end of the set - so the person asking the question just gets the complete answer instead of having to notice the result was silently truncated at 100 rows.
Frequently asked questions
What is a safe MaxReturnedRecords value for interactive queries?
For an interactive lookup feeding a screen or a chat answer, 20-50 rows is usually enough and keeps response time low. For batch extracts, 200-500 balances fewer round trips against per-call timeout risk; test against your specific ION or API Gateway timeout settings.
Is there a total record count field I can check before paging?
Most List MI transactions do not return a total count up front, since M3 evaluates and returns rows without a separate counting pass. If you need an approximate count first, a targeted MI Get or a small List call against a narrower filter is more reliable than assuming a count field exists.
Does this pagination pattern apply to ION API the same way as direct MI calls?
Yes - ION API and m3api-rest both pass MaxReturnedRecords and the key-based continuation through to the same underlying MI List transaction, so the paging logic in your calling code does not need to change based on which adapter you use.
Why did paging return a duplicate row on the boundary between two pages?
This usually means the starting key on the second call was set to the last row returned rather than the value immediately after it, or the sort key is not unique enough to guarantee an unambiguous cut point. Confirm the List transaction's exclusive-versus-inclusive behavior for the specific starting-key field you are using.
Related
M3 API Error: Record already exist
Record already exist means the MI Add transaction you called is trying to insert a key that is already present in the target M3 table, most often because a prior call succeeded and was retried, or because the key fields you built do not match what you think they match. Read the errorField and errorFieldGroup attributes on the response to see exactly which key field M3 flagged, then either switch to the matching Chg (change) transaction or fix the key construction in the caller.
Error fixM3 API Error: Not Authorized to Program
Not authorized to program (or the equivalent transaction-level authorization error) means the M3 user ID the integration authenticates as can log in fine but has not been granted access to that specific MI program, transaction, or company/division through its authority group. Fixing it means adding the program/transaction to the integration user's authority group in M3, not changing anything in the calling code.
How-toHow to Build a Grid Mapping in M3 Enterprise Collaborator (MEC)
M3 Enterprise Collaborator (MEC) moves data between an external format (EDI, flat file, XML) and M3's own API by chaining a collection step (getting the document in), a grid mapping step (field-level transformation from source structure to M3 API call structure), and a delivery step (executing the mapped MI transaction). Building a new mapping means defining the source document structure, building the grid that maps each source field to its M3 API field, and testing with representative sample documents before going live.
How-toHow to Add a Personalization Script to an M3 H5 Panel
M3 H5 lets an administrator attach a JavaScript personalization script to a specific panel of a specific program, using the MForms client API to read fields, react to panel and field events, and adjust the UI (hide fields, set defaults, validate input) without modifying the underlying M3 program. Scripts are written and attached through Personalization mode in H5, saved against the panel/program combination, and deployed to the users or roles who should see the behavior.
How-toHow to Create a New Item in M3 (MMS001)
A new item in M3 is created in two stages: item basic data in MMS001 (Item. Open), which defines company-wide attributes such as description, item group and unit of measure, then facility-level data in MMS002 (Item/Facility. Connect), which attaches the item to a specific warehouse or plant with purchasing, planning and costing parameters. An item is not usable for orders, purchasing or MRP until both stages are complete.
How-toHow to Enter a Customer Order in M3 (OIS100)
OIS100 (Customer Order. Open) is the primary M3 program for entering and maintaining customer orders, built as a header-then-line workflow: you first create the order header with customer, order type and delivery terms, then add order lines that each carry their own item, quantity, price and delivery date defaulted from customer and item agreements.
AI for ERPAI for Infor M3: A Practical Path from MI Programs to a Private Assistant
Add grounded AI to Infor M3: natural-language answers over MI programs and MEC, agents for distribution and manufacturing, on-prem or private cloud in Europe.
AI for ERPAI Agents Over Infor ION API, BODs, and the Infor Data Lake
Build AI agents on Infor ION API Gateway, BODs, and Data Lake, alongside or instead of Infor's own GenAI features, with your choice of model and hosting.
Stuck on Infor M3 (M3 Business Engine)?
Talk to engineers who work inside Infor M3 (M3 Business Engine) every week, and who build private AI that answers these questions from your own ERP data.