Supabase Plugin - Integrate Supabase into your Bubble app

@ZeroqodeSupport - one quick question.

I have a multi-drop down in Bubble that I’m trying to insert the data into Supabase as individual unique entries.

For example, if the drop down has:

{value_1, value_2, value_3}

I am trying to convert the payload to:

{

  user_id: “string value”,

  value: “value_1”

}

{

  user_id: “string value”,

  value: “value_2”

}
{

  user_id: “string value”,

  value: “value_3”

}

Given that I don’t know how many numbers of value the user is going to choose, I need it to loop through until the very end automatically. I am wondering if you know how to set this up on Bubble using the plug-in?

Initially, I tried to use the Bubble backend looping function, but it seems i can’t trigger a Supabase database insert/upsert on the backend?

Hi @steven.h.liu.1 :waving_hand:

You can use the Server-Side Action → Run SQL Query from Supabase Pro Kit to insert dropdown selections into Supabase. Here’s how you can set it up:

Use SQL approach

  1. Create a backend API workflow.
  2. Add a parameter for the user ID (e.g. user_id) and a parameter for the selected value (e.g. value_item).
  3. In that workflow, use the Supabase Pro Kit → Run SQL Query action.
  4. Pass parameters into your SQL. For example:
INSERT INTO your_table (user_id, value)
VALUES ('{{user_id}}', '{{value_item}}');
  1. On your frontend/workflow where the multi-dropdown is submitted, use Schedule API Workflow on a List:
  • List to run on = MultiDropdown’s value list
  • API workflow = the backend workflow you created
  • Parameters configured before

That way, Bubble loops through each selected value, calling the backend workflow each time — and your SQL inserts one row per selected item.

Documentation

You can read more about the SQL-action approach here:
Supabase Pro Kit → Server-side actions (Run SQL Query)

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hi @ZeroqodeSupport - I am having a bit trouble replicating this. I am able to successfully authenticate as a supabase_admin using the access code. However, when I check the database, it’s not showing the INSERT json load I’m putting in.

Things I tried:

  1. I was able to successfully insert directly in Supabase using the same sql query
  2. The Postgres log only shows authentication success but no sql query load is shown in the log
  3. I assume access token is my overall JWT or creating a separate API key?
    1. Got this error: Failed to run query: Unauthorized (401): JWT could not be decoded and Failed to run query: Unauthorized (401): JWT failed verification
    2. Where would I get the right JWT in this case?
  4. I changed everything to hardcode (see pic) to ensure it’s not due to variables causing issues
  5. Also tried with a simpler SQL query still same effect:
    1. INSERT INTO public.author (author_name)
      VALUES (‘joseph smith’)

Pics (Bubble Backend):

Supabase auth (BUT, i’m not seeing a INSERT log entry under API Gateway):

Table RLS (i assume this doesn’t matter as i’m logging in as an admin):

Hello @steven.h.liu.1 ,

Hi Steven,

Thanks for the detailed screenshots — they help a lot. From what we can see, your Bubble setup for the “Run SQL Query (Supabase management)” action looks correct, so the issue is most likely related to the token being used. The SQL management endpoint requires the Supabase service-role key specifically, not a user JWT or any other API key. If the token isn’t the service-role key, Supabase will authenticate the connection but won’t authorize the SQL execution, which matches what you’re seeing in the logs.

Since RLS doesn’t apply to SQL management queries, the policy you showed shouldn’t block the insert. Once the correct service-role token is used, the query should appear in the Postgres logs and the row should be inserted.

Please try running the same test using the service-role key exactly as provided in your Supabase project settings. If the logs still show only the authentication event and no SQL activity, let me know and we’ll dig deeper together.

Happy to help you get this working.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

@ZeroqodeSupport- thanks for the clarification. Could you let me know where in the Supabase dashboards I would be able to find the service role key?

I was using the JWT key that was under Settings > JWT Keys, but I encountered the issue you described (authenticated but not approved).

Hello @steven.h.liu.1 ,

We’ll take a closer look at the specifics you’ve provided and carefully review your question again.

Once we’ve completed our review, we’ll follow up with more detailed information and suggestions tailored to your scenario. In the meantime, if you have any additional clarifications, or details you’d like to share, please feel free to send them over—they can help us troubleshoot more effectively.

Thank you for your patience while we investigate further! We’ll be in touch as soon as we have more insights to share.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hello @steven.h.liu.1 ,

Thank you for your patience!

Here’s where you can get your service role key:
https://supabase.com/docs/guides/api/api-keys

Please remember that the service role key must be kept strictly secret. It should only be used in backend workflows. Exposing it in the frontend, sharing it, or placing it inside any client-visible element will compromise your entire Supabase project, because the service role key bypasses all RLS policies.

To proceed with testing, take the service role key and paste it into the Access Token field of the Run SQL Query action. This will allow you to check whether the query executes correctly when RLS restrictions are not blocking it.

Let us know if the SQL query runs successfully using the service role key.
If it does, that means the issue lies in how your RLS policies are configured, or the authenticated user simply does not have permission to run that operation under your current rules.

Additionally, could you please test the other database actions as well?
You mentioned the insert operation — but does update, delete, or select work as expected?
This will help us understand whether the problem is specific to SQL execution or related to permissions in general.

Feel free to share your findings and we’ll help you move forward.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hi @ZeroqodeSupport - I tried but still encounter errors.

When I used the service_role key (found under Setting > API Keys > Legacy anon, service_role API keys), I get the following error via “run SQL query”:

Failed to run query: Unauthorized (401): JWT failed verification

When I used the secret API key (found under Setting > API Keys > publishable and secret API keys), I get the following error via “run SQL query”:

Failed to run query: Unauthorized (401): JWT could not be decoded

This is the backend workflow I’m running (removed the access token and project ref for security reason)

________________________

And just so we eliminate all potential variables: project ref is the project id found under Settings > General, correct?

Hello @steven.h.liu.1,

Thanks for the detailed follow-up.

To answer your questions and outline next steps:

  1. Project ref
    Yes — the project ref you’re using is correct. It should be the Project ID from your Supabase Dashboard → Settings → General.

  2. Alternative approach while server-side SQL is failing
    Since the server-side Run SQL Query (Supabase management) action is currently failing due to the JWT verification/decoding errors, you can use an alternative approach that we showcase on our demo page.

You can see it here:
https://supabase-editor.bubbleapps.io/bulk-insert
Editor page:
https://bubble.io/page?id=supabase-editor&tab=Design&name=bulk-insert&type=page&version=live

In this setup, the selected values are first collected and stored in a custom state, and then passed into a bulk insert action, allowing multiple rows to be inserted in a single operation without relying on the server-side SQL action. This can be a good workaround in the meantime.

  1. Dev team review
    I’ll reach out to our dev team to help review your setup in more detail so we can understand what’s causing the JWT decoding and verification issues with the SQL management endpoint. Once we have more clarity from their side, I’ll follow up with you and share our findings and next steps.

Thanks again for your patience — we’ll get back to you as soon as we have an update.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

@ZeroqodeSupport - thank you for the response. Just so I understand, my setup is correct, but this is a more widespread issue vs. my isolated incident? If so, do you happen to have a timeframe on the follow-up?

Hi @steven.h.liu.1 ,

Thanks for checking in. Our dev team is still reviewing your setup and investigating the issue in detail. At this stage, we’re not able to confirm whether it’s a more widespread issue or an isolated case, but we’re treating it as a priority and will keep you updated as soon as we have more information. Unfortunately, we can’t provide an exact ETA yet, but as soon as we have a response or update from the team, we’ll reach out to you right away.

Thanks for your patience and for bringing this to our attention.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hello @steven.h.liu.1,

Here’s the update from our dev team:

• The JWT token is required only for user authorization.

• The errors “JWT failed verification” or “JWT could not be decoded” suggest the workflow may not be reaching the Run SQL step.

However, you mentioned seeing a “connection authorized” entry in the logs, which seems contradictory. Our current hypothesis is that the auth session is not persisting across pages. For example:

• The user signs in on a login page and is redirected to the Run SQL page.

• If the second page is missing an auth component, the session might not persist, leading to the JWT errors you’re observing.

From what we can see, your Run SQL step configuration looks correct, but it will fail without a persistent session.

Could you please verify the session persistence across your pages and let us know if this resolves the issue?

Looking forward to your reply.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hi @ZeroqodeSupport - thank you for your response. I do have persistent session across my pages, but it’s still encountering the same issue.

I sent you a recorded video replicating the problem to your DM (because of more sensitive info being recorded). Please take a look and let me know if this helps in diagnosing the problems and/or let me know if you would need additional info on top of what’s in the video.

Hi @steven.h.liu.1

Thank you for the update and for sharing the recorded video — that’s very helpful.

I’ve initiated a more formal investigation together with our dev team, and we’ll review the video in detail. Just a quick heads-up: since the video contains sensitive information, we’ll continue the follow-up and share any findings via DM, in line with the privacy considerations you mentioned.

If we need any additional details after reviewing the recording, we’ll let you know directly.

Thanks again for taking the time to put this together — it really helps us move things forward.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hello @steven.h.liu.1 ,

Our dev team has prepared a test page and an editor reference to demonstrate the exact setup you’re aiming for. You can review the test page here: https://supabase-editor.bubbleapps.io/version-test/at_supabase?debug_mode=true and the Bubble editor here: supabase-editor | Bubble Editor. On this page, you’ll find a dropdown configured similarly to yours, along with the workflows and elements that make it work as intended.

To get started, in Supabase go to Account Settings, then Access Tokens, and generate a token. Use the access token and your Project ID in the action settings. If the response returns data, use the datatype and expectedResponse fields accordingly.

Please also review the “Button RUN is clicked” workflow, the “Generate Token Copy” backend workflow, and the configuration of the Run SQL Query action.

Additionally, our devs recommend taking a closer look at the client workflow for bulk data insertion. A multi-dropdown triggers events when items are added or removed. For these events, you can trigger the plugin actions “Add item to bulk data” and “Remove item from bulk data,” which will populate a plugin state called “Bulk data” for later writing to the database. Once ready, write the “Bulk data” state to the database using the “Insert” action.

Please review the test page and editor setup. If anything is unclear feel free to follow up - we’ll gladly help!

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hello everyon! :waving_hand:

We’ve just published a new video tutorial for the Supabase Pro Kit, covering the full setup flow and a practical walkthrough so you can get from “installed” to “working app” faster. :rocket:

What you’ll learn

In this tutorial, we walk through:

  • Installing and initializing the Supabase Pro Kit
  • Connecting your app to Supabase (project + API keys)
  • Setting up the core Supabase pieces you need to run the kit smoothly (auth + database basics)

Watch the tutorial

- YouTube

Helpful links

What should we cover next?

We’re building out more Supabase Pro Kit tutorials and would love your input.
What future use cases would you like to see covered?

Reply with your top requests (and your app type/use case if possible) and we’ll prioritize accordingly.

Additionally, we would be very grateful to receive feedback on this video—what you liked or didn’t like, whether you found it useful, and if there are any parts that could be improved for future videos.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

hey @ZeroqodeSupport- I have a question regarding persistent log-in session.

Currently, at every (new) page load, it takes bubble ~2 seconds to log back into supabase again. Is there a way to reduce this lag time?

My setup is:

  • I have a reusable element called “global_auth” that stores my Supabase Auth A
  • I place the reusable element in every single page

This gives me a persistent session across the pages. However, the 2 second load time per page to stay logged in is quite unbearable.

Hello @steven.h.liu.1,

To properly understand where the ~2 second delay is coming from (whether it’s Supabase re-initialization, token refresh, network handshake, or something else), we’ll need to look at the actual network timeline during page load.

Could you please record and share a HAR file of the page loading process? This will allow us to analyze the exact requests being triggered and their timing.

You can follow this guide to export a HAR file from Chrome DevTools:
:backhand_index_pointing_right: https://developer.chrome.com/blog/new-in-devtools-130/#har

In short:

  1. Open Chrome DevTools (F12)
  2. Go to the Network tab
  3. Enable recording
  4. Reload the page
  5. Right-click inside the Network panel → Save all as HAR with content

Once we review it, we’ll be able to determine what could be causing the delay.
Looking forward to reviewing the file and digging into this with you :raising_hands:

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3

Hi @ZeroqodeSupport - here’s the HAR file LINK

Hello @steven.h.liu.1 ,

Hi! I analyzed your HAR file from creatorbackstage.co. Here’s what I found:

The ~2 second delay you’re seeing is actually part of a longer chain. Your page takes about 6.9 seconds total to load (onLoad), and Supabase queries don’t fire until roughly 5.8 seconds into that process. The delay you notice is the gap between the page shell appearing and Supabase data actually populating.

Here’s what’s contributing to it:

  1. You’re running in debug mode (version-test)
    This is the biggest easy win. Your app is loading run_debug.js plus the Eruda debugger console — that’s dozens of extra requests and significantly larger JS files. Switching to the live version should cut a meaningful chunk off load time by itself.

  2. Slow server response (TTFB)
    The main HTML document alone takes ~2.9 seconds of server wait before Bubble even starts sending the page. This is Bubble’s server-side processing and is partly influenced by page complexity (number of elements, conditions, etc.).

  3. Heavy JS bundle chain
    After the HTML arrives, there’s about 1.3MB of JavaScript that needs to download and execute before the Supabase plugin can do anything. One bundle alone takes ~1.3 seconds due to server wait. This is Bubble’s framework — not much you can control directly, but reducing page complexity helps.

  4. Instagram embeds loading eagerly
    You have 4 Instagram embed iframes loading at the same time as your Supabase queries, competing for network connections.

  5. Third-party scripts adding up
    Google Charts (300KB), reCAPTCHA (500KB), and a Kaspersky browser extension are all loading during the critical window and competing with your Supabase requests.

Quick wins to try:

• Switch to production mode (not version-test) — this alone should noticeably improve things

• Check for duplicate queries — tag?select=* fires twice with identical parameters

Hope this helps! Happy to dig deeper if you have questions.

Best regards,
Zeroqode Support Team
Browse all Zeroqode Plugins for Bubble
Banner_Last3