How It Works
This page explains how Entrig connects to your Supabase project, what access it uses and why, and how a database event becomes a push notification on a user’s device.
Web Portal
SDK
How does Entrig connect to your database?
Entrig connects to your Supabase project via OAuth. Once authorized, it uses the Supabase Management API to set up what it needs. See Write access below.
What access Entrig requests
During OAuth, Supabase shows you exactly what is being granted:
- Read and Write access to Postgres configurations, SQL snippets, SSL enforcement configurations, and TypeScript schema types
- Read access to project metadata, upgrade status, network restrictions, and network bans
Write access
Used for setup only, never to write to your data:
| When | What |
|---|---|
| On connect | Enables pg_net and supabase_vault, creates the entrig schema, stores a secret key in your vault |
| Per notification | Creates a trigger function on the table and event you configure |
We never write to any of your existing tables.
Read access
Schema: Entrig reads your database schema (tables, columns, and foreign key relationships) to display your data model in the dashboard when you configure notifications.
Data: The trigger sends the changed row to Entrig as part of the event. If your notification needs additional data beyond that (columns from a related table, or recipients from a relationship table), Entrig queries only those specific columns. Only SELECT queries run, only what you configured is read, and the data is discarded once the notification is sent. Nothing is stored.
A note on database access
Giving a third-party tool access to your database is a significant decision. Here is what we have done on our end:
- The OAuth access token is encrypted and never exposed in logs or responses
- Every query Entrig runs is built internally. There is no way to inject custom SQL through notification configuration or any other input
- All table and column names are validated before use. Values are escaped. Only a known set of operators is permitted
- Queries are restricted to
SELECT. Any other operation is rejected before it reaches your database
How does a database change reach Entrig?
When you create a notification, Entrig creates a PostgreSQL trigger on the table you choose. That trigger fires on the event you select: INSERT, UPDATE, or DELETE.
Here is what happens in order:
- Your app writes to Supabase
- The trigger fires and writes an event record to the
entrigstaging table pg_netpicks it up and sends an HTTP POST to Entrig’s servers, authenticated using the key stored in your vault- Entrig receives the event and starts processing
This is why pg_net is required. Entrig cannot poll your database, so the database must call Entrig. pg_net is what makes that possible.
How does Entrig know who to notify?
Entrig maps a user in your database to a device token. This works in two parts:
Device token registration
When a user opens your app, the app collects the device token (FCM on Android, APNs on iOS) and sends it to Entrig along with that user’s ID. Entrig stores this mapping.
User ID resolution
When creating a notification, you configure which field on the trigger table contains the user ID, or navigate through a foreign key to reach it. When the trigger fires, Entrig uses that field to look up the registered device tokens for that user.
The user ID used during registration must match the field configured in the notification. If they do not match, Entrig cannot resolve the recipient.
How does Entrig send the notification?
Once Entrig has the event and the recipient’s device tokens, it:
- Evaluates any conditions you configured
- Resolves the message by replacing placeholders with actual data
- Sends via FCM (Android) or APNs (iOS) using credentials you provide
- Logs the delivery result
If delivery fails due to a temporary error, Entrig retries up to 3 times with exponential backoff. If a token is no longer valid, it is marked invalid and removed automatically.