Terms of Use for APIs, clarification

Is it possible to get a bit more clarification about the terms of use section 2.8 https://www.cloudflare.com/terms/ on serving non-html content. A recent thread talked about this and a reply (now removed) said that APIs are technically in violation, although implied that volume would come into consideration too.

I fully understand CF position and am able to change my API handling if needed, but I dont really know what CF are trying to restrict with this clause in the terms.
All of my questions are around using “orange cloud” - we want to protect our API origin(s). However we are very happy with the CF service so aren’t looking to move. Our volumes are currently quite small too, but should grow over time. (And sidenote, the recent changes to dashboard stats is great - we can see some places we can reduce volume). And to be super clear, this is mostly me being paranoid about what the TOS say, being forced to suddenly change would hurt - I want to do the right thing.

Question 1.
Are API calls are excluded per this section or not? There are documents from CF explaining how to setup APIs to be handled behind CF, including how to cache or not cache, and even how zendesk APIs are configured.
I am mainly asking about APIs that include private content, which may or may not be marked with s-maxage headers.

Question 2
Are you able to explain what drain/load you are trying to avoid on your POPs? I can imagine it is either network bandwidth, request volume or amount of data in your POP cache. In some cases we can bypass CF (unique to us) and secretly connect to our origin(s) (And we have prioritised doing this more, now that we’ve seen this clause)

Question 3
We’ve been experimenting with Load Balancer to select different origins, although we primary want to drive to Pool(A) and use Pool(B) when A is unavailable. Does this affect anything? I doubt it, but best to ask.

Question 4
I am guessing that the clause 2.8 is focused on “orange cloud”, if we switch to “grey cloud” and only use DNS services, I presume this clause no longer applies? Should we switch all API calls to a subdomain and use “grey cloud”?

What we do
We deal with live business transactional data. Much of it is secure and private. APIs are used to share data between a single businesses users at different physical locations
We have a number of origins of our own, (not all on CF yet), and some businesses have their own specific origins as well. We are more a geodistributed “edge” type solution, not so much a central “server”.

What we want to achieve
We wish to hide all origin IP addresses. This is our primary reason for using CF
We do like being able to cache API responses in CF -not everything is private and non cacheable, but this isn’t a show stopper.
Not adverse to paying as we grow, but would like to understand where limits might exist. We did enquire about enterprise pricing, but we aren’t there yet in terms of revenue.

Some pseudo examples, in case it helps
a) GET /Api/SystemStatus.json
This is a shared api for all users. Response is public, cached up to 30 minutes
b) GET /Api/SystemStatus/SJFIVJVJHGJ583bfVdfjsh3hth.json
This is a semi private response for a single business, where only that business knows the SJf… part. Response is public, cached for up to 30 minutes
c) GET /Api/SomeSafeData/SJFIVJVJHGJ583bfVdfjsh3hth.json
This is a semi private response with real data, but is considered low risk. Response is public, cached for various times depending on other factors
d) GET /Api/SomePrivateData/SJFIVJVJHGJ583bfVdfjsh3hth.json
This is totally private, and marked private, no-cache, no-store as relevant.
e) POST/PUT /Api/SaveData
Most common operation, sending data to servers. Responses overwhelmingly marked no-cache

Thanks
.R
NB. Not complaining at all, simply trying to understand what you want us to do and how best to architect solutions.

.

:wave: @rbrett,

So the answer is a bit vague… if your business is delivering petabytes of traffic via API for your video streaming service where you are intentionally subverting Cloudflare’s TOS then you are screwed. If you are running a legit business you almost certainly have nothing to worry about even when your data volumes are ver large.

I have seen a number of threads where streamer_bob is totally shocked, shocked I say, that their account was suspended for violation of terms of use when their ‘totally legal’ stream of Indian cricket matches on a rotating series of throwaway domains with 100% of the content being video segments.

APIs are a fundamental part of teh interwebs. Cloudflare has companies your parents would know using all plan types. As a baseline use ‘don’t be a d*ck’. If you think you might be getting close to that line you can always ask their sales department I suppose, but in general what you described sounds like a perfectly reasonable use of the service.

— OG

1 Like

Also just for fun… workers offers some really fun ways to do advanced handling of JSON responses, especially for cached data. Depending on what you are building offloading from your origin to workers can really help with scale as you grow.

Based on the thoughtful questions (as asked) in my experience you have less than zero risk.

:wave: @rbrett,

And if you can’t trust the opinion of a Pug on the Internet, is it really a place you want to do business? :crazy_face:

— OG

This topic was automatically closed after 14 days. New replies are no longer allowed.