Audit entities (technical preview)

Use the audits resource to review create, update, and delete operations across site, space, shared-area, and workspace contexts.

Overview

Audit data helps administrators track changes for security and compliance use cases.

The audits resource is cross-entity, so one request can return events for multiple entity types.

Because this is a technical preview resource, include the ALM-OCTANE-TECH-PREVIEW request header with the value true in all audits API requests.

Only users with the required admin roles and permissions in the target context can access audit data.

This resource is available to site and space admins, including admins with data-access restrictions.

Note: As a technical preview, this resource is subject to change.

Results are capped at 10,000 records by default. The MAX_LIMIT_ELASTIC configuration parameter can lower this cap, but cannot raise it.

URIs by context

Context URI
Space

.../api/shared_spaces/<space_id>/audits

Examples include workspaces, users, and API access.

Shared area

.../api/shared_spaces/<space_id>/shared_area/audits

Examples include releases.

Workspace

.../api/shared_spaces/<space_id>/workspaces/<workspace_id>/audits

Examples include teams, work items, and tests.

Build audit queries

Use the query clause to filter results. Separate query conditions with semicolons (;), which act as logical AND.

Supported query items

Query item Purpose
entity_type Filter by audited entity type, for example story, feature, or pipeline. For configuration parameters, use configuration_parameter.
entity_id Filter by specific entity ID.
field_name Filter updates to a specific field.
action Filter by operation type: create, update, or delete.
user_id Filter by the user who made the change. Use site user ID at site level, and space user ID at space/workspace levels.
timestamp Filter by time range, for example with GE and LE operators.

Notes:

  • If you omit query, the API can return all operations for all auditable entities in the context. Always filter to reduce payload size and improve performance.

  • You can combine standard collection clauses, such as limit, offset, and fields, with query.

  • Explicitly set the fields clause. If you omit fields, the response can return a minimal projection (for example, only "type": "audit" for each event).

  • Users with data visibility restrictions, must include both entity_type and entity_id in the query.

  • Only auditable entities and auditable fields are returned by this resource. To see whether an entity can be audited, check the non-auditable feature in Entity metadata reference. To see whether a field is auditable, check the non-auditable feature in Field metadata reference.

Request examples

The following examples show common audit request patterns with explicit fields and query clauses.

Audit all deletions since a specific date

GET .../audits?fields=action,entity_type,entity_id,timestamp,user_id,change_set&query="action EQ ^delete^;timestamp GE ^2019-01-01T20:59:59Z^"

Audit all operations for one entity (include both type and ID)

GET .../audits?fields=action,entity_type,entity_id,timestamp,user_id,user_name,workspace_id,entity_physical_id,session_id,change_set&query="entity_type EQ ^epic^;entity_id EQ 1125"

Audit one user

GET .../audits?fields=action,entity_type,entity_id,timestamp,user_id,change_set&query="user_id EQ 2002"

Audit multiple attributes in one request

GET .../audits?fields=action,entity_type,entity_id,timestamp,user_id,change_set&query="entity_type EQ ^story^;entity_id EQ 2004;field_name EQ ^severity^;action EQ ^update^;user_id EQ 8987"

Response field highlights

Each result is an audit event. Use fields to return only the fields you need.

A single response can include multiple audit events for the same entity, such as create, update, and delete operations.

Common fields returned in audit events: action, entity_type, entity_id, timestamp, user_id, user_name, workspace_id, change_set.

  • Create actions: Each field that received a value during the create is listed in the change_set attribute.

  • Update actions: Each field that was updated is listed in the change_set attribute. Fields receiving values for the first time during the update are listed with their current value. For fields whose values were modified, both the old and the current values are listed.

Common audit event schema

{
    "type": "audit",
    "workspace_id": 1002,
    "entity_physical_id": 1125,
    "entity_type": "epic",
    "user_id": 1001,
    "user_name": "user@thecompany.com",
    "action": "create",
    "session_id": "$1$XHYKNW1C$IhyU1Zzj7N0rlfLwoeWGQ0",
    "entity_id": "1125",
    "timestamp": "2018-12-13T11:18:42Z",
    "change_set": [
        {
            "field_name": "...",
            "value": "..."
        }
    ]
}

change_set patterns

Create pattern

"change_set": [
    {
        "field_name": "name",
        "value": "Epic 1"
    },
    {
        "field_name": "phase",
        "value": "phase.epic.new"
    }
]

Update pattern

"change_set": [
    {
        "field_name": "phase",
        "old_value": "phase.epic.new",
        "value": "phase.epic.inprogress"
    },
    {
        "field_name": "story_points",
        "value": "10"
    }
]

Note: If an automated rule changed an entity, the event can include rule_changer_id in addition to the user who triggered the rule.

See also