Skip to main content
Uniblock does not replace your claim contract or distribution logic, but it can cover a large part of the surrounding campaign data layer: holder checks, transfer tracking, event monitoring, NFT ownership checks, and post-launch reporting.

Best-fit workflows

  • Monitor token or NFT distribution progress
  • Verify recipient activity and holdings
  • Trigger internal workflows from transfer or contract events
  • Build campaign dashboards for launch teams and community ops
  • GET /token/transfers
  • GET /token/activity
  • GET /token/balance
  • GET /nft/is-airdrop
  • GET /nft/is-nft-holder
  • GET /nft/transfers
  • Webhook quickstart

Suggested implementation flow

1. Define the eligibility read path

Depending on the campaign, eligibility can come from:
  • token balances
  • NFT ownership
  • historical wallet activity
  • contract interactions
Use the unified read layer to centralize those checks before users ever reach the claim flow.

2. Monitor campaign movement

Once distribution begins, use token, NFT, and transaction endpoints to track:
  • how many wallets received assets
  • which wallets moved or sold immediately
  • whether claim activity is still active

3. Add webhook-driven operations

Webhooks are useful for:
  • internal notifications when claims happen
  • syncing campaign databases
  • triggering CRM or growth workflows
  • detecting large movement from campaign wallets

4. Close the loop with analytics and logs

After launch, use:
  • Analytics & Logs to understand request usage during campaign spikes and debug malformed requests

Common pitfalls

Eligibility logic is application-specific. Keep your business rules in your own backend even if Uniblock powers the underlying reads.
Campaign traffic is bursty. Load-test your own systems and watch Uniblock rate limits before a public launch.