API
Public API endpoints
Enable Workflow API and backend workflows
Check this box if you want the app to expose an API that you or other developers/services can access to run API workflows. In addition to API workflows (which can be used for scheduled workflows), there are two other types of backend workflows: recurring events and database change trigger events. Unchecking this box will disable the API endpoint. It will not stop backend workflows from running. You can pause the scheduler in the Logs tab to stop these workflows from running.
Enable Data API
Check this box if you want the app to expose an API that you or other developers/services can access to read or write the app data directly. When checked, select which types to expose as an API in the options that display.
Use field display instead of ID for key names
GET API calls or Return Data actions can either return data with the keys being a fixed ID or use the display defined for the field in the Data Types section in the Data Tab. Choose this setting here.
Hide Swagger API documentation access
Check this box if you want the app to hide the automatically generated Swagger API documentation that you or other developers/services can access. See the Swagger Specification section for more details.
Warning
Hiding this may break some Bubble App Connector features.
3rd Party OAuth / SAML Access
If the app exposes an OAuth2 protocol, meaning users can log in to other websites using their credentials with the app, you must define the page they get redirected to once they authenticate. Select the page here.
When your Bubble app is used as an OAuth provider, a GET call is made to:
https://[Your-App- URL]/version-test/api/1.1/oauth/authorizewith the client_id and redirect_uri as parameters.When this is successful, a parameter, "code", is sent back in the URL, to the external service
Next, the external service must execute a POST call to:
https://[Your-App-URL]/version- test/api/1.1/oauth/access_tokenwith parameters: "client_id", "client_secret", "redirect_uri", and "code". This is known as the token endpoint.Lastly, the app will respond with "access_token", "expires_in", and "uid" parameters that the external site can store for the user.
The access_token is used in future calls to the Bubble app from the user within the external app (until expiry)
Refreshing the token: In the POST body, set grant_type to "refresh_code" and send the refresh token as the refresh_token received previously. You will need to include the same client_id and client_secret used when getting the token in the first place.
Discourse SSO
For apps on the Professional plan and above, the Bubble app can be used as a single sign-on (SSO) provider for a Discourse forum.
For more information and set-up instructions on the Discourse side, please see this article.
Discourse base URL
This is the URL for your Discourse forum, where you want your app's end-users to be able to log into with their app username and password.
Discourse SSO secret
This is a token generated from Discourse.
Suppress welcome message flag
If this checkbox is not checked, any user logging in via your app into your Discourse forum will receive Discourse's welcome email.
Require activation flag
Checking this setting will have Discourse send email verification emails to any user who creates an account via SSO. This is generally recommended by Discourse.
Default avatar when creating the account
If this is set, all new users created via SSO in your Discourse forum will have this image as their initial avatar.
Advanced
Download public JSON web key
Certain custom integrations with other web services will require the "public JSON web key" of your Bubble app. This is where you can download it.
Other ways to learn
Last updated