/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 haveRead 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:- Record created/updated/deleted
- Access rule evaluated for current user
- Event sent only if access granted
- Subscription terminated if access permanently lost
Enabling Subscriptions
Subscriptions must be explicitly enabled in the Record API configuration: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: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
- Check if subscriptions are enabled in API config
- Verify authentication token is valid
- Confirm user has read access to the record
- Check if table (not view) is being used
- Verify filters aren’t excluding all events
Connection Drops Frequently
- Implement automatic reconnection
- Check network stability
- Verify server keep-alive settings
- Review server-side connection limits
Missing Updates
- Events are not guaranteed delivery (use SSE, not WebSocket for reliability)
- Check if updates occurred during disconnection
- Implement periodic polling as fallback
- Verify event filters aren’t excluding updates
Best Practices
- Implement reconnection logic with exponential backoff
- Clean up subscriptions when components unmount
- Use table-level subscriptions sparingly - they can be resource-intensive
- Filter events client-side if server-side filtering isn’t sufficient
- Combine with polling for critical data that can’t afford missed updates
- Monitor connection health with keep-alive messages
- Test access control to ensure users only see authorized data
- 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