Environments & Base URLs

There is one base URL for the PirateCrew Blockchain API:

https://api.piratecrew.fun

There is no api-sandbox.piratecrew.fun, no api-staging, and no api-devnet — the API service itself runs in a single environment. What changes between mainnet and devnet is the RPC endpoint the service talks to when it builds or submits a transaction.

One API version, one host

The root / redirects to /v2/docs.

Switching to devnet

For endpoints that accept an RPC override (most write endpoints in /v2/swaps, /v2/transactions, /v2/tokens, and the pool / fee-claim builders), pass an rpc_url field in the request body:

curl -X POST https://api.piratecrew.fun/v2/tokens \
  -H "Authorization: Bearer $PIRATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Devnet Test",
    "symbol": "DEV",
    "rpc_url": "https://api.devnet.solana.com",
    "mode": "unsigned"
  }'

If rpc_url is omitted the service uses its default mainnet RPC. Read endpoints (account fetch, pool curve progress, tx status) default to mainnet — pass ?cluster=devnet or the same RPC override where supported.

Shared server-side state

The API persists state in Supabase tables that are shared across all clusters:

• launched_crews — DBC pool registry used by POST /v2/pools and every fee-claim route.
• api_keys — your Bearer keys, rate limits, and scopes.
• idempotency_keys — your Idempotency-Key cache.
• merkle_trees — persisted airdrop trees used by GET /v2/merkle-trees/{id}/proofs/{wallet}.
• events — webhook event log.

The practical consequence: a devnet pool you create through POST /v2/pools will appear in the same registry as your mainnet pools, with the same ticker-cooldown rules, the same fee endpoints pointed at it, and the same idempotency cache. Pick distinct tickers when testing on devnet, and don't expect devnet entries to be auto-purged.

Your API key, scopes, and rate-limit counters are also shared — devnet calls consume your mainnet quota.

Health and reachability

curl https://api.piratecrew.fun/v2/health

A 200 with data.status: "healthy" confirms the service is reachable; it does not check downstream RPC liveness. See Status & Incidents for what to do during outages, and Sandbox Overview for the broader devnet testing story.