ACS Developer Sandbox automatic plan upgrade behavior in Titanium SDK 8.0‑9.x
0 reputation · 29 Apr 2025, 22:37 UTC
0 reputation · 29 Apr 2025, 22:37 UTC
Goal: Keep a low‑traffic Appcelerator Titanium app on the free ArrowDB (ACS) developer sandbox to avoid unexpected billing while still using SDK 8.0‑9.x.
Constraints/uncertainty: The free sandbox provides up to 1 M API calls per month, but the switch to the paid plan occurs automatically and silently when the quota is exceeded, with no CLI or build‑log notification. Additionally, Titanium SDK 10+ removed the explicit acs sandbox flag, so relying on the legacy acs enabled=\"false\" mode=\"dev\" configuration may generate warnings or be ignored, making the cost‑saving behavior unreliable.
How can developers programmatically detect when the free sandbox quota is approaching its limit? Is there a supported CLI command or ACS API to query current usage and remaining quota? What configuration should be used in SDK 10+ to retain the free sandbox behavior without triggering build warnings or falling back to paid services?
35275 reputation · 30 Apr 2025, 05:37 UTC
There is no Titanium CLI command that reports ACS sandbox usage. The only programmatic way to check current quota is the ArrowDB Admin API endpoint GET https://api.cloud.appcelerator.com/v1/apps/<app_id>/usage called with your master API key. In SDK 8.0–9.x the <acs enabled="true" mode="dev"/> element in tiapp.xml selects the free sandbox. In SDK 10+ that element is ignored (and may warn); you must instead initialize the Cloud module in code: Ti.Cloud.enabled = true; Ti.Cloud.mode = 'dev'; and include the ti.cloud module.
calls_used, calls_limit (1,000,000 for the free sandbox), and reset_date. Requires the master key—never embed it in client code.appc nor ti exposes a quota-check subcommand.acs flag is removed. Use Ti.Cloud.enabled = true; Ti.Cloud.mode = 'dev'; in your alloy.js or app.js and add ti.cloud to the modules section of tiapp.xml. This avoids deprecation warnings and keeps the app on the developer sandbox.The Admin API usage counters are probably cached for a few minutes, so a real-time throttle based on the API could briefly exceed the limit. The silent-upgrade behavior is not formally documented by Axway/Appcelerator and could change without notice.
curl -H "Authorization: Bearer <MASTER_KEY>" \
https://api.cloud.appcelerator.com/v1/apps/<APP_ID>/usage
Parse calls_used and calls_limit; alert when calls_used > 0.9 * calls_limit.<acs enabled="true" mode="dev"/> in tiapp.xml.acs element. In tiapp.xml add:
<modules>
<module platform="commonjs">ti.cloud</module>
</modules>
In your entry file (e.g., app.js):
Ti.Cloud.enabled = true;
Ti.Cloud.mode = 'dev';calls_used increments while the plan remains "developer sandbox" in the ArrowDB dashboard.Do you have a server-side component (Node.js, Python, etc.) where you can safely store the master key and run the periodic Admin API check? If the answer is no, you cannot programmatically monitor quota without exposing the master key, and you must rely on the ArrowDB dashboard or email alerts (if configured).
Use comments to ask for clarification. Post a solution as an answer.
5,650 reputation · 30 Apr 2025, 03:06 UTC
To avoid surprise upgrades, poll the ArrowDB Admin API GET https://api.cloud.appcelerator.com/v1/apps/<app_id>/usage from a secure server, using your master API key in the Authorization header. The JSON payload includes calls_used, calls_limit (1,000,000 for the free sandbox) and reset_date. Because the counters are cached for a few minutes, set the polling interval to at least 5 minutes and trigger an alert when calls_used exceeds 80 % of calls_limit. Never embed the master key in client‑side Titanium code; keep the call in a backend service or cron job.