POST /faucet/claims — Claim Testnet ADA
Submit a claim request for testnet ADA. The faucet validates the address, checks cooldown and IP limits, builds a funding transaction, and returns the transaction hash once the transaction is submitted to preprod.Request
Request Body
string
required
Bech32 preprod address to receive the ADA. Must start with
addr_test1, must carry a valid payment credential, must not be a script address, and must be a preprod (testnet) network address.string
required
A unique string identifying this claim request. Resending the same
idempotencyKey for the same address is safe — the faucet returns the original result rather than triggering a second transaction. Use a value that is stable across retries, such as a test run ID or a UUID generated at the start of your pipeline.string
required
A non-empty string representing the requester’s IP address (typically a hash). Used for per-IP daily rate limiting. When integrating through the Sundial web frontend, the proxy populates this field automatically. When calling the API directly, pass a consistent identifier for the originating IP.
Example
Success Response
string
UUID uniquely identifying this claim record. Use this for support requests if a claim fails to arrive.
string
Hex-encoded preprod transaction hash of the funding transaction. Look this up on a preprod block explorer to confirm the transfer.
string
Lovelace amount dispensed, returned as a string to preserve full integer precision.
string
ISO 8601 timestamp indicating when this address becomes eligible for another claim. Store this value to avoid unnecessary cooldown errors in subsequent requests.
Error Responses
The faucet returns structured error objects with a stablecode field alongside a human-readable error string. Handle these by code rather than by HTTP status or message text.
Error Response Shape
nextEligibleAt field is only present for COOLDOWN responses.
Error Handling Example
Idempotency and Retry Behaviour
Using a stableidempotencyKey makes the faucet safe to call multiple times in retry loops without risk of double-funding:
1
Generate a stable key
Create an idempotency key that is unique to this logical claim but stable across retries. A test run ID, a UUID generated once at startup, or a hash of
address + testRunId all work well.2
Call the faucet
POST the claim with your bearer token. On a
200 response, store nextEligibleAt and proceed with your test.3
Retry on transient failures
On
VALIDATION_FAILED or INTERNAL errors, retry with the same idempotencyKey. The faucet deduplicates by key, so even if the first attempt partially succeeded, the retry will either return the original result or trigger a fresh transaction safely.4
Respect cooldown signals
On a
COOLDOWN response, wait until nextEligibleAt before retrying. On IP_LIMIT, avoid retrying from the same IP for 24 hours.Web UI Alternative
If you prefer to claim tokens manually rather than programmatically, use the testnet faucet web interface at: https://sundialprotocol.com/testnet/faucet The web UI provides the same tokens as the API and shows your current cooldown status and estimated next eligible claim time.The faucet dispenses testnet ADA on the preprod network. These tokens are used for testing Sundial L2 transactions and covering transaction fees. They have no monetary value and cannot be transferred to mainnet.