Terms of service questions around building third party tools

[boston85719]

@georgecollier

not Josh but

Yes, I read that commentary on the other thread previously. What I am hoping for is @josh or @emmanuel or perhaps @fede.bubble to provide an official bubble stance on the use of the APIs for these types of products/services so it is clear from the company what is an acceptable use versus not.

My main concern, is whether or not we can use a server to trigger these API calls or not. I do not want to have to build a product into a Google Chrome extension as that is adding an extra layer to my products I do not really want to need to use.

@randomanon

He just effectively confirmed it here.

He did acknowledge knowing about the product. But did not confirm what is or is not considered fair usage and what might fall foul of the policy since the question was not posed, so I asked it.

@randomanon

purpose of the Terms of Service is solely to protect the company’s business interests and users

That was actually what I thought it was, I appreciate the confirmation on that. Part of why I am asking for a response from Bubble on this is to understand what we can and can not use based on their interpretation of what goes against their business interests.

Simple example for you Rando, is the logs API. Already we know Bubble has requested buildprint and likely the other log services hitting the API on a schedule loop to attempt to provide a ‘log alert’ offering from their product was something Bubble was not happy about and why they asked them not to hit that API as frequently. Publicly it seemed to be due to a strain on resources, but I personally could interpret it as also against Bubble business interests since Log retention windows are tied into the different subscription tiers they offer, so if somebody is leveraging Bubble’s resources by hitting that log API, at Bubble’s expense, that is one reason for it to be against their business interests, but also it takes away a selling point of a higher subscription tier since users could just keep their logs in an external database and have a much longer log retention window than their bubble subscription plan provides for.

I am not asking the question to try and say I believe buildprint is doing something wrong. I am asking for clarification from Bubble as to what is or is not permissible, so that I know whether or not I, and any other developer, who wants to provide more innovative products to the bubble ecosystem need to use the google chrome extension workaround, or if we can in fact use severs to run these types of API calls, and perhaps, which internal APIs are off limits.

For me, it is in Bubble business interests to allow this, except the logs API. For me, it enables Bubble to leverage OPM and let the community handle more of the tasks to expand Bubble ecosystem so Bubble is free to do more of what the community can not (like bug fixes, uptime, performance etc.).

What I’d like to hear from Bubble is that using the internal APIs is not against fair usage policy and we can build products/services that use them, so long as we are using a collaborator account for the user session token, and using a server to run these is fine.

[georgecollier]

@boston85719

to attempt to provide a ‘log alert’ offering from their product was something Bubble was not happy about and why they asked them not to hit that API as frequently

That’s not the reason at all. It’s just that Bubble’s moving their logs to a new backend (which everyone benefits from), and during that cutover, they need some rate limits to ensure stability - Buildprint is accounting for a significant proportion of requests to Bubble’s logs endpoint.

So, the idea that they asked us to rate limit because our feature enabled stuff that’s not possible natively or it disincentivises users upgrading just isn’t true. The people that actually care about log retention windows are happy to pay $$$ to upgrade. And they know that Buildprint logs will inevitably become a paid feature after a generous free tier, because it costs us a lot of money.

Bubble naturally can’t dedicate engineering time to supporting third party tools, but we collaborate together where possible because we win together.

If Bubble asked us to stop something, would we? For sure. For example, we used to offer backfill on logs but stopped that because it led to too many requests.

But the reality is that Bubble benefits from good community integrations as long as they respect the platform systems, don’t affect end users, and just generally positively contribute to the ecosystem.

Besides, I know multiple people who’ve upgraded to Bubble’s growth plan to get access to multiple branches so they can better use the editing beta

Edit:

@boston85719

hitting the API on a schedule loop to attempt to provide a ‘log alert’

This is also not how log alerts work, we don’t poll for conditions that are met from Bubble, that would be very inefficient.

[boston85719]

@boston85719

Simple example for you Rando, is the logs API. Already we know Bubble has requested buildprint and likely the other log services hitting the API on a schedule loop to attempt to provide a ‘log alert’ offering from their product was something Bubble was not happy about and why they asked them not to hit that API as frequently. Publicly it seemed to be due to a strain on resources, but I personally could interpret it as also against Bubble business interests

@georgecollier

That’s not the reason at all. It’s just that Bubble’s moving their logs to a new backend (which everyone benefits from), and during that cutover, they need some rate limits to ensure stability - Buildprint is accounting for a significant proportion of requests to Bubble’s logs endpoint.

@Zeroic

Correct - we run a job every 5 mins that fetches the updated logs.

As for retention, yes, this extends further that the plan-specific limited period which Bubble offers (and unlike other similar tools that exist atm). We’ve currently set a TTL for 90 days in our OLAP DB, which we’ll be extending later depending on the demand

@georgecollier

PSA: We now account for a significant amount of Bubble logs requests so are throttling requests whilst they’re doing some planned backend work (that will improve logs for everyone, whether you use Buildprint or not). If you see log sync fall behind, that’s why.

@georgecollier if you read into what I said, the part where “I personally could interpret…” that is significant to the meaning of the statement, and why I am asking Bubble for clarification. It wasn’t meant to imply that it is the true reason, it was meant to significantly improve the understanding of why I would like clarification from Bubble about what might be seen by Bubble as against their business interests and therefore be something that would result in Bubble saying a service is going against their fair usage.

All I had to go on was what was publicly stated, which I summarized as ‘stop hitting it on a scheduled loop’…I had not gone back to see the exact quote from you saying ‘rate limited’ for a cutover period. I must have confused my expectations of another log provider looping every 5 minutes being reason for Bubble to request ‘rate limits’.

@georgecollier

So, the idea that they asked us to rate limit because our feature enabled stuff that’s not possible natively or it disincentivises users upgrading just isn’t true

Again, read it clearly, says “I personally could interpret” which doesn’t mean I am stating that it was the reason…it was meant to highlight why I am asking Bubble for clarification about what goes against fair usage and is potentially seen as against their business interests.

@georgecollier

If Bubble asked us to stop something, would we? For sure. For example, we used to offer backfill on logs but stopped that because it led to too many requests.

Maybe that is where some confusion came from, and I glanced over the concept of backfill logs.

@georgecollier

This is also not how log alerts work, we don’t poll for conditions that are met from Bubble, that would be very inefficient.

I guess you might be doing it differently than @Zeroic and Zerotrace…but by the way, I didn’t imply there is polling for conditions, just an idea of hitting the api every 5 minutes to get updates to logs, the way explained by @Zeroic and how Zerotrace does it.

@georgecollier

But the reality is that Bubble benefits from good community integrations as long as they respect the platform systems, don’t affect end users, and just generally positively contribute to the ecosystem.

Yes, that is why it would be great to know what kind of integrations or how to integrate that do not go against the fair usage policy statements I highlighted that for me personally, cause me confusion about how to provide such integrations.

[senecadatabase]

I think it’s great that users are creating things that help a lot…

however, I’ve been a little hesitant because of privacy issues. Maybe it’s me being naive when it comes to all this.

Example: Do I want someone knowing we bring in $500,000.00 monthly (example) down to the penny for our rental properties? Do I want someone knowing who our tenants are and their lease specifications?

The whole privacy issue is something that has been a stumbling block for me…maybe I’m looking at things wrong.

In my mind, I would hope Bubble would control things that could pose privacy leaks.

Just my thoughts, and maybe I’m not thinking about it the right way in how these outside tools work

[georgecollier]

Tbf you can just control permissions via collaborator and block access to live database if that’s a concern

[senecadatabase]

Thanks, I’ll look into that.

Security these days is a multi-billion-dollar industry, and some of it worries me when it comes to running an app…so I try to be vigilant.

Tenants’ phone numbers, work, weekly salary, etc. I try to do everything possible to secure the info.

There have been other outside tools that have bothered me. I think it’s important for them to discuss privacy… even though I would suspect some of it is just talk.

Thanks again for your follow-up. I’ll look into what you said

[boston85719]

@senecadatabase

think it’s great that users are creating things that help a lot

Yes, and I want to see more of it. Would like clarity on which internal APIs we can or can not use and whether we can use them via a server or must run them in browser as Chrome extensions do.

@senecadatabase

however, I’ve been a little hesitant because of privacy issues. Maybe it’s me being naive when it comes to all this.

I don’t think you need to share the data in database to make use of them, just data structure.

My questions are not focused on security or privacy of the 3rd party tools. It’s more about clarity on what we can build without violating fair usage policy of bubble.

[fede.bubble]

@boston85719

. It’s more about clarity on what we can build without violating fair usage policy of bubble.

I wouldn’t expect Bubble as an organization to make any blanket statements in matters such as this. If you have a project you are working on and want some clarity, I would recommend you reach out to Bubble for clarification on a case by case basis (probably?).