Repeating Group not showing data received via API Workflow (POST returns 200 but rows are blank)

Need help
1

Hi everyone, I need help with an API Workflow that receives data but doesn’t display it.
Setup:
A Python script on my VPS sends crypto signals to my Bubble app via API Workflow (POST).
The POST returns status 200 (success) every time.
App version: version-test
API Workflow: run_brain_engine_v2 (public, runs without authentication).
The Python sends this JSON:
ativo (unique id of an “Asset” thing)
sinal_texto (text, e.g. “Compra”/“Venda”)
score_cerebral (number)
forca_sinal (number)
valor_rsi (number)
Data type “Signal” has fields: asset (Asset), sinal_texto (text), score_cerebral (number), forca_sinal (number), rsi_value (number), generated_at_date (date).
Problem:
New Signal rows ARE created and my Repeating Group shows them, but ALL fields are empty (they show my “–” fallback). The data source is Search for Signals sorted by generated_at_date descending.
Questions:
For an API Workflow receiving a POST, do I need to manually declare EVERY field under “Parameter definition”, or does “Detect request data” handle it?
What is the correct way to map each incoming API parameter to a field in the “Create a new Signal” action?
How can I see the raw incoming request body to confirm the field names arriving?
The Python backend works and returns 200, so I believe the issue is how the Bubble API Workflow receives/maps the data. Thank you!

2

Detect request data handle the field but you need to first initialize it and save parameters.

Once it’s done, you need to do something with the received data, like save it to your DB and at this moment, you will set all DB field with request data values.

The RG will show your DB, not directly the received webhook.

If you want to display data directly from your server, your need to use API connector.

Please share screenshots of your settings

3

I think using Detect Data Request is enough to identify which fields are being received. However, what I would do (and what I actually do in my own apps) is create a workflow that "create a new thing containing only the fields that are relevant to my application.

This gives you much better traceability throughout the process. I’ve worked with some services that don’t retain webhook logs for very long, so having your own record makes debugging and auditing much easier.

4

Hi @eduardosantosdeleon

A couple of things to check:

  1. Field mapping isn’t automatic. Even after “Detect data” learns your parameter names, you still have to explicitly set each field on the “Create a new Signal” step (sinal_texto = the detected sinal_texto param, etc.) — nothing gets wired up just because the names match. If any field was left on its default, that’s your blank column.

  2. Double check the Content-Type header the Python script sends. If it’s not application/json (e.g. form-encoded or missing), Bubble’s detector can silently treat the whole body as one blob instead of separate params, which also produces “success but empty” results.

  3. To see exactly what your Python script is sending, use **webhook.site** (free, no signup required). Go there, copy your unique URL, point your Python script at it instead of Bubble, run it once, and you’ll see the complete raw request displayed in your browser — headers, body, everything. Compare that to what your Bubble workflow expects. Once you’ve confirmed the payload is correct, swap the URL back to Bubble. Alternatively, add a **Display** step at the top of your backend workflow to dump the detected parameters — that’ll show you in real-time what Bubble actually parsed.