Theoretical Question - APIs - connector vs plugin

Has anyone ever tested or know if there is any difference in performance between creating your API calls through the API connector or creating your own plugin for the API and using that?

Or any other pros and cons to consider between the two options?

I will be using this particular API in multiple apps (though different set ups for the calls as slightly different use cases) which is the main reason I am tossing up creating a plugin as it would save me some time down the line but just wanted to hear opinions from the brains trust.

I think Bubble’s API Connector is meant for insuring security. I know for me, I find using a plugin and running an API call in there is sometimes easier just because that is what I am used to but I know it is less secure. Curious to hear what others think.

What makes it less secure?

1 Like

I think when you use a private key for an api with the connector and mark it as such then they make sure that no one can access it. When I use an api call with a private key, I am not doing anything to secure it or keep it hidden. I tried to publish a plugin one time where I used private keys but I did not use their connector and it was denied so I assume that was the reason. Honestly I do not know much on the subject but that was my impression.

I generally opt for creating a private plugin as oppose to building the call in the API Connector.


  • Easier to separate calls to different platforms
  • Version control
  • Define and initialise the calls once and use them for multiple apps
  • Can easily add actions that might be relevant to the API calls for additional parsing required
  • Testing mode enables you to trial changes without actually changing the published API call
  • Can choose if keys are public, hidden or secret whereas API Connector only lets you choose public or private (which is the equivalent of secret I believe).
  • Easy to commercialise/share with the community


  • Harder to make quick changes (but can use testing mode which works really well)
  • Attempt to make the call from the browser doesn’t exist as an option

I wasn’t aware of any differences in security between the two (except obviously making calls from the browser requires everything to be exposed). It’s hard to comment on @williamtisdale and his experience but by setting a key as secret in the plugin builder, it does exactly that. It’s not shown on the frontend. If he submitted a Commercial or Open source plugin (which I wouldn’t do unless it really was for public use), then I can imagine Bubble rejecting it if his keys weren’t set to secret or hidden.


Thanks, that’s very helpful :slight_smile:

What sort of things would you need to attempt to make the call from the browser? Just to know what use case this con would apply to - I’m still learning about APIs.

I’m not sure about the security issues either. Lots of plugins for payment gateways around and I’ve never heard of any security issues cropping up around those…but perhaps as you say it was more of the set up of the plugin than an inherent security issue with plugins in general.

I think the key use case was around public APIs that rate limited requests if they all came from the same source IP (say Bubble’s server). If you have a public API like perhaps a weather API and you want to avoid getting rate limited, you might want to run the call on the browser and therefore use the users IP. This would mean that each call would be coming from a different IP, and therefore less likely to hit a rate limit.

You can read all about the announcement here; [New Feature] Make API call directly in the browser, if possible

Yeah I think so. I’ve chatted to Bubble before around plugin security and they did make some minor changes as part of my request but it’s also worth pointing out that the items I raised weren’t really super clear breaches and were more around tidying up a few things from a best practice perspective.

Ahh cool thanks :slight_smile: Not a con I need to worry about for my use case then :slight_smile:

Looks like I’ll be getting more familiar with the plugin builder haha!

That’s a good question, you are asking here.

Personally, I try to avoid plug-ins as much as I can. Almost all the time I’m developing apps for clients and I really don’t want to run in a situation where the plug-in is no longer supported and certain functionalities do not work. That doesn’t count for Plug-ins which are originally developed from Bubble.

I also think that some plug-ins are just not worth the money. Especially if you know a little of programming or to handle API requests.

On top, I run into a situation where I saw that the API documentation provides more endpoints, but the plug-in doesn’t (which makes total sense in most cases).

Therefore, I go most of the with private plug-ins which I use for my own apps or I create normal API calls.

1 Like

Thanks for your thoughts Sarah :slight_smile:

I probably should have been a little clearer - I’m not asking about using a public plugin. I was asking for any pros/cons/things to consider between building your own private plugin for an API vs just doing it in the API connector :slight_smile:

The main benefit to building your own plugin I thought was time saving when you know you will implement in multiple apps…but @juicebox shared some other pros as well :slight_smile:

I have been working out the implementation of this particular API via the API connector at the moment as I’m familiar with that - but I will be exploring the plugin builder and creating my own when I have a bit more time to give to that :slight_smile:

I’d opt to build my own if I need to clean up the response at all. It also makes it easy to share your calls between apps or users. That’s for sure.

The interfaces are nearly identical. Not only that, but you can copy/paste from the API Connector to the plugin editor’s API tab; so when you’re finished with your calls in the API Connector, you’re nearly done. Just right click on a call to get the copy/paste menu.

Note also that the API connector says you can “convert your connections into plug-ins”. I’m honestly not sure what that means unless it’s referring to the ability to copy/paste calls.

And lastly, another advantage to building a plug-in is that you can sell it in the marketplace if you so choose.

Good luck!



Sheeetttt!!! That’s awesome!!!

1 Like

Hey Equi,

Love that you asked this and hope you are doing great. I see your really active here and I always love your questions.

Did you make the plugins in the end and did you find any speed gains. Was this the best method in the end?

Actually another question I have regarding this, if we create a plugin can that plugin exist in our clients app if once we hand the app over to them and it’s no longer linked to our account?

Hi Chad,

No I didn’t end up making the plugin - I had planned to set up the calls in the API connector of the first app then copy in to a plugin at a later stage as Sudsy had suggested however I didn’t end up continuing with the API as the provider actually fell a bit short on promised features and I went another direction.

Re the handing over of client apps with a private plugin - from what I understand is that the app itself retains the permission for the plugin (like any public plugin) however you retain control over the plugin itself unless you also transfer the plugin, but then you wouldn’t be able to utilise it in any other client app :slight_smile: So probably as an agency it’s a good idea to have a range of private plugins as you’ll be able to use them over and over without having to redo the work on the API set up.

Spot on. Our apps would be little more than static web-pages without our custom private plugins…And there is such a large diversity in API specifications that I always end up having to write NodeJS server-side actions to handle requests. A fairly robust design pattern really doesn’t take much more than a dozen lines of code and provides exponentially more functionality in processing the API call responses.

And any concrete feedback on speed vs API connector?

1 Like

Same question. I’ve noticed that API calls made through the Bubble API connector are slower in comparison to most other No-code competitors. Specifically, when using Xano as a database for Bubble, the response times are noticeably slower. I am curious if by using a custom plugin and some node hacks, we can optimize the speed of these calls. Has anyone compare both methods?

API connector will always beat ssa’s used in bubble plugins since ssa’s always have that 1 run to warm up. However, you can also use the api connector within plugins. And you secure keys by using context.keys[‘private key name’] within ssa code.

API Connector > than SSA Calls

1 Like