PostgreSQL

Go to supabase.com → New project. Give it a name, choose the database region closest to your users (this affects API latency for your Bubble users), and set a strong database password (store it somewhere safe — you'll need it for direct database access if debugging). Click 'Create new project' and wait for provisioning (about 2 minutes). Once the project is ready, go to Project Settings (gear icon in the left sidebar) → API. You'll find two pieces of information you need: 1. **Project URL**: `https://{project-id}.supabase.co` — this is the base URL for all API calls 2. **anon key**: a long JWT string labeled 'anon public' — this is what Bubble will use in the Authorization header for client-side calls Also note the **service_role key** — labeled 'service_role secret.' This key bypasses all Row Level Security. Write it down, but do NOT put it in Bubble's API Connector unless it's in a Backend Workflow Private header. Never use it in client-side workflows. The PostgREST REST API base URL is: `https://{project-id}.supabase.co/rest/v1` You'll be pointing Bubble's API Connector at this base URL with two shared headers: `apikey: {anon_key}` and `Authorization: Bearer {anon_key}`. Both headers use the same anon key — this is the correct setup for client-safe reads.

1{
2  "base_url": "https://your-project-id.supabase.co/rest/v1",
3  "headers": {
4    "apikey": "your-anon-key",
5    "Authorization": "Bearer your-anon-key"
6  }
7}

In Supabase, go to Table Editor → New table. For a typical Bubble app user-data table, create a table called `profiles` with these columns: - `id` (uuid, primary key, default: `gen_random_uuid()`) - `user_id` (uuid, references `auth.users.id` if using Supabase Auth, or just a text field storing Bubble user IDs) - `display_name` (text) - `created_at` (timestamptz, default: `now()`) For tables storing user-specific data, immediately enable Row Level Security. In the table editor, click on the table → RLS → Enable RLS. Then add policies: **Policy for user-specific reads (if using Supabase Auth)**: - Policy name: `Users read own rows` - Command: SELECT - USING expression: `auth.uid() = user_id` **Policy for open reads (public content)**: - Policy name: `Anyone can read` - Command: SELECT - USING expression: `true` For Bubble apps that use Bubble's own auth (not Supabase Auth), you won't have Firebase-style UIDs in the JWT. In this case, either use a Backend Workflow with the service_role key for all writes (the anon key with open SELECT rules for reads), or implement a custom JWT strategy where Bubble generates tokens that Supabase can verify. Insert one test row into your table immediately — Bubble's API Connector 'Initialize call' needs a real response with data to detect the response schema. An empty table returns an empty array, and Bubble cannot detect field names from an empty array.

1-- Enable RLS
2ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
3
4-- Policy: users can read their own rows
5CREATE POLICY "Users read own rows" ON profiles
6  FOR SELECT USING (auth.uid() = user_id);
7
8-- Policy: users can insert their own rows
9CREATE POLICY "Users insert own rows" ON profiles
10  FOR INSERT WITH CHECK (auth.uid() = user_id);
11
12-- Policy: users can update their own rows  
13CREATE POLICY "Users update own rows" ON profiles
14  FOR UPDATE USING (auth.uid() = user_id);

In your Bubble app, go to Plugins tab → Add plugins → search 'API Connector' → Install (it's the official plugin by Bubble, free). Once installed, click 'API Connector' in the plugins list to open its configuration panel. Click 'Add another API'. Configure the group: - **API Name**: `Supabase` - **Authentication**: None (auth is handled via shared headers) - **Shared headers**: - `apikey`: `{your-anon-key}` (DO NOT mark as Private — this is an intentionally client-visible key when RLS is properly configured) - `Authorization`: `Bearer {your-anon-key}` (same value) - `Content-Type`: `application/json` The shared header configuration looks like: ```json { "method": "GET", "url": "https://your-project-id.supabase.co/rest/v1/profiles", "headers": { "apikey": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "Content-Type": "application/json" } } ``` Now add your first API call. Click 'Add another call' under the Supabase group: - **Name**: `Get Profiles` - **Method**: GET - **URL**: `/profiles` (PostgREST appends this to the base URL) - Add a query parameter: `select` = `id,user_id,display_name,created_at` (comma-separated column names to return) - **Use as**: Data (for reads that populate repeating groups) For filtering by a specific field, add a query parameter using PostgREST's filter syntax. For example, to filter by user_id: add parameter `user_id` = `eq.{user_id}` where `{user_id}` is a dynamic value you'll pass from Bubble workflows.

1{
2  "method": "GET",
3  "url": "https://your-project-id.supabase.co/rest/v1/profiles",
4  "headers": {
5    "apikey": "<your-anon-key>",
6    "Authorization": "Bearer <your-anon-key>",
7    "Content-Type": "application/json"
8  },
9  "params": {
10    "select": "id,user_id,display_name,created_at",
11    "user_id": "eq.<dynamic>"
12  }
13}

The Bubble API Connector's 'Initialize call' step is required before you can use an API call in workflows. It makes a real HTTPS request to the API and uses the response to detect field names and data types that Bubble will display in workflow action pickers. In the 'Get Profiles' call, click 'Initialize call'. If you have a dynamic parameter like `user_id`, enter a test value matching a real row you created in Step 2 (e.g. if your test row has `user_id = 'test-user-123'`, enter that). Click 'Run'. If the call succeeds with data, Bubble will display the detected fields: `id` (text), `user_id` (text), `display_name` (text), `created_at` (text). Click 'Save'. Common Initialize call problems: - **Empty array returned**: Your test filter parameter matched no rows. Either the table is empty, the filter value doesn't match any rows, or RLS is blocking the query. Insert a test row in Supabase and try again. - **'There was an issue setting up your call'**: The request returned a non-200 status. Check the exact error in Bubble's Logs tab → API connector calls. A 404 usually means the table name is misspelled. A 401/403 usually means the apikey header is missing or incorrect. - **'relation does not exist'**: The table name in the URL doesn't match a table in your Supabase database. Check the exact table name (case-sensitive) in Supabase Table Editor. After initializing the read call, add a POST (insert) call: - **Name**: `Create Profile` - **Method**: POST - **URL**: `/profiles` - **Body**: JSON with dynamic fields: `{"display_name": "{{display_name}}", "user_id": "{{user_id}}"}` - Add header at call level: `Prefer: return=representation` (tells PostgREST to return the created row) - **Use as**: Action (triggered by workflow, not data binding) Initialize the POST call with test values to confirm Bubble detects the returned row schema.

1{
2  "method": "POST",
3  "url": "https://your-project-id.supabase.co/rest/v1/profiles",
4  "headers": {
5    "apikey": "<your-anon-key>",
6    "Authorization": "Bearer <your-anon-key>",
7    "Content-Type": "application/json",
8    "Prefer": "return=representation"
9  },
10  "body": {
11    "display_name": "<dynamic>",
12    "user_id": "<dynamic>"
13  }
14}

With initialized API calls, you can now use them across Bubble's workflow editor and data bindings. **Binding a read call to a Repeating Group**: On a page with a Repeating Group, set the Data source to: Plugins → Supabase Get Profiles → result list. The repeating group will render one row per profile returned by the API. Use the repeating group cell's `current cell's Get Profiles` dynamic value to access fields like `current cell's Get Profiles profile's display_name`. **Triggering a write from a button**: Add a workflow triggered by a button's 'click' event. Add action: Plugins → API Connector → Create Profile. Map the parameters: `display_name = Input Display Name's value`, `user_id = Current User's unique id`. After the API call action completes, add 'Display data' to refresh the repeating group. **Using the PATCH method for updates**: Add another API call in the Connector: - Name: `Update Profile` - Method: PATCH - URL: `/profiles?id=eq.{{id}}` - Body: `{"display_name": "{{display_name}}"}` - Prefer header: `return=representation` The `?id=eq.{{id}}` in the URL path (not the body) tells PostgREST which row to update. Pass the row's UUID as the dynamic `id` parameter. **Adding PATCH + DELETE calls**: Follow the same pattern — URL filter on the primary key, body with fields to update (PATCH) or no body (DELETE with URL filter). WU note: each API Connector call made from a client-side Bubble workflow consumes approximately 0.1–0.5 WUs. For apps with many simultaneous users making frequent reads, consider caching Supabase data in Bubble's native database (updated by a scheduled Backend Workflow) to reduce per-user API call WU consumption.

1{
2  "method": "PATCH",
3  "url": "https://your-project-id.supabase.co/rest/v1/profiles?id=eq.<dynamic-id>",
4  "headers": {
5    "apikey": "<your-anon-key>",
6    "Authorization": "Bearer <your-anon-key>",
7    "Content-Type": "application/json",
8    "Prefer": "return=representation"
9  },
10  "body": {
11    "display_name": "<dynamic>"
12  }
13}

With Supabase RLS enforcing data access at the database layer, your data is protected at the API level. But if you also store references to Supabase records in Bubble's native database (e.g. storing a Supabase row's UUID alongside a Bubble User), add Bubble privacy rules to protect those native data types too. In Bubble, go to Data tab → Data types → click any type that stores Supabase-sourced data → Privacy tab. Add a rule: `When Current User is the creator → Allow find in searches: Yes, Allow reading all fields: Yes`. This ensures even if someone queries your Bubble app's database directly, they can't read other users' records. To verify RLS is working correctly, test with a different user account or an unauthenticated session: 1. Open your Bubble app in an incognito window (unauthenticated) 2. Note what data the Supabase API calls return — with RLS enabled and a `where auth.uid() = user_id` policy, unauthenticated calls should return empty arrays 3. Sign in as a test user and confirm only that user's rows appear If you're using the service_role key anywhere for admin operations, those calls must go through a Bubble Backend Workflow with the key in a Private header. To add admin operations: - In the API Connector, add a second Supabase API group named 'Supabase Admin' - Shared header: `Authorization: Bearer {service_role_key}` marked **Private** - Only use this group's calls inside Backend Workflows - Trigger those Backend Workflows from client-side events using Bubble's 'Schedule API workflow' action RapidDev's team has built dozens of Bubble apps with Supabase backends and complex RLS policies — if you're running into data access issues, book a free scoping call at rapidevelopers.com/contact.