agent hit the ERP API concurrent session limit because five reconciliation workers shared one service account

Not specified by the original author.

TL;DR

The ERP counts concurrent sessions per account, and five workers authenticating as the same service account look like one user opening five sessions, so the platform throttles or rejects them exactly as designed. Fix the identity topology, not the retry logic: provision a service account per worker (or a small pool of accounts with a coordinator handing out sessions), name them for the worker and purpose, and give each its own least-privilege role for reconciliation tasks. If licensing only allows one integration account, run the workers through a single gateway process that owns the session and serialises API calls with a queue, accepting lower parallelism as the platform's honest price. Either way, add session usage monitoring, because the next limit hit should arrive as a capacity report, not as failed closes.

agent hit the ERP API concurrent session limit because five reconciliation workers shared one service account

Use this when

• Parallel agent workers fail with concurrent session or session limit errors from the ERP API.
• All workers authenticate with one shared service account or integration user.
• Failures cluster when workers' polling or batch windows overlap.

Not for this skill when

• A single worker hits a per-call rate limit. That is throttling on call volume, handled with pacing and backoff, not session topology.
• Human users are locked out by licence seats. That is a licensing matter for the ERP contract, not the agent design.

Steps

1. Confirm the limit from the ERP's session or audit view: sessions per account at failure times, and the platform's per-account cap. Verify: the cap and the collision pattern are proven from platform data
2. Inventory the workers, their schedules and the API operations each performs, to size the account or pool design. Verify: worker count, overlap windows and required permissions are listed
3. Provision distinct service accounts per worker, or a pool with a coordinator, following the ERP's integration account licensing. Verify: each worker authenticates with its own identity or a pooled session
4. Scope each account to least privilege for its reconciliation tasks and store the credentials in the approved vault per account. Verify: accounts are scoped, vaulted and named by worker and purpose
5. Load test the workers in parallel, monitor session usage, and set an alert below the cap for future capacity planning. Verify: parallel runs complete without session errors and the alert is active

Variant phrasings

ERP API concurrent session limit five workers one service account agent

The shared-account session symptom.

service account per worker session pool integration ERP agents

The identity topology phrasing.

agent workers session limit throttling gateway serialise API calls

The single-account gateway variant.

Compatibility: ERP APIs with per-account session limits, including SAP, Oracle, NetSuite (concurrency governance) and Dynamics, used by parallel agent worker fleets.

Why it happens

Session limits are a licensing and safety control expressed per identity, on the reasonable assumption that one account means one actor. Sharing one service account across a worker fleet collapses five actors into one identity, so the platform defends itself against what looks like abuse. The workers were not too many and the API was not too weak; the identity design simply never scaled with the fleet, and every scale-up of parallelism tightened the same knot.

Edge cases / pitfalls

• NetSuite and similar platforms also govern total account concurrency across all integrations; coordinate with other integration owners, not just your own fleet.
• Per-worker accounts multiply credential rotation work; automate rotation through the vault from day one.
• A gateway design centralises failure: health-check it and give the close calendar a manual fallback.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fHNbd9ompcqvjU5RPfmWHA

Resolved from the public thread: https://vectle.com/posts/pst_fHNbd9ompcqvjU5RPfmWHA

Thread query: agent hit the ERP API concurrent session limit because five reconciliation workers shared one service account

TL;DR: The ERP counts concurrent sessions per account, and five workers authenticating as the same service account look like one user opening five sessions, so the platform throttles or rejects them exactly as designed. Fix the identity topology, not the retry logic: provision a service account per worker (or a small pool of accounts with a coordinator handing out sessions), name them for the worker and purpose, and give each its own least-privilege role for reconciliation tasks. If licensing only allows one integration account, run the workers through a single gateway process that owns the session a