Integrations
Part of No-code costs and vendor risk
Reviewing dependencies on paid plugins
Inventory paid plugins, trace the tasks that use them, check billing and support, and plan a safe response to an update or failure.
Review a paid plugin by tracing the tasks that use it, its full billing arrangement, and the work required if it changes or stops working. A small fee can still support an essential payment, sign-in or data action that is difficult to replace.
Trace each plugin through the app
For every installed plugin, record its name, provider, app, version, billing arrangement and account owner. Find its elements, events, actions and data sources in the app. Ask what user task fails if each use is unavailable. Keep keys and secrets out of the register.
Bubble plugins can add elements, events, actions and data sources. A plugin subscription can be changed to a one-time licence fee by cancelling the subscription and purchasing the licence. A service reached through a plugin may have its own account and charges.
| Dependency | Question for the owner |
|---|---|
| User task | What can no longer be completed? |
| Data | What does the plugin read, write or transform? |
| Access | Which service account or key does it use, and who maintains it? |
| Billing | Is there a recurring, one-time or separate service charge? |
| Replacement | Is there a supported built-in or maintained alternative? |
Check the bill and update route
A plugin subscription is charged on a later bill for time it was active. It follows the paid app plan's billing frequency, so an annual app plan can mean an annual plugin subscription.
A credit covers remaining time after removal. Check the app's invoice and terms to confirm the full billing arrangement. Count a plugin separately in each app where it is installed.
A new Bubble plugin version does not automatically take effect in an installed app. The owner can select a version in development and assess it before deployment. An older version may be selectable, but Bubble does not guarantee it will remain available indefinitely. Record who supports the plugin, and confirm the support route with the plugin creator or its marketplace listing.
Key facts about plugin billing and management
- Billing frequency
- Matches the app’s plan (e.g. annual for an annual app plan)
- Credit upon removal
- Remaining time covered by credit; check invoice and terms
- Version control
- New versions don’t auto-deploy; owner selects version in development
- Support route
- Confirmed via plugin creator or marketplace listing
Decide how to manage the dependency
For each essential plugin, identify an immediate response if its action fails. A document-generation failure might allow a controlled manual route; an uncertain payment action needs its provider's result checked before a retry. The safe route depends on the business task.
Keep a plugin when it performs a defined task under acceptable terms and has a support owner. Replace it when an alternative performs the same task in the configured app. If replacement is not practical, limit its use, document its inputs and outputs, and establish an exception route where the task permits one.
Before changing a version or removing a plugin, use safe records in a suitable development setting to check the normal task, a failure and the saved result. Record the observations and the affected workflows before changing the live app.
