There's not a hard limit - but brainCloud does encourage devs to work with us to keep scripts tight and efficient. That's the biggest reason why we charge per API call - the tighter and more efficient you can keep things, the less your app usage will cost you.
Scripts are more efficient than full-blown API calls - so they are encouraged.
brainCloud charges:
- 1 API Count to call the script
- You get 3 API calls from the script for free
- From then on, each API call is just 1/2 an API count
All-in-all, doing a bunch of operations from a script (instead of remotely from the client) is:
- A better user experience (the end-user doesn't have to wait for all the individual requests and responses to go back and forth to/from the remote device)
- Uses less server processing (receiving and breaking apart the messages is one of the bigger loads on the system)
- Costs the dev less (due to the API count rules above)
It's win:win:win!
Okay though - back to your question 
There aren't any specific limits to the # of API calls you can make. We do have watchdog timers on scripts, to help ensure that things aren't running awry. The default timeout is 10 seconds (though honestly most scripts take < 100ms to run).
That said, of course, the more calls you make - the more your scripts will cost you - and the more time your customers spend waiting for the script's response.
Also, client timeouts can sometimes interfere. If you've raised the timeout on your script to 20 seconds to allow it to do some big operation, but your client timeouts are set to the default 15 seconds - then often your client will timeout before the script is complete, and you'll cause extra server traffic as your client automatically retries.
Another observation - must issues folks have with scripts has more to do with how they are accessing data, than the script itself. It's less about the API counts, and more about how you're using Entities - especially Global Entities, whose performance can really slow down if you've got too many of them (i.e entering the thousands) or have entities being written to by too many people concurrently.
Okay - let me see if I can boil this down to a few straight-forward points:
- There are no specific limits on the # of API calls made from scripts
- Apps are charged per API call, so keeping the number lower is best for all
- Scripts are however more efficient (and less expensive) than making the calls from the client, so when in doubt, extra calls in scripts better than extra calls from the client
- The real thing to watch for is efficient data access. Global Entities are to be used carefully - User Entities and Custom Entities with proper indexes are much, much safer.
- In general, keep scripts to well under 1 second execution time for best performance.
- Scripts with 3-8 API calls generally perform best (totally off the top of my head). If you're getting 20+ API calls you probably want to rethink the script, unless it's some sort of periodic background script (i.e. scheduled, not from the client).
Hope that helps?
Paul.
