Supabase Node Dynamic Table/Field Dropdowns Fail With “No bridge acquired for this context. Call acquire() first.”
I’m running into an issue with the native Supabase node in n8n Cloud where the Supabase credential works and the node can successfully query data, but the dynamic table and field dropdowns fail to load.
The issue appears to be isolated to n8n’s dynamic parameter loading rather than Supabase connectivity, authentication, RLS, or table access.
Environment
-
n8n Cloud
-
Native
n8n-nodes-base.supabasenode -
Supabase hosted project
-
Using a newly created Supabase server-side Secret Key
-
Resource: Row
-
Operation: Get Many
Problem
The Supabase credential tests successfully in n8n.
However, when creating a Supabase node, the Table Name or ID dropdown displays:
Error fetching options from Supabase
The UI also reports:
There was a problem loading the parameter options from server: "[object Object]"
The same issue occurs when n8n attempts to dynamically load field/column names.
What is important is that the actual Supabase node works when the table and field names are entered manually as expressions.
Tests Performed
- Supabase credential test
The n8n Supabase credential test succeeds.
Result:
Connection successful
- Manual table name
Instead of using the broken Table Name dropdown, I switched the field to Expression mode and entered a known table manually:
{{ 'example_table' }}
I then ran:
-
Resource: Row
-
Operation: Get Many
-
Limit: 50
-
No filters
Result:
The Supabase node successfully returned rows from the table.
- Manual field name and filter
I then added a filter and manually supplied a known field name as an expression:
{{ 'status' }}
Condition:
Equals
Value:
Test
Result:
The Supabase node successfully returned matching rows.
This confirms that:
-
Supabase authentication works
-
n8n can reach Supabase
-
The table is accessible
-
The fields are accessible
-
Filters work
-
Data retrieval works
-
The Supabase node itself can execute successfully
The failure appears to be specifically related to dynamic parameter loading.
- Direct Supabase Data API test
I also tested the Supabase REST API directly using an n8n HTTP Request node.
Request:
GET https://[PROJECT].supabase.co/rest/v1/
Headers:
apikey: [REDACTED SERVER-SIDE SECRET]
Authorization: Bearer [REDACTED SERVER-SIDE SECRET]
The request succeeds and Supabase returns the OpenAPI schema, including table paths and definitions.
So Supabase appears to be successfully exposing the metadata required for table and column discovery.
Network Error From n8n
I opened Chrome DevTools and captured the request generated when a brand-new Supabase node attempts to load the Table Name dropdown.
The dynamic parameter options request returns:
HTTP 500
Response:
{
"code": 0,
"message": "No bridge acquired for this context. Call acquire() first.",
"level": "warning",
"tags": {},
"timestamp": "[REDACTED]",
"context": {},
"functionality": "regular",
"name": "NodeApiError",
"node": {
"parameters": {
"useCustomSchema": false,
"resource": "row",
"operation": "getAll",
"tableId": "",
"returnAll": false,
"limit": 50,
"filterType": "manual",
"matchType": "anyFilter",
"filters": {}
},
"id": "[REDACTED]",
"name": "Temp-Node",
"type": "n8n-nodes-base.supabase",
"typeVersion": 1,
"position": [
0,
0
],
"credentials": {
"supabaseApi": {
"name": "Supabase account"
}
}
},
"messages": [
"No bridge acquired for this context. Call acquire() first."
],
"httpCode": null
}
Expected Behavior
When a valid Supabase credential is selected, the Table Name or ID dropdown should populate with the available Supabase tables.
After selecting a table, the field dropdowns should populate with the available columns.
Actual Behavior
The dropdown displays:
Error fetching options from Supabase
The dynamic parameter request returns HTTP 500 with:
No bridge acquired for this context. Call acquire() first.
Workaround
The Supabase node works if the table and field IDs are entered manually using expressions.
For example:
Table:
{{ 'example_table' }}
Field:
{{ 'status' }}
The node then successfully queries and filters Supabase data.
Additional Notes
I originally suspected RLS or Supabase permissions, but the testing above appears to rule that out.
The same server-side Supabase key:
-
passes the n8n credential test
-
retrieves the Supabase OpenAPI schema
-
successfully queries rows through the native Supabase node
-
successfully applies filters through the native Supabase node
Only the dynamic table/field option loading fails.
This appears to be an internal n8n dynamic parameter/load-options issue rather than a Supabase API issue.
I can provide additional logs, sanitized screenshots, workflow JSON, n8n Cloud version information, or other diagnostics if helpful.