Configure API rate limits

Atria rate-limits selected API actions, including sign-in and other anonymously accessible actions. If an integration exceeds a configured limit, Atria returns HTTP 429 Too Many Requests.

Rate limits are configured on the Atria server. Use the section that matches the API processing the request.

API host	Configuration file
Platform API (current installation)	C:\Program Files\Automate101\Atria\PlatformApi\appsettings.Customer.json
Internal API hosted by WebForms	C:\inetpub\Automate101\Atria\WebForms\appSettings.config

Edit every API server

In a multi-server deployment, apply the same values to every server that can process the request. Back up each configuration file before changing it.

Platform API

The Platform API uses a token bucket for each source IP address. The default bucket contains 10 tokens and is replenished with 10 tokens every minute. Requests are rejected immediately when the bucket is empty because the default queue limit is zero.

Add a RateLimiter section to the update-safe customer override file:

C:\Program Files\Automate101\Atria\PlatformApi\appsettings.Customer.json

{
  "RateLimiter": {
    "TokenLimit": 60,
    "TokensPerPeriod": 60,
    "ReplenishmentPeriod": 1,
    "QueueLimit": 0
  }
}

If the file already contains other settings, add RateLimiter as another top-level property and keep the JSON valid.

Property	Purpose
TokenLimit	Maximum tokens the source IP can hold. This also controls the initial burst size.
TokensPerPeriod	Tokens restored at the end of each replenishment period.
ReplenishmentPeriod	Replenishment period in minutes.
QueueLimit	Requests allowed to wait when no token is available. Use 0 to reject them immediately.

For a steady limit of 60 protected requests per minute, set both TokenLimit and TokensPerPeriod to 60, with ReplenishmentPeriod set to 1.

Restart the Platform API service after saving the file:

Restart-Service -Name AtriaPlatformApi

Internal API hosted by WebForms

The legacy Internal API applies two fixed-window limits to each protected controller action:

• A per-client limit, keyed by the first IP address in X-Forwarded-For when that header is present, or by the direct client IP.
• A global limit across all clients handled by that WebForms process.

Edit the following file:

C:\inetpub\Automate101\Atria\WebForms\appSettings.config

Update or add these entries inside the existing <appSettings> element:

C:\inetpub\Automate101\Atria\WebForms\appSettings.config

<add key="Throttle.Limit" value="60" />
<add key="Throttle.PeriodSeconds" value="60" />
<add key="Throttle.GlobalLimit" value="1000" />
<add key="Throttle.GlobalPeriodSeconds" value="60" />

Property	Purpose	Product default
Throttle.Limit	Requests allowed from one client IP to one protected controller action during the period.	5
Throttle.PeriodSeconds	Per-client time window, in seconds.	60
Throttle.GlobalLimit	Requests allowed across all clients to one protected controller action during the global period.	100
Throttle.GlobalPeriodSeconds	Global time window, in seconds.	60

Set the global limit high enough to accommodate the combined legitimate traffic from all clients. A request can be rejected when either the per-client limit or the global limit is reached.

After saving the file, recycle Atria Management AppPool in IIS. From an elevated PowerShell session, you can use:

Restart-WebAppPool -Name 'Atria Management AppPool'

Choose appropriate limits

Increase limits only enough to support expected traffic. The settings apply only to actions on which Atria has enabled rate limiting; they do not impose a blanket limit on every API route.

For an integration that enumerates customers or users:

1. Authenticate once and reuse the API token or authenticated session instead of signing in before every request.
2. Use paging when the endpoint supports it.
3. When Atria returns 429, pause before retrying. The Platform API supplies a Retry-After header when retry timing is available.
4. Avoid parallel request counts that exceed the per-client or global limit.

Test the new values with the integration after restarting the affected application. If 429 responses continue, confirm which API host handled the request and verify that every server in the deployment has the same configuration.