A spreadsheet of the 340 records with no email address

What do you have to enable first?

In your Bubble app, the API section of settings: switch on the Data API, then tick each data type you want readable. Nothing external sees a data type you have not ticked, which is a sensible default and a reliable source of "why is this returning nothing". Generate an API token in the same place.

Think about which types you expose. A Bubble `User` data type frequently holds far more than a username, including fields somebody added for a one-off feature and never removed. Privacy rules on the Data API behave differently from the ones you set for page logic.

• Enable the Data API in your app’s API settings, then expose data types individually.
• Generate a token there, and prefer one that can read only what you exposed.
• Check what fields your `User` type actually holds before exposing it.
• Remember that the live and development versions of a Bubble app are separate endpoints.

What is worth doing once it is connected?

Reporting and the data hygiene the Bubble editor makes tedious. Counting records by status, finding rows where a required field is empty, checking whether the two order types have drifted apart. A spreadsheet of the 340 records with no email address is genuinely actionable, and getting it out is ordinary data extraction.

The other one is the admin task nobody built a screen for. Every Bubble app has three or four operations rare enough that building UI for them never got prioritised. Read the Available tools list on the Bubble entry under `strawberry://settings/integrations`, then keep any write action at Ask every time. Bulk updating records in web apps is the neighbouring pattern, and ai for solo operators is usually the audience.

What a write can trigger in your app

Because Bubble workflows react to data.

Changing a field through the Data API can trigger a database trigger workflow, which sends an email, which charges a card, which posts to a webhook. That chain is invisible from outside the app and completely visible inside the editor, so the person who knows what a write will cause is you.

The Permissions block on the app’s detail page is where you encode that. Leave writes switched off until you have traced what each one triggers, and consequential steps stop at an approval card anyway. For read-only reporting none of this applies.

Frequently asked questions