Infor OS Service Limits: Payload, File Size and Rate, and How to Design Around Them

How to find and design around Infor OS service limits

1. 1List every Infor OS service your integration touches: ION API calls, ION document flows, IDM attachments, file or data lake loads.
2. 2For each, look up the documented limits in the current Infor documentation and confirm tenant-specific ones with Infor support. Record them in your integration design.
3. 3Measure your real maximums: the largest document, the biggest list response and the peak request rate at month end or quarter end.
4. 4Chunk anything large: page list calls, split big documents into logical batches, and move large files by reference instead of embedding them in a message.
5. 5Make each unit of work idempotent with a business key so that a retry after a failure cannot duplicate transactions.
6. 6Add monitoring for rejected, delayed and dead-lettered messages, with an alert before the queue backs up.
7. 7Test at limit size in a non-production tenant, including the failure path, before go-live.

Patterns that survive limits

paged read with checkpoint (pseudocode):
cursor = load_checkpoint() or start
while cursor:
  page = get(url, cursor, page_size=N)
  process(page)            # idempotent
  save_checkpoint(page.next)
  cursor = page.next

Common pitfalls

• !Designing around a limit number from a forum post that no longer applies to your release.
• !Testing only with small sample documents and finding the size limit in production.
• !Embedding large files in messages instead of passing a reference.
• !Retrying non-idempotent operations, which duplicates orders or postings.
• !Ignoring dead-lettered messages until a user reports missing data.