Skip to main content
The Subscriptions API enables real-time updates for records using Server-Sent Events (SSE) or WebSockets, allowing clients to receive instant notifications when records are created, updated, or deleted. Base Path: /api/records/v1

Subscribe to Record Changes

Subscribe to real-time updates for a specific record.
GET /api/records/v1/{name}/subscribe/{record}

Path Parameters

string
required
Record API name (must have subscriptions enabled)
string
required
Record ID to subscribe to

Query Parameters

Filters can be applied to subscription queries using the same syntax as list queries:

Response (SSE Stream)

The endpoint returns an event stream with Server-Sent Events:

Event Types

Insert Event

Fired when a new record is created:

Update Event

Fired when a record is modified:

Delete Event

Fired when a record is deleted:

Error Event

Fired when an error occurs:

Connection Management

Keep-Alive

The server sends periodic keep-alive messages to maintain the connection:

Automatic Reconnection

Clients should implement automatic reconnection with exponential backoff:

Cleanup

Subscriptions are automatically cleaned up when:
  • Client disconnects
  • Connection times out
  • Table or record is deleted
  • Access permissions change

Access Control

Subscriptions respect the same access control rules as read operations.

Table-Level Access

Users must have Read permission to subscribe:

Row-Level Access

Subscription events are filtered by row-level access rules:

Real-Time Access Checks

Access is re-evaluated for each event:
  1. Record created/updated/deleted
  2. Access rule evaluated for current user
  3. Event sent only if access granted
  4. Subscription terminated if access permanently lost

Enabling Subscriptions

Subscriptions must be explicitly enabled in the Record API configuration:
Subscriptions only work on tables, not views. The underlying table must support SQLite’s update hooks.

JavaScript/TypeScript Client

Using EventSource (SSE)

Using WebSocket

WebSocket support requires the ws feature to be enabled in your TrailBase build.

React Hook Example

Filtering Subscription Events

Apply filters to receive only relevant events:
Filters use the same syntax as the Records list filtering.

Performance Considerations

Connection Limits

Each subscription maintains an open connection. Consider:
  • Server connection limits (configure via TrailBase settings)
  • Client browser limits (typically 6 connections per domain)
  • Database load from active subscriptions

Batching Updates

For high-frequency updates, consider implementing client-side debouncing:

Subscription Scope

Subscribe to the most specific resource:
  • ✅ Subscribe to individual records when possible
  • ⚠️ Table-level subscriptions may generate many events
  • ❌ Avoid subscribing to rapidly-changing records

Troubleshooting

Subscription Not Receiving Events

  1. Check if subscriptions are enabled in API config
  2. Verify authentication token is valid
  3. Confirm user has read access to the record
  4. Check if table (not view) is being used
  5. Verify filters aren’t excluding all events

Connection Drops Frequently

  1. Implement automatic reconnection
  2. Check network stability
  3. Verify server keep-alive settings
  4. Review server-side connection limits

Missing Updates

  1. Events are not guaranteed delivery (use SSE, not WebSocket for reliability)
  2. Check if updates occurred during disconnection
  3. Implement periodic polling as fallback
  4. Verify event filters aren’t excluding updates

Best Practices

  1. Implement reconnection logic with exponential backoff
  2. Clean up subscriptions when components unmount
  3. Use table-level subscriptions sparingly - they can be resource-intensive
  4. Filter events client-side if server-side filtering isn’t sufficient
  5. Combine with polling for critical data that can’t afford missed updates
  6. Monitor connection health with keep-alive messages
  7. Test access control to ensure users only see authorized data
  8. Limit concurrent subscriptions per client to avoid resource exhaustion

Error Responses

Forbidden
User doesn’t have read access or subscriptions disabled
Not Found
Record or API not found
Method Not Allowed
API doesn’t support subscriptions or uses a view instead of table