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.