Hey,
Creating a new topic because i’m experiencing some strange things within supabase pro kit mobile :
For the same database, and same settings, same workflow triggers, the one on bubblego or testflight returns a 400 with status code “Failed to load initial data with status 400”, but when using bubble web preview for native app, it is working normally
Do you know what could be causing this ?
Hi g.pujol,
Thanks for reaching out.
I reviewed the screenshot and the Supabase Pro Kit documentation. Since the same setup works in Bubble web preview but returns Failed to load initial data with status 400 in BubbleGo/TestFlight, this may be related to a difference in how the native environment handles the request, authentication state, or the element initialization.
One possible bottleneck that often leads to issues like this is whether the user is properly authorized in the native app environment and has access to the data you are trying to retrieve. For example, if Supabase RLS policies are enabled, the request may work in one environment but fail in another if the user session/token is missing, expired, or not being passed correctly.
Could you please send us a few screenshots so we can check the setup more precisely?
Please share:
The action where the Supabase Pro Kit Mobile plugin loads/fetches the data
The full setup of the action returning the 400 error
-The Supabase Pro Kit Mobile element settings on the page
The workflow where the user logs in or where the Supabase session is initialized
Supabase side
Error details
Once we have these screenshots, we’ll be able to compare the native setup against the working Bubble web preview behavior and identify whether the issue is caused by authentication, permissions/RLS, plugin initialization, or a request configuration difference.
Support Team
Browse all Zeroqode Plugins for bubble
Hey,
Qs a general return, I find this mobile version of supabase pro kit way trickier to make it work than the web one.
Example : Even with proper RLS policies (works perfectly on web, with supabase pro kit, with the same given user, roles etc) calling some tables with the anon key and jwt doesn’t return anything on my end, but putting the service role in the anon key thing make it work (obviously). Even with simple RPCs functions that returns 2 simple columns, it doesn’t return anything (but the plugin is telling me Data initialized successfully).
My guess would be that the JWT token isn’t getting parsed when calling a table / rpc, tried with various accs with various permissions, and it only seem to return something when using the service role.
Did a complete migration of my bubble database few months ago with the supabase pro kit web plugin (20k users, large table architecture) and it works just great with the web one, but this mobile iteration is, on my end a pain just to fetch a single table.
Maybe i am not testing it right ?
Im mainly using Bubble go and web preview of my mobile app. I also tried deploying on testflight just to see if the bubblego thing was messing with the plugin but it doesn’t seem like it is.
Hey,
It really seems like its not working at all with the publishable keys / anon keys on my end,
Even tho my schema are well exposed and everything is configured properly, nothing is returning from any fetches, and even on test data with only a single text value returned (as stated in my previous reply, i already moved everything to supabase with the web plugin, and everything works fine)
My hint is that the users JWT token is not getting parsed into all the calls,
I only have data when I used a security definer function / service_role key
On your end, is the plugin working with a regular anon key ?
Best regards
Hey again,
I’m now 99% sure the user JWT token is not being forwarded when fetching data via the Supabase Pro Kit Mobile plugin. Here is how I tested it (I am logged in throughout, with the Auth element on the page, and I confirmed it by displaying Current User's email on screen — it shows the correct email).
Setup: brand new test table with only a uuid and a text column.
Baseline — no RLS: fetches the data successfully 
Test 1 — to authenticated policy:
create policy "test_1_role_check"
on public.rls_diagnostic
for select
to authenticated
using (true);
→ Status message says “Initial data loaded successfully” but 0 objects returned. Means the request isn’t being seen as coming from the authenticated role.
Test 2 — auth.uid() is not null policy:
create policy "test_2_uid_check"
on public.rls_diagnostic
for select
using (auth.uid() is not null);
→ Also 0 objects returned. Confirms auth.uid() resolves to null on the DB side.
Test 3 — direct proof via RPC:
To remove any ambiguity, I created a security invoker function that returns exactly what Supabase sees from the caller:
create or replace function public.whoami()
returns table (uid uuid, role text, jwt_email text)
language sql
security invoker
stable
as $
select auth.uid(), auth.role(), (auth.jwt() ->> 'email')::text;
$;
grant execute on function public.whoami() to anon, authenticated;
Called from the mobile plugin with the logged-in user: → (0 objects returned) uid: null, role: anon, jwt_email: null
Called from the web Pro Kit plugin, same user, same moment, same database: → uid: <correct UUID>, role: authenticated, jwt_email: <correct email>
So the database itself confirms it: the mobile plugin is not forwarding the user’s JWT in the Authorization header. The request lands on Supabase as a pure anon resuest, which is why every RLS policy relying on auth.uid() or the authenticated role returns 0 rows.
Can you confirm this is a plugin bug and provide an ETA on the fix? Happy to share more screenshots or jump on a calll if needed.
Best regards, Guilhem
Hi @g.pujol ,
Thank you for your message, and apologies for the waiting time on this case.
I confirm that we received both your forum updates and your email message. We have reviewed the diagnostics you shared, including the latest conclusions in the forum thread, and we are passing them to our development team for further investigation.
From the support side, your findings point to a possible issue with how the Supabase Auth session/JWT is propagated to Database/RPC requests in the native mobile runtime. However, confirming this requires a developer-level review. The developers have access to the actual plugin code and can verify the behavior internally, including whether the authenticated token is being attached correctly in BubbleGo/TestFlight/native builds.
At this stage, we cannot provide a precise timeline for the investigation. Identifying the exact root cause and implementing a reliable fix can take longer than confirming that the behavior is reproducible, especially when the issue depends on the native mobile runtime.
That said, the diagnostics you provided are very valuable and will help the developers narrow down the investigation.
Once the developers reach a conclusion and/or release a fix, we will make it a priority to circle back and update you directly.
Thank you again for the detailed report.
Best regards,
Egor Smorodinov,
Support Team
Browse all Zeroqode Plugins for bubble
Hello @g.pujol ,
I wanted to quickly inform you that the issue is now being analysed by our devs.
They confirmed that your input was very helpful and are now analysing what can be causing the difference in execution between web preview and native mobile runtime.
I flagged this case as a top priority one, since it’s a pressing issue and an popular plugin, and I will make sure to circle back to you as soon as there are updates.
Thank you for your continued patience!
Best regards,
Egor Smorodinov,
Support Team
Browse all Zeroqode Plugins for bubble