# Faucet Rate Limit Exception — Automated E2E Testing for toodigital

**URL:** <https://forums.sui.io/t/faucet-rate-limit-exception-automated-e2e-testing-for-toodigital/49262>\
**Category:** Technical Support\
**Created:** [April 14, 2026, 12:59am UTC](https://forums.sui.io/t/faucet-rate-limit-exception-automated-e2e-testing-for-toodigital/49262 "2026-04-14T00:59:58Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![akiratata](https://dub1.discourse-cdn.com/sui/user_avatar/forums.sui.io/akiratata/32/31698_2.png) [@akiratata](https://forums.sui.io/u/akiratata)\
**Post date:** [April 14, 2026, 12:59am UTC](https://forums.sui.io/t/faucet-rate-limit-exception-automated-e2e-testing-for-toodigital/49262/1 "2026-04-14T00:59:58Z")

</div>

I’m building **\*\*toodigital\*\*** , a native music distribution app (Flutter + Rust) fully on Sui — zkLogin onboarding, Move contract catalog (sale/listing/catalog), decentralized vendor shops, and NFT purchases with fiat settlement. Currently on testnet, planning mainnet migration.

We run a fully automated E2E testing pipeline: cron-based contract redeployment after testnet resets (30-min monitoring → auto-republish 3 Move modules), Platform Wallet SUI drops to NFT buyers (5-min batch), and gas sponsorship for new zkLogin users (balance starts at 0). Faucet rate limits (`429 Too Many Requests`) cause our deploy to fail post-reset (10 retries × 60s still not enough) and drain our Platform Wallet, blocking all automated tests — sometimes for hours.

**\*\*Request:\*\*** Rate limit exception for 2 server-side wallets (~5-10 req/hour) to achieve near-100% faucet success during automated test runs. One wallet handles SUI drops and gas sponsorship, the other handles contract publishing after resets.

Happy to demo or share automation scripts. Thanks!

---

<div class="post-metadata">

**Author:** ![tanakarei\_0416](https://dub1.discourse-cdn.com/sui/user_avatar/forums.sui.io/tanakarei_0416/32/31701_2.png) [@tanakarei\_0416](https://forums.sui.io/u/tanakarei_0416)\
**Post date:** [April 17, 2026, 7:40am UTC](https://forums.sui.io/t/faucet-rate-limit-exception-automated-e2e-testing-for-toodigital/49262/2 "2026-04-17T07:40:08Z")

</div>

I’m smart contract and DeAI engineer with 7+ years. I’m very interested in your project. I want to implement this project together while sharing the development experience each other. Let’s contact for the future.

---

<div class="post-metadata">

**Author:** ![terranweb3](https://dub1.discourse-cdn.com/sui/user_avatar/forums.sui.io/terranweb3/32/31715_2.png) [@terranweb3](https://forums.sui.io/u/terranweb3)\
**Post date:** [June 23, 2026, 3:14pm UTC](https://forums.sui.io/t/faucet-rate-limit-exception-automated-e2e-testing-for-toodigital/49262/3 "2026-06-23T15:14:14Z")

</div>

Thanks for sharing the detailed context, this makes sense from an E2E reliability perspective.

That said, I would avoid depending on the public Devnet/Testnet faucet as a guaranteed part of your CI pipeline. The faucet is intentionally rate-limited and is shared infrastructure, so even with retry logic, it is not ideal for near-100% automated funding guarantees.

A more robust setup would be:

1. Run the majority of automated E2E tests on Sui Localnet  
Use a local network with its own faucet for deterministic CI runs, contract redeployments, zkLogin-like onboarding flows, marketplace/listing/purchase logic, and post-reset simulations. This removes public faucet rate limits from the critical path.

2. Keep public Testnet for smoke/integration tests only  
For Testnet, run a smaller set of scheduled or post-reset smoke tests instead of using it for every automated funding path.

3. Pre-fund and recycle a platform/gas sponsor wallet  
For zkLogin users with zero balance, the app should sponsor transactions from a funded backend wallet/gas station rather than requesting faucet funds per user. Add a balance threshold check and only request/refill when truly needed.

4. Add a centralized faucet queue + backoff  
If you still need faucet calls, make sure all services go through one queue, respect rate-limit responses, use exponential backoff with jitter, and stop retrying aggressively after a 429 to avoid extending the lockout window.

If this still requires an exception, I’d suggest sharing the two exact wallet addresses, expected request volume, IP/range, test schedule, and why Localnet cannot cover those cases. But structurally, I would treat faucet access as best-effort rather than CI-critical infrastructure.