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

How to diagnose and respond to Infor OS usage limits

1. 1Capture 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.
2. 2Identify 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.
3. 3Count calls per minute and per hour from your own client logs and compare to when errors begin. Bursts, not averages, usually trigger throttling.
4. 4Look for the common waste: polling loops, one call per record in a loop, repeated token requests, and retries without backoff.
5. 5Fix 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.
6. 6Where polling is used to detect change, replace it with an event or an ION document flow so the system pushes instead of being asked.
7. 7If 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.

Designing clients that stay under the limit

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

Common 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.