Guides
  1. Sandbox

Sandbox Overview

Sandbox Overview

The PirateCrew Blockchain API is production-first. We don't run a separate test host or a test-key tier — everything points at https://api.piratecrew.fun, and every key is a real key with real rate limits.

For now, "sandbox" means Solana devnet plus a few conventions for keeping test data out of your way. This page is honest about the gaps so you can plan around them.

What you get today

  • Devnet RPC: pass network: "devnet" to the SDK, or override rpcUrl to your own devnet endpoint (Helius / QuickNode devnet works fine).
  • Devnet faucet: Solana's public faucet at faucet.solana.com — see Test Wallets & Faucets.
  • Read-only API calls (PDA derivation, account fetch, batch reads) work identically across mainnet and devnet — they're pure compute or RPC pass-throughs.
  • Transaction simulation (POST /v2/transaction-simulations) works against whichever cluster your rpcUrl points at. Great for dry-running anything. See Simulating Transactions.
  • The same API host — there's no separate api-sandbox.piratecrew.fun. You're talking to production; the cluster is what changes.

What you don't get

Be aware of these gaps before you build your test plan:

  • No isolated test database. Your devnet pool's launched_crews row sits in the same Supabase table as mainnet pools. Pick test tickers that won't conflict with production launches.
  • No devnet platform wallet. mode=signed relies on the Privy platform wallet — there is only one, and it's mainnet. Server-signing flows are very hard to test in isolation; prefer mode=unsigned for sandbox work. See Test Wallets & Faucets for the workaround.
  • No test-tier API key. Every key is a real key with real rate limits. If you want a separate budget for testing, generate a second key at developer.piratecrew.fun and treat it as your sandbox key.
  • No built-in faucet endpoint. We don't expose /v2/devnet/airdrop — use Solana's faucet directly.
  • Some Pirates programs are mainnet-only. Staking, gold, and the airdrop program are deployed on mainnet only at the moment. Read endpoints will 404 on devnet for those.

Recommended testing workflow

  1. Generate a second API key at developer.piratecrew.fun. Label it sandbox so you don't mix it with prod traffic.
  2. Use the SDK with network: "devnet" and a devnet rpcUrl. Your local code path stays identical; only the cluster changes.
  3. Prefer mode=unsigned for everything — sign with a throwaway devnet keypair (see Test Wallets & Faucets).
  4. Simulate first via POST /v2/transaction-simulations before you submit. It costs you nothing and surfaces 90% of mistakes — wrong PDA, insufficient funds, instruction-level errors. See Simulating Transactions.
  5. Walk through devnet end-to-end at least once before flipping the cluster to mainnet. See Devnet Walkthrough.

When you must test against mainnet

Some flows (server-signed fee claims, gold unlocks tied to a real veGOLD position) can't be meaningfully exercised on devnet. For those:

  • Use small amounts — the smallest amount that produces a non-trivial side-effect.
  • Send Idempotency-Key on every write to make accidental double-submits inert.
  • Keep a paper trail of every signature for reconciliation.

Treat mainnet test traffic as production traffic that happens to be small. The rate limiter doesn't know the difference.

We'll publish a proper sandbox host with isolated data when there's enough demand. Until then, devnet + a sandbox key is the supported path.