Hi, I'm looking for some clarity on how many API requests we will be generating when using the JS or React SDKs. Can we say that a user will generate

x

number of API requests per page load (assuming a page with an experiment running)? My hypothesis would be an API request when

loadFeatures

is called and another when

useFeatureValue

or

getFeatureValue

is called, but can anyone confirm? I want to ensure we won't be close to the 10M limit on api requests/month for the free plan.

it would just be one API request on load features, all the other growthbook calls don’t cause an API request.

Oh, great! Thanks for the response. We are doing hybrid SSR + client-side, so we call

loadFeatures

on both the server and client side. Would that be 2 API requests then? (Looking at the code I see some caching logic, but want to confirm to what degree that will work)

yes, most likely two requests for hybrid

OK thank you!

Extending on this, I noticed that when a GrowthBook instance is created,

/api/features/<client_key>

is called, then

/sub/<client_key>

is called to subscribe to any updates. So minimally there will be 2 calls for each instance created, right? Are there any other API requests we should be taking note off?

No there should not be any others. You can disable SSE if you like by setting

backgroundSync: false

. https://docs.growthbook.io/lib/js#streaming-updates

If we set load features with

growthbook.loadFeatures({ autoRefresh: true })

, will the polling add to the API requests? If so, what is the refresh rate? I can’t seem to find this in the documentation 😅

Hi.

autoRefresh: true

is the legacy way of enabling streaming (SSE, not polling);

subscribeToChanges: true

is the preferred way going forward. The reconnect rate is currently set to 1 minute refresh intervals.

Oh nice, thanks for the clarification! So if I understand this correctly,

subscribeToChanges: true

should not affect the API requests, right? 😅

/sub

requests are included in the API limits.

I see, thanks everyone!