Audit Logs

This feature is currently in beta and only available to enterprise customers.

Overview

Audit logs provide a comprehensive tracking system for all changes to activities and reactions in your feeds. This feature is essential for:

  • Accountability - Track who made changes and when
  • Traceability - Follow the history of activities and reactions
  • Compliance - Meet regulatory requirements
  • Debugging - Troubleshoot issues with historical context

The audit logs feature requires no additional integration work. Once enabled for your app, audit logs are automatically populated by the Feeds API.

Audit Log Structure

Each audit log entry contains the following fields:

FieldDescription
entity_typeEither “activity” or “reaction”
entity_idThe unique identifier of the activity or reaction
actionThe type of action performed (see actions below)
user_idThe identifier of the user who performed the action
customAdditional contextual data related to the log entry
created_atTimestamp when the log was created
Audit log entries are immutable - they can only be created, not updated or deleted.

Supported Actions

Activity Actions

ActionDescription
createdActivity was created
updatedActivity was modified (includes previous version in custom data)
removed_from_feedActivity was removed from a feed (feed information in custom data)
deletedActivity was permanently deleted via data privacy endpoints

Reaction Actions

ActionDescription
createdReaction was created
updatedReaction was modified (includes previous version in custom data)
soft_deletedReaction was soft deleted
restoredReaction was restored after being soft deleted
deletedReaction was permanently deleted

Integration with the Moderation API

Audit logs seamlessly integrate with the Moderation API. When a moderator takes action on an activity or reaction from the dashboard, an audit log entry is automatically created with:

  • action: update_moderation_status
  • user_id: The ID of the moderator who performed the action from the Moderation Dashboard
  • custom: includes data about which action was performed

Some moderator actions will cause multiple audit log entries to be created. For instance a moderator marking a blocked reaction as reviewed (i.e OK to show) will cause two events. One update_moderation_status and one restored for restoring the reaction.

Attribution of Actions

The user_id in audit logs is determined as follows:

  • Client-side requests: The user ID is extracted from the JWT token
  • Server-side requests:
    • For activities: The user_id is the actor of the activity
    • For reactions: The user_id is the user_id field of the reaction

Querying Audit Logs

You can query audit logs using filters based on:

  • entity_type and entity_id combination
  • user_id
  • Or a combination of both approaches
// Get the latest 10 audit logs for activity with ID 123
filters := stream.QueryAuditLogsFilters{
  EntityType: "activity",
  EntityID:   "123",
}
pager := stream.QueryAuditLogsPager{
  Limit: 10,
}
resp, err := client.AuditLogs().QueryAuditLogs(context.Background(), filters, pager)
if err != nil {
  panic(err)
}
fmt.Println(resp.AuditLogs)

// Get the next 10 audit logs for activity with ID 123 (pagination)
pager.Next = resp.Next
resp, err = client.AuditLogs().QueryAuditLogs(context.Background(), filters, pager)
if err != nil {
  panic(err)
}
fmt.Println(resp.AuditLogs)

// Get the last 10 audit logs for user `foo`
filters := stream.QueryAuditLogsFilters{
  UserID: "foo",
}
pager := stream.QueryAuditLogsPager{
  Limit: 10,
}
resp, err := client.AuditLogs().QueryAuditLogs(context.Background(), filters, pager)
if err != nil {
  panic(err)
}
fmt.Println(resp.AuditLogs)
The maximum number of logs you can fetch in one API call is 100.
© Getstream.io, Inc. All Rights Reserved.