Skip to main content
In the API Traffic tab, the message traffic of the API Proxy can be viewed and filtered, and log records of each message can be examined. API Traffic Tab Each of the log records shown in the table belongs to a request coming from a client to this API Proxy and the response message given to that request. The following operations can be performed on this message.
Since WebSocket and gRPC requests are kept as data coming to and going from Apinizer, there are only 2 areas in these types of API Proxies.

​
Routing Address

This field holds the address information where the relevant API Proxy is routed. If this field is empty, it indicates that the request did not go to the backend address. Services using Apinizer as backend are shown with the “apinizer://” prefix, it will write exactly “apinizer://<COMPONENT_NAME>/<METHOD_NAME>”. This also applies to proxies where routing is closed to prevent going to backend. Possible values are;
Routing AddressCondition
apinizer://mirror.routing/<METOT_ADI>API Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy or No-Spec API and Routing option is closed and Mirror option is open
apinizer://specresponse.routing/<METOT_ADI>API Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy or No-Spec API and Routing option is closed and Mirror option is closed
apinizer://db2api.apicreator/<METOT_ADI>API Proxy type DB2API
apinizer://script2api.apicreator/<METOT_ADI>API Proxy type Script2API
apinizer://mockapi.apicreator/<METOT_ADI>API Proxy type Mock API
apinizer://connector/<METOT_ADI>API Proxy type Connector
apinizer://maintenanceAPI Proxy in maintenance mode
apinizer://cache/<METOT_ADI>In any API Proxy type and Caching is open
http://<BACKEND_ADRESİ>/<METOT_ADI> or https://<BACKEND_ADRESİ>/<METOT_ADI>API Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy, No-Spec API or KPS and Routing option is open
apinizer://specAPI Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy, No-Spec API and access to spec address
(Empty)Request cannot go to backend address for various reasons

​
Filtering

Search can be performed in 2 different types (Basic, Advanced) with the More options option In the Basic tab, filtering is applied to records with determined criteria such as a specific time range, endpoint, or HTTP method. Basic Filtering In the Advanced tab, users can create nested filters. Advanced Filtering Search can be performed with the following options in the Advanced tab. Advanced Filtering Options

​
Detailed View

The first one in the menu at the end of the row of the request message to be examined opens a window displaying the log records of that message. Detailed View In the window that opens, it is seen that logs are divided into sections related to message flow. When the name of the section to be examined (for example, the Request From Client to API Proxy section) is clicked, log records related to this area are displayed. By default, the Overview section is open. Detailed View Dialog

​
JSON View

The button below the Detailed View button displays log records in JSON format. JSON View The visual containing the dialog opened when JSON View is clicked is shown below: JSON Dialog
Key values in this field are written in a readable format, not as they are in the log file, to facilitate reading.For example, the “apiProxyId” value is kept as “api” in the log record, when the log record is downloaded, the actual log record will be displayed.For the actual log file format, you can examine the “Template Data Structure Table” on the Elasticsearch Manual ILM Policy and Template Creation page.

​
Download

It is also possible to download log records for more detailed examination. Download

​
Quick Test

The Quick Test button on the relevant row opens the Test Console formatted so that the sent request can be tested immediately by resending it. Quick Test
“Quick Test” button must be enabled in general settings to be visible.