Skip to main content
The DDL commands on this page use Apinizer’s default table names (log_ApiProxyTraffic, log_PolicyCapture, log_AuditEvent, log_Application, log_UnsentMessage, log_TokenTraffic, log_LoginLog) and no schema prefix.If you prefer a custom schema or custom table names, configure them in the Log Target Usage — Table Schema section of the connection definition. You can rename the table or add a schema prefix in your DDL, but column names and data types must match exactly — otherwise log inserts will fail with column-not-found errors.Especially on Oracle, if you use case-sensitive table names (e.g. CREATE TABLE "HR"."logtablosu"), you must enter the table name inside double quotes in the connection definition.See Database Connection for details.
Apinizer can store traffic and audit records in relational databases using DB Connector. The following tables are prepared with appropriate data types for each supported database type.
Column names are identical across all database types (snake_case). Only the data types differ per database.

API Proxy Traffic Log

The main table where all HTTP traffic passing through API Proxy is recorded.
This is the highest-volume log table. The following indexes cover the most common query patterns (end-to-end tracing, time-range scans, proxy/project filtering, error analysis).

Partitioning

This table grows very quickly under production traffic. Daily partitioning on log_timestamp is strongly recommended so that retention can be applied via DROP PARTITION and time-range queries prune inactive partitions. See Partitioning Syntax for database-specific examples.

Token Traffic Log

The table that records OAuth/JWT token operations.
Token operations are frequently investigated per user/application and per time window. Correlation joins with the API traffic table are also common when tracing an end-to-end call.

Partitioning

Token volumes usually scale with API traffic volumes. Daily partitioning on log_timestamp is recommended. See Partitioning Syntax.

Policy Capture Log

The table that stores request details recorded in policy capture mode.
When the log policy is placed at multiple pipeline stages (for example, FROM_CLIENT and TO_CLIENT), request and response rows share the same correlation_id. The correlation_id index is therefore essential for joining request and response records end to end.

Partitioning

Volume depends on how many log policies are attached to flows and how often they fire. For policies attached at proxy/method scope on high-traffic APIs, daily partitioning on log_timestamp is recommended. See Partitioning Syntax.

Application Log

The table that stores platform-level application logs.
Application logs are commonly filtered by time range and log level (for troubleshooting), and joined with traffic logs via correlation_id to reconstruct a single request’s platform-level events.

Partitioning

Application logs accumulate steadily. Daily partitioning on log_timestamp is recommended on production systems. See Partitioning Syntax.

Audit Event

The table that stores audit records of user operations.
Audit queries most often filter by date range, user (principal), affected object type, or project. The partition key here is audit_event_date, not log_timestamp.

Partitioning

Audit events are generated by user actions (far fewer than traffic rows) and are usually retained for longer periods for compliance. Monthly partitioning on audit_event_date is typically sufficient. See Partitioning Syntax and substitute MONTH for DAY in the interval.

Login Log

The table that stores login attempts to the API Manager and API Portal (success and failure events).
Login logs are queried by time range, user (email/principal), login source, and event type (for security auditing and locked-account investigation).

Partitioning

Login log volume is typically low compared to traffic logs. Monthly partitioning on log_timestamp is sufficient for long retention periods commonly required for security audit. See Partitioning Syntax and substitute MONTH for DAY in the interval.

Unsent Message

The table that temporarily stores log records that could not be delivered due to connection errors.
Rows in this table are transient: they are inserted when a connector is unreachable and removed when delivery succeeds. A small number of indexes is sufficient for resend lookups and cleanup.

Partitioning

This table holds transient records that are normally consumed within a short time window. Partitioning is not required. If the table grows unexpectedly (prolonged outages), operational cleanup is a better remedy than partitioning.

Partitioning Syntax

The examples below show daily partitioning on log_timestamp. Substitute the actual table name and adjust the initial boundary date to suit your deployment. For the log_AuditEvent table, replace log_timestamp with audit_event_date and use a monthly interval instead.
New daily partitions must be created in advance (for example, via a scheduled job). If the next partition does not exist when a record arrives, inserts will fail on SQL Server and MySQL, and Oracle will auto-create only when INTERVAL partitioning is used.

Data Type Mapping Table

The following table shows the data type mappings between different databases.