API
Last updated
Was this helpful?
Last updated
Was this helpful?
This core reference entry is suited for all experience levels.
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.
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.
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.
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 section for more details.
Warning
Hiding this may break some Bubble App Connector features.
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/authorize
with 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_token
with 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.
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.
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.
This is a token generated from Discourse.
If this checkbox is not checked, any user logging in via your app into your Discourse forum will receive Discourse's welcome email.
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.
If this is set, all new users created via SSO in your Discourse forum will have this image as their initial avatar.
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.
Article: