You can embed a Solana data API in your app on a standard plan — but the moment you resell the data, expose it as your own feed, or strip the branding, you're in licensing territory most builders discover too late. This guide maps the three usage zones (internal use, user-facing display, redistribution), the questions to ask any data vendor before you build, and what an Enterprise data license actually covers: white-label, bulk export, extended caching, SLA, and dedicated limits.
Polling the Wallet Tracker API on a schedule works well for many use cases — batch analytics, daily reports, backfill jobs. But when you need to react to a swap as it happens rather than minutes later, polling falls short. Webhooks invert the model: instead of asking "what happened recently?" on a timer, you register an endpoint and the API notifies you the moment an event is indexed.
This guide is a complete reference for working with the wallet_tracker:event webhook from the Solana API. It covers everything from initial configuration to production-grade payload handling, including signature verification, event type differences, filtering strategies, and retry semantics. For the broader context of building Solana notification systems, see the Solana alerts and notifications guide.
Webhooks are available on PRO and ULTRA plans. Get your free API key to get started — you can prototype on BASIC with polling before switching to webhooks. New to the Wallet Tracker entirely? Start with the setup tutorial, and pick your watchlist with the KOL smart-money guide.
How Wallet Tracker Webhooks Work
When you configure a webhook URL on your account, the API starts pushing wallet_tracker:event payloads to that endpoint for every swap and transfer made by any wallet in your watchlist. The flow looks like this:
- A wallet in your watchlist submits a transaction on Solana
- The transaction is confirmed and indexed by the MadeOnSol pipeline
- The API constructs a webhook payload and sends a POST request to your registered URL
- Your server responds with a 2xx status to acknowledge receipt
- If the delivery fails (non-2xx or timeout), the API retries with exponential backoff
The key property to understand: webhooks fire per event, not per poll cycle. If a tracked wallet makes 10 swaps in 30 seconds, you receive 10 separate webhook calls. This is what makes webhooks useful for alert bots — there is no batching delay.
The full endpoint reference, including how to register and update your webhook URL, is in the API docs.
The Webhook Payload Structure
Every wallet_tracker:event webhook delivery is a JSON POST with a consistent envelope:
{
"event": "wallet_tracker:event",
"api_version": "v1",
"delivered_at": "2026-04-15T09:22:13Z",
"data": {
"id": "evt_01hx9k3m2n4p5q6r7s",
"wallet": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
"wallet_label": "KOL: Alpha Finder",
"event_type": "swap",
"action": "buy",
"token_mint": "DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263",
"token_symbol": "BONK",
"sol_amount": 15.72,
"token_amount": 4820000,
"price_usd": 0.0000032,
"signature": "5KgVX2mN7...",
"slot": 312847291,
"timestamp": "2026-04-15T09:22:11Z"
}
}
Top-Level Fields
| Field | Type | Description |
|---|
event | string | Always wallet_tracker:event for this webhook type |
api_version | string | API version — use for forward compatibility checks |
delivered_at | ISO 8601 | When the API attempted delivery (not when the tx happened) |
data | object | The event payload — see below |
Data Fields
| Field | Type | Description |
|---|
id | string | Unique event ID — use for deduplication |
wallet | string | Solana public key of the tracked wallet |
wallet_label | string | null | Label you assigned when adding the wallet, if any |
event_type | "swap" | "transfer" | Type of on-chain event |
action | "buy" | "sell" | null | Direction of the trade (null for transfers) |
token_mint | string | SPL token mint address |
token_symbol | string | null | Token symbol (resolved from on-chain metadata) |
sol_amount | number | SOL value of the trade |
token_amount | number | Token quantity |
price_usd | number | null | USD price per token at time of swap |
signature | string | Transaction signature |
slot | number | Solana slot number |
timestamp | ISO 8601 | When the transaction was confirmed |
Swap vs Transfer Events
The two event types require different handling logic.
Swap Events (event_type: "swap")
Swap events are DEX trades — the wallet exchanged one token for another through a program like Jupiter, Raydium, or Orca. These events always have an action field ("buy" or "sell"), a sol_amount, and a token_amount.
A "buy" means the wallet spent SOL (or a SOL-denominated token) to acquire a token. A "sell" means the opposite. The sol_amount is normalised to SOL value — even if the underlying trade was USDC → TOKEN, the API converts the USDC value to its SOL equivalent so you have a consistent unit for size filtering.
Swap events are the primary signal source for most use cases — copy trading, whale alerts, KOL tracking. To decide which wallets are worth registering in the first place, our Solana wallet win rate leaderboard API guide covers pulling ranked, performance-filtered addresses to populate your watchlist.
Transfer Events (event_type: "transfer")
Transfer events are direct SPL token movements between wallets — no DEX involved. These do not have an action field and the sol_amount represents the SOL equivalent value of the transferred tokens.
Transfers are useful for:
- Distribution detection — a team wallet sending tokens to many addresses before a launch
- Portfolio tracking — a whale consolidating positions into a cold wallet
- Bridge activity — tokens arriving from a cross-chain bridge
For most trading signal use cases you will filter to event_type: "swap" only and ignore transfers.
