Notifications Overview

Every state change you care about — a transaction confirming, a pool migrating, an airdrop being claimed — is exposed two ways:

1. Push via webhooks — the preferred path. Subscribe a URL to one or more event types and the delivery worker fans events to it as resources transition.
2. Pull via polling — re-read the resource and branch on its status / lifecycle field. Useful as a fallback when you can't expose a webhook endpoint, or to backfill state.

Polling transactions

After submitting a transaction, poll GET /v2/transactions/{signature} until lifecycle reaches confirmed (or finalized, if you need stronger guarantees):

curl https://api.piratecrew.fun/v2/transactions/$SIGNATURE \
  -H "Authorization: Bearer $PIRATE_API_KEY"

{
  "data": {
    "signature": "...",
    "lifecycle": "confirmed",
    "confirmation_status": "confirmed",
    "err": null,
    "slot": 271234567,
    "confirmations": 12
  },
  "meta": { "request_id": "req_…" }
}

Three terminal states matter:

• lifecycle: "confirmed" (or "finalized") with err: null — success.
• err is non-null — the transaction was included but reverted. Stop polling.
• After your timeout window with no change — treat as dropped and resubmit (or surface to the user).

See Transaction Lifecycle for the full state machine.

Recommended backoff

Solana confirmation is typically sub-second to a few seconds. Use a short, capped exponential backoff:

If you bundle through Jito, the same polling loop applies — pull each bundle signature individually.

Polling on-chain state

For higher-level events — a DBC pool migrating to DAMM v2, an airdrop's claimed-count incrementing, a stake being recorded — re-read the relevant resource:

• Pool migration: GET /v2/pools/{address}/curve-progress
• Pool & partner fees: GET /v2/pools/{address}/fee-metrics and GET /v2/pools/{address}
• Arbitrary account: GET /v2/accounts/{address} or POST /v2/accounts/batch-fetch

Keep the polling interval reasonable — at least a few seconds between reads — to stay within your rate-limit budget. Rate limits are per API key; see Authentication.

When push delivery is an option, prefer webhooks — they remove the polling loop and the rate-limit pressure that comes with it.