# Infor OS Service Limits: Payload, File Size and Rate, and How to Design Around Them > Source: https://netray.co/erp-help/infor-os-service-limits-design-around-payload-and-rate > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Infor OS services such as ION API and ION messaging have limits on request rate, payload or document size, and processing time. The values change by service and release, so look them up for your tenant rather than trusting a number from a thread, and design integrations to be chunked, resumable and idempotent so a limit becomes a retry instead of an outage. ## Kind advanced ## System infor-os ## Erp Infor OS ## Module ION / ION API architecture ## Query infor os service limits ## Alternate Queries - infor os limits - ion api payload size limit - infor ion document size limit ## Applies To Infor OS with ION API, ION Messaging and IDM; specific limits are version and tenant dependent and must be confirmed with Infor documentation ## Steps ### How to find and design around Infor OS service limits **Items:** - List every Infor OS service your integration touches: ION API calls, ION document flows, IDM attachments, file or data lake loads. - For 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. - Measure your real maximums: the largest document, the biggest list response and the peak request rate at month end or quarter end. - Chunk anything large: page list calls, split big documents into logical batches, and move large files by reference instead of embedding them in a message. - Make each unit of work idempotent with a business key so that a retry after a failure cannot duplicate transactions. - Add monitoring for rejected, delayed and dead-lettered messages, with an alert before the queue backs up. - Test at limit size in a non-production tenant, including the failure path, before go-live. ## Sections ### Three kinds of limits to design for **Body:** Rate limits cap how many requests a client may make in a time window; the symptom is HTTP 429. Size limits cap the payload of a request, a message or an attachment; the symptom is a rejection or a truncated result. Time limits cap how long a request or a message-processing step may run; the symptom is a timeout or a retried message. Each needs a different remedy. Rate is solved with caching and backoff, size with chunking and passing references, and time with asynchronous processing instead of one long synchronous call. ### Patterns that survive limits **Body:** Prefer an asynchronous, message-based flow for bulk work. Send small business documents through ION, let the receiving application process them at its own pace, and confirm completion with an acknowledgement. This is more resilient than a single call that must finish inside a timeout. Where a large result is needed, request it in pages and persist a checkpoint after each page, so a failure resumes from the last good page. For files, store them in a document or file service and send only the identifier through the integration path. **Code:** 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 ### What to do when a limit is not enough **Body:** If a legitimate workload cannot fit, the answer is usually architectural, not a bigger quota. Extract data on a schedule to a reporting store and let heavy readers use that. It keeps analytics and AI queries off the transactional services and avoids both rate and size problems. For on-prem and hybrid estates this is common: a read-only replica or extract feeds search, dashboards and private AI, while ION carries the transactional integration that truly needs to be live. ## 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. ## Ai Angle Heavy AI reads belong off the live services. Netray typically points a private model at a governed extract or replica, so retrieval does not compete with transactional ION traffic. ERPray and DataRay can run on-prem against that copy, read-only, with the generated query visible for review. ## Faq ### What are the service limits in Infor OS? **Answer:** They cover request rate, payload or document size and processing time, and differ by service and release. Check current Infor documentation and confirm tenant-specific values with Infor support before designing. ### How do I handle large payloads in ION? **Answer:** Split them into business-sized documents, pass big files by reference through a document or file service, and process asynchronously with acknowledgements instead of one oversized message. ### What happens when a message is too large or fails? **Answer:** It is rejected or retried and may end up in an error or dead-letter state. Monitor those queues, fix the cause, and replay safely, which requires idempotent processing on the receiving side. ### Are Infor OS limits different on-premise? **Answer:** Cloud gateway limits do not apply to purely internal traffic, but the application server, database and network still bound throughput. Size and test them, and use extracts for heavy read workloads. ## Search terms infor os service limits, infor os limits, ion api payload limit, ion messaging size limit, infor ion timeout, ion document flow design, infor os architecture, ion dead letter --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json