System Audit Logs

Audit Logs record every API call, providing a record of actions conducted within Veza. Depending on your use case, you can export a continuous list of events, or get events matching a filter, newest first by default. Developers, administrators, and security teams can use these requests to:

• Integrate Veza with an SIEM platform or other auditing tools

• Detect potential inappropriate access or usage

• Get insight into how users are interacting with the Veza platform

See for more details about the audit event object.

You can also browse audit events in the Veza UI. See .

Responses will include a next_page_token. Use this page_token in the request query to get the next batch of results.

Setting a page size is required for requests. The maximum page size is currently 10,000 records.

This endpoint supports filtering by ended_at timestamp, method, user_id, url, outcome (SUCCESS or FAILURE), and action_name. The endpoint returns the newest events first. To return the oldest events first, set order_by=asc on the first request. Later pages keep the order of the first request.

You must include an ended_at GE filter that starts no earlier than 90 days ago. To set an upper bound, add an ended_at LT filter. The ended_at filter and the result order use the time the audit log stored each event, which can be later than the event's ended_at value. As a result, a filtered list can include events whose ended_at value is earlier than the filter value, and the order can differ from ended_at order.

In the examples, replace <TIMESTAMP> with an RFC 3339 time within the last 90 days, in the form YYYY-MM-DDThh:mm:ssZ.

Example:

To list the actions of a single user, add a user_id filter with the user's Veza user ID (the identity.user_id value in their audit events). The results include calls made with API keys that the user owns.

To list only failed actions, add an outcome filter. Set it to FAILURE for requests that returned an error, or SUCCESS for requests that succeeded. The values are case-sensitive.

To list the events for one action, add an action_name filter with the action's name, such as Create API Key. The filter supports only EQ, and the value is case-sensitive. Use a name returned by . Events recorded without an action name don't match, even though the API returns a name derived from the endpoint for them.

Returns the action names you can use in the action_name filter of . It requires the same role as listing audit events and returns the names sorted alphabetically.

Returns a paginated list of events, intended for exporting entries into an external log management system.

To ingest events as they become available without skipping any entries, first make a call with a persisted_at GE "<TIMESTAMP>" filter. Then, continuously call the next page. If the first call has no filter, the export starts 24 hours ago.

If you request the next page within a minute of a page that returned no entries, the export endpoint returns the error code ResourceExhausted (error reason SYSTEM_AUDIT_EXPORT_BACKOFF). Wait a minute before retrying the request.

In the example, replace <TIMESTAMP> with an RFC 3339 time within the last 90 days, in the form YYYY-MM-DDThh:mm:ssZ.

Example:

An event describes an API-level action, including the IP address and user agent of the caller. Requests can originate from user sessions, or from applications using API keys. The following is a sample event for a successful API key generation:

• request and response both only contain some whitelisted fields. Due to size limitations, the entire message is not recorded.

The following fields give a human-readable summary of the action. These are the fields surfaced in the UI.