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:

Field	Description
`entity_type`	Either “activity” or “reaction”
`entity_id`	The unique identifier of the activity or reaction
`action`	The type of action performed (see actions below)
`user_id`	The identifier of the user who performed the action
`custom`	Additional contextual data related to the log entry
`created_at`	Timestamp when the log was created

Audit log entries are immutable - they can only be created, not updated or deleted.

Supported Actions

Activity Actions

Action	Description
`created`	Activity was created
`updated`	Activity was modified (includes previous version in `custom` data)
`removed_from_feed`	Activity was removed from a feed (feed information in `custom` data)
`deleted`	Activity was permanently deleted via data privacy endpoints

Reaction Actions

Action	Description
`created`	Reaction was created
`updated`	Reaction was modified (includes previous version in `custom` data)
`soft_deleted`	Reaction was soft deleted
`restored`	Reaction was restored after being soft deleted
`deleted`	Reaction 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.

Batch Endpoints

Personalization Introduction