# Infor OS Usage Limits: What They Are and What to Do When You Hit Them

> Source: https://netray.co/erp-help/infor-os-usage-limits-api-throttling-what-to-do
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Infor OS limits how hard clients can call its services, most visibly through the ION API gateway, and answers over-limit calls with HTTP errors such as 429 rather than silently dropping them. Exact numbers depend on your tenant and contract, so confirm them with Infor, then fix the cause: chatty clients, missing caching, or polling that should be an event.

## Kind

how-to

## System

infor-os

## Erp

Infor OS

## Module

ION API gateway / usage

## Query

infor os usage limits

## Alternate Queries

- usage limit infor os
- infor ion api rate limit 429
- infor os throttling

## Applies To

Infor OS multi-tenant (CloudSuite) and ION API; limits and quotas are tenant and agreement specific, so treat any figure you see elsewhere as unverified

## Steps

### How to diagnose and respond to Infor OS usage limits

**Items:**

- Capture the exact failing response: HTTP status, response body and headers, and the time. A 429 means throttling; 401 or 403 is authentication or permission, not a usage limit.
- Identify the caller from the ION API client registration (the ionapi file or service account in use), so you know which integration is consuming the allowance.
- Count calls per minute and per hour from your own client logs and compare to when errors begin. Bursts, not averages, usually trigger throttling.
- Look for the common waste: polling loops, one call per record in a loop, repeated token requests, and retries without backoff.
- Fix the client: batch where the API supports it, cache reference data, reuse access tokens until they expire, and add exponential backoff with jitter on 429.
- Where polling is used to detect change, replace it with an event or an ION document flow so the system pushes instead of being asked.
- If the load is legitimate, ask Infor support or your account team what the documented allowance is and whether it can be raised for your tenant.

## Sections

### What a usage limit looks like in practice

**Body:**

Limits in a shared platform are protection for every tenant. They show up as rejected requests with a status code and sometimes a retry hint, not as a slow degradation. That is useful: the failure is explicit and countable.

Do not guess numbers. Published or forum-quoted limits change by service and release. Read the current Infor OS documentation for your product, and ask Infor for the figures that apply to your tenant, then record them next to the integration that depends on them.

### Designing clients that stay under the limit

**Body:**

The cheapest call is the one you do not make. Cache slow-changing data such as items, customers and units of measure, and refresh on a schedule or on a change event. Request only the fields and rows you need, and page through large lists with the documented paging parameters rather than pulling everything each time.

Treat 429 as normal. Retry with exponential backoff and jitter, cap the number of retries, and put a queue in front of bursty producers so a nightly batch does not compete with interactive users. Make operations idempotent so a retry cannot create a duplicate.

**Code:**

retry policy (pseudocode):
for attempt in 1..5:
  resp = call()
  if resp.status != 429: return resp
  wait = min(60, 2 ** attempt) + random(0, 1)
  sleep(wait)
fail and alert

### On-prem and hybrid considerations

**Body:**

If part of your estate is on-premise, calls that stay inside your network are not subject to a cloud gateway limit, but they are still bounded by the capacity of the application server and database. Moving a heavy analytics or AI read workload to a replica or an extract keeps it off the transactional path.

That is also a good pattern for AI workloads, which tend to issue many small reads. A private model that queries a governed copy of the data does not consume your ION API allowance and does not add load to the live ERP.

## Pitfalls

- Treating a 401 or 403 as a rate limit and adding retries that never succeed.
- Requesting a new access token for every call instead of reusing it until expiry.
- Retrying immediately and in lockstep, which turns one throttle into a storm.
- Quoting limits from a forum post instead of confirming them for your tenant.
- Sharing one service account across many integrations so you cannot see which one is consuming the allowance.

## Ai Angle

AI agents are chatty by nature, so they are exactly the clients that hit limits. A well-built agent plans its reads, caches results within a conversation and queries a read replica or extract instead of looping over the API. ERPray works read-only and shows each query it runs, which makes call volume visible and easy to tune.

## Faq

### What are the Infor OS usage limits?

**Answer:** They depend on the service, release and your agreement, so there is no single universal number. Confirm the current limits in Infor documentation or with Infor support for your tenant and write them down against each integration.

### What does an Infor OS rate limit error look like?

**Answer:** Typically an HTTP 429 Too Many Requests response from the gateway. Authentication problems appear as 401 or 403 instead. Check the status code and body before assuming throttling.

### How do I avoid hitting the limit?

**Answer:** Cache reference data, batch calls, reuse access tokens, page properly, back off on 429 and replace polling with event driven flows. Spread scheduled jobs across the day instead of running them at the same minute.

### Can the limit be raised?

**Answer:** Sometimes, for a legitimate workload. Raise it with Infor support or your account team with the integration name, call pattern and business reason. Fix wasteful calls first, because that is faster and free.

## Search terms

infor os usage limits, usage limit infor os, ion api rate limit, infor ion api 429, infor os throttling, ion api quota, infor os api limits, ionapi retry backoff

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
