Open the unified System Settings screen with the System Settings & Limits link in the user profile menu. This screen presents the platform's configuration parameters, default limits, and system constraints grouped across 8 tabs. A ninth tab, AI Gateway, appears when your license includes the AI Gateway.
Warning
Only users with the Administrator (Admin) role can access this screen. Since settings take effect platform-wide, they should be configured carefully.
The unified System Settings page brings together some General Settings fields, System Properties, gateway runtime parameters, and system constraints in a single interface. Each setting has a scope badge:
Scope
Color
Description
Deploy Required
Orange
Saved to the database; applied to all gateway nodes after deploy
Restart Required
Blue
Configured via environment variable / YAML in the Kubernetes deployment. The screen shows the value defined in the environment settings, or the default value if none is defined; a pod restart is required to change it
Fixed
Gray
Infrastructure limit that cannot be changed
Deploy Required settings can be changed directly on the screen with the corresponding input components (number, text, toggle, etc.). Restart Required and Fixed items are read-only on the screen.
This tab contains settings that control how API requests are routed to backend servers and how connections are configured. All settings in this tab are Deploy Required (except Hop-by-Hop Headers).
When Relative redirect allowed is off and the backend returns a Location header holding a relative address, the redirect is not followed and the request ends with an explicit redirect error. Absolute addresses — including http→https transitions — are unaffected by this setting.
On the HTTP/2, streaming (SSE) and server-stream transports, Max redirects is enforced as min(setting, 20): those transports use OkHttp, whose own follow-up cap is 20 and cannot be raised. A value above 20 therefore takes effect as 20. The HTTP/1.1 transport enforces the configured value in full.
Idle Warning After — inactivity period before the session-expiry warning appears in the Manager UI
235 s
1 - 999,999 s
Auto-Logout Countdown — countdown shown in the warning dialog before automatic logout
5 s
1 - 999,999 s
Failed login attempts are counted per user on the server; the account is locked once the consecutive failures reach the sum of captcha attempts allowed and user lock attempts allowed (3 + 7 = 10 by default), and the lock is shown and can be lifted under Users → Locked. The captcha threshold is applied by the login page itself: after that many consecutive failures in the same browser page a CAPTCHA appears. It is a client-side deterrent against casual retries, not a security control — the lock is the control. The login screen never says which case applies: an unknown user name, a wrong password, a locked or inactive account and a failed LDAP check all receive the same Username or password is incorrect answer, and the number of remaining attempts is not displayed. Revealing any of that to a caller who has not signed in would let them discover which accounts exist (user enumeration). The exact reason is still recorded for administrators in Login Logs.
Environment variables that set the CORS headers for the token endpoint. Their default values are empty; if a value is defined in the environment settings, the screen shows that value.
Log retention settings are not shown on this screen.
Log retention settings determine storage duration and maximum record counts for different log types. Separately configurable for all log types (traffic, application, token, audit, login), including Identity Synchronization History — the durable run-by-run log described in Provider Synchronization, disabled by default so no run record is deleted until an administrator turns it on. API Security Events — the bodyless record of Gateway requests blocked by a policy or failed with an error, described on the Security Events page — is likewise disabled by default. Lifecycle Purge Run History — the record of finished Data Lifecycle Purge runs — is likewise disabled by default (365 days once enabled); a run still in progress is never eligible for cleanup regardless of this setting.
Log Retention above decides how long log records are kept; the Data Retention Profile answers a different question — whether a request's body/headers get captured at all. There are three profiles, increasing in strictness:
Profile
Label on screen
Behavior
STANDARD
Standard
Today's behavior — body/header capture, persistence, and tracing all work normally per your existing settings
NO_PAYLOAD
No Payload
Request/response headers, query string, and body are never captured — not scrubbed afterward, simply never populated. Starting Live Trace is locked under this profile; not even an authorized user can turn it on
NO_PERSIST
No Persist
Everything No Payload restricts, plus no record at all is sent to connectors, the Mongo trace store, or OTel spans. Tracing is locked here too
Counter and metric flows (Prometheus, quota counters) are unaffected by all three profiles — these profiles only stop persistent record creation, not counting.
Not the Same as In-Memory Data
These profiles prevent persistent/external record creation. While a request is being processed, the data still exists temporarily in JVM memory (for example, while being forwarded to the backend) — these profiles do not establish a claim that "no trace exists even in memory," only that "no persistent/external record is created."
The profile can be set at three levels: the global level on this page, the project settings level, and the API proxy's traffic log settings level. The effective profile is the strictest of the three levels — a lower level can never choose a looser profile than the level above it: a project can match the global profile or be stricter than it; a proxy must likewise match or exceed the effective profile it inherits (global + project). Choosing a looser profile is rejected on save.
This cascade isn't just a UI convenience — the gateway computes the effective profile at runtime with the same strictest-wins logic, so trying to bypass a higher level outside the UI (for example, updating a proxy's setting directly through APIops) has no effect.
The global-level Data Retention Profile is set on the General Settings screen, not on this screen.
Installation-wide defaults for the circuit breaker that protects log delivery over Kafka, RabbitMQ, ActiveMQ, Graylog, Webhook, and database (DB) connections. This section is independent of the Routing circuit breaker on Tab 1 — that one governs requests routed to backends; this one only covers connector log delivery.
Parameter
Default
Configuration Range
Scope
Circuit Breaker Enabled
Disabled
-
Deploy Required
Error Window
10 s
1 - 3,600 s
Deploy Required
Error Threshold
5
1 - 10,000
Deploy Required
Sleep Window
30 s
1 - 3,600 s
Deploy Required
Half-Open Attempt Enabled
Enabled
-
Deploy Required
Info
These five values are installation-wide defaults. Circuit Breaker Enabled, Error Threshold, and Sleep Window can be overridden per connection from the Resilience (Circuit Breaker) section on the Kafka, RabbitMQ, ActiveMQ, Graylog, Webhook, and database connection screens; fields left empty inherit the defaults configured here. Error Window and Half-Open Attempt Enabled are configured only here, installation-wide.
All parameters in this tab are Restart Required and read-only on the screen (Default Ports are Fixed). To change them, define them as environment variables and restart the pod.
This tab is shown only when your license includes the AI Gateway. It holds the platform-wide defaults of the AI Gateway: provider failover, connection pool, body size limits and the agentic tool-call loop. The sections are independent of each other. New LLM Gateways start with these values, and each LLM Gateway can override them on its own Routing tab. The How to read? button opens a short explanation of the sections. Token and cost limits are not set here; define them in Limit Plans.
The tab has its own Save and Cancel buttons. Only a system administrator can save this tab. Other users who can open it see the values read-only.
Used by LLM Gateways whose connection pool type is General. Each LLM provider of a gateway gets its own pool, and these values apply to each provider separately. A change reaches an LLM Gateway on its next deploy.
Parameter
Default
Configurable Range
Idle Connections per Provider
64
1 – 1,000
Idle Connection Timeout (s)
4 sec
1 – 3,600 sec
Connections in use are not limited, and requests never wait for a connection. Keep the idle timeout below the provider's own keep-alive timeout. For details, see Connection Pool.
How many tool-call round-trips the gateway chains automatically when the model keeps requesting tools. One turn is: the model returns a tool call, the gateway calls the tool, the result is fed back to the model. After the last turn the loop stops and the last model response is returned to the caller. 0 disables the loop. This is a structural safety net, independent of any token or cost limit.
Changes are saved with the Save and Deploy button in the upper right corner of the screen. The system saves changes belonging to different data sources separately:
Deploy Required settings are saved to the database and deployed to the gateway nodes
Restart Required settings cannot be changed from this screen; they must be defined as environment variables and the relevant pod restarted