Advanced Monitoring for Grist Core

Developers
1

Advanced Monitoring for Grist Core: API Limitations vs Direct File Access

Context

I’m working on implementing comprehensive monitoring for our self-hosted Grist Core instance for governance purposes. We need to track user actions, document history, and usage patterns across all documents in our organization.

Current Implementation

I’ve successfully created a monitoring solution that:

  • Uses the Grist REST API to access team sites and workspaces
  • Analyzes document history using the /sql endpoint to decode action history payloads
  • Stores monitoring data in DigDash
  • Works well for documents the API key owner has access to

The Problem

API Limitation: The Grist API only provides access to team sites accessible to the account associated with the API key. This means:

  • :white_check_mark: Can monitor: Team workspaces where the user is a member
  • :white_check_mark: Can monitor: The API key owner’s personal site
  • :x: Cannot monitor: Other users’ personal sites
  • :x: Cannot monitor: Team sites where the API user isn’t a member

For comprehensive governance monitoring, we need visibility into ALL documents across the instance.

Potential Solutions I’ve Identified

Solution 1: Admin API Key (Enterprise Only?)

Based on Grist’s admin controls documentation, there might be administrative API access, but this appears to be limited to Grist Enterprise, not Grist Core.

Solution 2: Direct File System Access

Since Grist Core stores documents as SQLite files in /persist/docs/, we could:

  • Read all .grist files directly from the file system
  • Parse SQLite databases to extract action history and metadata

Questions:

  • Has anyone implemented monitoring by directly accessing Grist’s SQLite filesin /persists/docs/ ?

Any insights, experiences, or alternative approaches would be greatly appreciated!

2 Likes