Access the General Settings screen by following Management → System Settings → General Settings. Click the Apply Changes button to save your changes.



General Settings Configuration
The fields used for General Settings configuration are shown in the table below:| Field | Description |
|---|---|
| API Root Context | Field where the Root Context required for API Proxy access is entered. Can only be left as /. Default value: apigateway/ |
| Enable the management of Kubernetes Namespace and Resources with Apinizer (Enable the management of Kubernetes Namespace and Resources with Apinizer) | If this setting is on (default value); All Namespace, Deployment and Service information required for Gateway and Cache Servers are created using the information that Apinizer defines as standard through the API Manager screen, and only Kubernetes definitions allowed through API Manager are made. Update etc. operations are performed through API Manager. If this setting is off; All Namespace, Deployment and Service information required for Gateway and Cache Servers are created using the information that Apinizer defines as standard through the API Manager screen, and only Kubernetes definitions allowed through API Manager are made. Update etc. operations are performed through API Manager. |
| Define your API Integration (Task Flow) Module (Define your API Integration (Task Flow) Module) | The URL address used to access the API Integration (Task Flow) Module from API Manager. This field connects the API integration module with API Manager. |
| Enable logging disabled fields in case request is blocked by policy (Enable logging disabled fields in case request is blocked by policy) | If this setting is on (default value); If the policy prevents the request from being forwarded to the backend, all request and response fields are sent to the Log Connector even if the log options for the relevant API Proxy are closed. For example, when a message is blocked by an authorization policy, and the log record of the incoming message is closed, it cannot be known who tried to make unauthorized access. When this setting is on, even for fields with closed log records in unauthorized accesses, logs can be kept to find who the request came from. This feature is an effective method that activates log recording to understand special situations only in special cases without storing fields with closed log settings in normal situations. |
| Enable logging disabled fields in case of Failure or Error at any policy (Enable logging disabled fields in case of Failure or Error at any policy) | If this setting is on (default value); If there is any error in the request or response line, all request and response fields are sent to the Log Connector even if the log options for the relevant API Proxy are closed. For example, when a message gets an error due to the content of the script in the script policy, and the log record of the incoming request is closed, it cannot be known which data in the message caused this error. When this setting is on, even for fields with closed log records in error situations, logs can be kept to find which situation in the message led to this result. This feature is an effective method that activates log recording to understand special situations only in special cases without storing fields with closed log settings in normal situations. |
| Enable Quick Test on API Traffic Log Records (Enable Quick Test on API Traffic Log Records) | If this setting is on (default value); The feature that allows you to make requests again with the request message sent by the client on the API Traffic logs page is enabled. |
| Enable API Traffic Log Details (Enable API Traffic Log Details) | If this setting is on (default value); Detailed view, JSON view and download buttons are displayed on the API Traffic logs page. When disabled, users cannot access detailed log information, JSON view or download log records. |
| Enable Management APIs (Enable Management APIs) | When this option is enabled (enabled by default); You can perform many operations without needing the screen application with Management APIs, and integrate Apinizer into your DevOps environment. |
| Multi Login Settings (Multi Login Settings) | This setting is activated to allow users to log in from different locations and different tabs of their browsers. |
| Enable Hostname Verification For Secure Connections (Enable Hostname Verification For Secure Connections) | If enabled, it checks the common name (CN) and subject alternative names (SANs) of the server certificate to ensure that the hostname matches in SSL/TLS Connections, otherwise hostname verification is disabled in SSL/TLS connections. |
| Total Incorrect Logins Allowed for Captcha Validation (Total Incorrect Logins Allowed for Captcha Validation) | The number of incorrect login attempts the user must make before Captcha verification becomes active during login to the management console is entered. Default value is set to 3. |
| Total Number of Incorrect Logins Allowed with Captcha Verification to Lock Login (Total Number of Incorrect Logins Allowed with Captcha Verification to Lock Login) | The number of incorrect Captcha verifications that can be made to lock user login during login to the management console is entered. Default value is set to 7. |
| Determine the period during which a user can remain inactive in Apinizer (Determine the period during which a user can remain inactive in Apinizer) | The time a user can stay in the application after logging into the management console without performing an active operation (click, scroll, etc.). It is in seconds. This field consists of two parts: Idle Time (Idle Time): Default value is set to 92000. Idle Timeout (Idle Timeout): When the idle time expires, it is the waiting time of the dialog that presents the user with Stay or Log Out options. It is in seconds. Default value is set to 5. |
| Navbar Color (Navbar Color) | Apinizer navbar color can be determined according to the hex code entered here. This especially facilitates distinguishing environments for those using multiple Apinizer Management Consoles. |
| Total History Count of API Proxy’s Revision (Total History Count of API Proxy’s Revision) | Information about how many deployment information will be stored in the database when API Proxy is deployed or undeployed each time is entered. Used for rollback through deployment history on an API Proxy basis. Fixed historical values are not included in this number. Default value is set to 6. |
| Maximum number of elements to be created in XML (Maximum number of elements to be created in XML) | The maximum number of elements that the XML to be created can have when generating sample XML from WSDL is entered. |
| The depth number of nested levels of elements to be created in XML (The depth number of nested levels of elements to be created in XML) | The number of nested levels that the elements of the XML to be created can have when generating sample XML from WSDL is entered. |
| Maximum message size of the generated XML in KB (Maximum message size of the generated XML in KB) | The maximum size in KB that the XML to be created can have as message size when generating sample XML from WSDL is entered. |
| Write application logs to the Apinizer configuration database (Write application logs to the Apinizer configuration database) | According to the logging settings in the Api Manager application, logs related to the application flow in the application container and are deleted when the relevant container is closed or restarted. With this setting, it is determined whether this logged data will be kept in Apinizer’s configuration database. If you select this setting as on (default value); The relevant logs will be kept in the Apinizer configuration database and will be viewable on the Application Logs page. If you select this setting as off; The relevant logs will not be kept in the Apinizer configuration database and will not be viewable on the Application Logs page. |
| Write application logs to other targets (Write application logs to other targets) | Connector selection can be made in this field to send these logs to another application with the help of a specific connector, independently of writing application logs to the Apinizer configuration database. |
| Write token logs to the Apinizer configuration database (Write token logs to the Apinizer configuration database) | According to the logging settings in the Api Manager application, data flows in the application container and are deleted when the relevant container is closed or restarted. With this setting, it is determined whether this logged data will be kept in Apinizer’s configuration database. If you select this setting as on (default value); The relevant logs will be kept in the Apinizer configuration database and will be viewable on the Token Logs page. If you select this setting as off; The relevant logs will not be kept in the Apinizer configuration database and will not be viewable on the Token Logs page. |
| Write token logs to other targets (Write token logs to other targets) | Connector selection can be made in this field to send these logs to another application with the help of a specific connector, independently of writing token logs to the Apinizer configuration database. |
| Write audit logs to the Apinizer configuration database (Write audit logs to the Apinizer configuration database) | According to the logging settings in the API Manager application, data flows in the application container and are deleted when the relevant container is closed or restarted. With this setting, it is determined whether this logged data will be kept in Apinizer’s configuration database. If you select this setting as on (default value); The relevant logs will be kept in the Apinizer configuration database and will be viewable on the Audit Logs page. If you select this setting as off; The relevant logs will not be kept in the Apinizer configuration database and will not be viewable on the Audit Logs page. |
| Write audit logs to other targets (Write audit logs to other targets) | Connector selection can be made in this field to send these logs to another application with the help of a specific connector, independently of writing audit logs to the Apinizer configuration database. |

