Exposing API endpoints in Bubble lets external services send data to your app or retrieve data from it. This tutorial covers enabling the Workflow API, creating backend workflows as public endpoints, defining URL paths and parameters, configuring return data, and securing endpoints with API tokens to control who can access them.
Overview: Exposing API Endpoints in Bubble
This tutorial shows you how to create custom API endpoints using Bubble's backend workflows. External services, apps, and developers can call these endpoints to create data, trigger actions, or retrieve information from your Bubble app.
Prerequisites
- A Bubble app on any plan
- Backend workflows enabled in Settings → API
- Understanding of Bubble backend workflows
- A use case requiring external API access to your app
Step-by-step guide
Enable the Workflow API
Enable the Workflow API
Go to Settings → API tab. Check the box for 'Enable Workflow API.' This activates the ability to expose backend workflows as public endpoints. Optionally, generate an API token by clicking 'Generate a new API token.' Save this token — external callers will use it for authentication. You can create multiple tokens for different external consumers and revoke them individually.
Expected result: The Workflow API is enabled and you have an API token for authentication.
Create a backend workflow as a public endpoint
Create a backend workflow as a public endpoint
Go to the Workflow tab → Backend workflows (via the Pages dropdown). Click to create a new backend workflow. Name it descriptively with hyphens (e.g., create-order). Check 'Expose as a public API workflow.' This makes it callable at: https://yourapp.bubbleapps.io/api/1.1/wf/create-order. Add parameters that the external caller will send — each parameter has a name, type, and optional default value. Add workflow actions that process the received data (create records, send emails, etc.).
Expected result: A backend workflow is configured as a public API endpoint accessible via HTTP POST.
Define return data for the endpoint
Define return data for the endpoint
To return data to the caller, add a 'Return data from API' action at the end of your backend workflow. Define the return keys and their types. For example, return an order_id (text) and status (text). The caller receives a JSON response with these fields inside a 'response' object. If you need to return a list of items, set the return type to a list and populate it with search results. Always include a status or success indicator in your return data.
Expected result: The endpoint returns structured JSON data to the caller after processing.
Secure the endpoint with authentication
Secure the endpoint with authentication
By default, exposed endpoints require an API token. External callers must include an Authorization header: Bearer [your_api_token]. To make an endpoint public (no auth required), check 'This workflow can be run without authentication' — use this sparingly and only for truly public operations like webhooks. For additional security, add parameter validation in the workflow: check that required parameters are not empty and values are within expected ranges. Return error messages for invalid requests.
Pro tip: Create separate API tokens for different external consumers. This lets you revoke access for one consumer without affecting others.
Expected result: Endpoints are secured with token authentication, with optional public access for webhook-style endpoints.
Test the endpoint with a REST client
Test the endpoint with a REST client
Use a tool like Postman, Insomnia, or curl to test your endpoint. Send a POST request to the endpoint URL with the Authorization header and a JSON body containing your parameters. Verify the response contains the expected return data. Test error cases: missing parameters, invalid values, and unauthorized requests (no token). Check the Bubble Logs tab for execution details and any errors that occurred during processing.
Expected result: The endpoint responds correctly to valid requests and returns appropriate errors for invalid ones.
Complete working example
1API ENDPOINT SETUP2====================34ENABLE:5 Settings → API → Enable Workflow API6 Generate API token for authentication78CREATE ENDPOINT:9 Workflow tab → Backend workflows10 New workflow: 'create-order'11 Check: Expose as a public API workflow1213 Parameters:14 customer_email: text (required)15 product_id: text (required)16 quantity: number (required, default: 1)1718 Actions:19 1. Validate parameters (Only when email is not empty)20 2. Create Order (customer, product, quantity)21 3. Return data from API:22 order_id: Result of step 2's Unique ID23 status: 'success'24 total: calculated total2526ENDPOINT URL:27 https://yourapp.bubbleapps.io/api/1.1/wf/create-order2829AUTHENTICATION:30 Header: Authorization: Bearer [api_token]3132TEST (curl):33 curl -X POST https://yourapp.bubbleapps.io/api/1.1/wf/create-order \34 -H 'Authorization: Bearer token123' \35 -H 'Content-Type: application/json' \36 -d '{"customer_email":"test@test.com","product_id":"abc","quantity":2}'Common mistakes when exposing a unique endpoint for an API Workflow in Bubble.io: Step-by-Step
Why it's a problem: Making endpoints public without authentication when they modify data
How to avoid: Keep authentication required for all endpoints that create, modify, or delete data. Only make read-only or webhook endpoints public.
Why it's a problem: Not validating parameters in the workflow
How to avoid: Add validation conditions at the start of the workflow and return error messages for invalid inputs
Why it's a problem: Forgetting that endpoint names are case-sensitive
How to avoid: Always use the exact workflow name (lowercase with hyphens) when calling the endpoint
Best practices
- Use descriptive hyphenated names for endpoint workflows
- Always require authentication for endpoints that modify data
- Validate all parameters and return clear error messages
- Include a status indicator in return data
- Create separate API tokens for different external consumers
- Test endpoints with a REST client before sharing with external developers
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I need to create API endpoints in my Bubble.io app that external services can call to create orders and retrieve product data. How do I set up backend workflows as public API endpoints with authentication?
Create a backend workflow called 'create-order' that accepts customer_email, product_id, and quantity parameters. Validate that all parameters are present, create an Order record, and return the order_id and status. Require API token authentication.
Frequently asked questions
What HTTP methods do Bubble API endpoints support?
Bubble backend workflow endpoints support POST requests. For GET-style data retrieval, use the Bubble Data API instead of workflow endpoints.
Can I rate-limit my API endpoints?
Bubble does not have built-in rate limiting for API endpoints. Implement your own by tracking API call counts per token in a database and rejecting calls that exceed the limit.
How do I test endpoints in development?
Use the development version URL: https://yourapp.bubbleapps.io/version-test/api/1.1/wf/endpoint-name. This calls the development version without affecting live data.
Can I return a list of database records from an endpoint?
Yes. Use the Return data from API action with a list return type. Populate it with a Do a Search for result. The response includes the list as a JSON array.
Can RapidDev help design and build API endpoints in Bubble?
Yes. RapidDev can architect, build, secure, and document API endpoints for your Bubble app, including authentication, validation, error handling, and integration testing.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation