PumpView Solana Trades API: agent quickstart

PumpView supplies filtered Solana swap summaries through REST, WSS and Model Context Protocol (MCP). Its trading API builds client-signed swaps, submits them through Kolibrio, reports execution at confirmed, and tracks account/API-key trading volume. Check /v1/swaps/config for current availability. API version: v1. Event schema version: 1.

Packages and limits

Plan ID Package Price Access period Credits Filter entries Concurrent WSS per account HTTP requests/sec per account
day Day Pass 2 USDC 1 days 100,000 10 1 3
starter Starter 19 USDC 30 days 1,000,000 25 1 5
builder Unlimited 49 USDC 30 days Unlimited 100 1 20

All API keys on an account share its packages and one concurrent WSS connection. Buying more packages or creating more keys does not increase that connection limit. Optional per-key lifetime budgets still apply to Unlimited. Authenticated HTTP requests and MCP tool calls share the account's request limit shown above, across all keys and account sessions. The highest unexpired package applies; limits do not add up. Accounts without a package have a 3 requests/sec limit for account, payment and trading operations; a paid package is still required for trade data. On HTTP 429, wait at least the Retry-After interval. Filter entries count the combined mint, wallet and DEX filters; an unfiltered subscription is supported.

One delivered event consumes one credit. Empty REST or MCP trade queries consume one credit; empty WSS messages do not. Replays consume credits again. Unlimited has no event allowance cap. Packages are prepaid, expire after their stated period, and do not auto-renew. Check /v1/plans before buying; prices and availability are returned there.

Option A: use your PumpView account

Sign in at https://pumpview.fun/developers#account with Google, Phantom or Telegram. Create a dedicated API key, optionally set a lifetime budget, and buy a package. A key is shown only once; store it securely. You can see usage and revoke keys in the dashboard. Link a Solana wallet there if your account does not already have one.

Authenticate data requests with Authorization: Bearer <PUMPVIEW_API_KEY>. Never place keys in URLs, public prompts or shared logs.

curl "https://api.pumpview.fun/v1/trades?limit=10" \
  -H "Authorization: Bearer $PUMPVIEW_API_KEY"

Use mint or wallet on GET /v1/trades for a single filter. For combinations, POST /v1/trades/query with:

{"mints": ["TOKEN_MINT"], "wallets": [], "dexes": [], "side": "buy", "min_sol": 1, "limit": 100}

Filter groups combine with AND; entries inside a group combine with OR. side is buy or sell. limit is 1–500 and controls the number of journal events scanned, not a guaranteed number of matching results. Omit a filter or use an empty list to accept all values in that group.

Option B: an agent obtains its own access

  1. POST /v1/agent/challenge with {"wallet":"SOLANA_PUBLIC_KEY"}.
  2. Sign the returned message's exact UTF-8 bytes with the wallet's Ed25519 signing key. Encode the signature as base58. The challenge expires in 300 seconds and is single use.
  3. POST /v1/agent/access with wallet, nonce, signature and an optional name. Store the returned API key. A linked wallet resolves to the existing PumpView account.
  4. Authenticate POST /v1/invoices with {"plan":"builder"} for Unlimited, or another plan ID from /v1/plans.
  5. Inspect the invoice: Solana mainnet, native USDC, payer, recipient, raw amount in six decimals, expiration and the pumpview:<invoice-id> memo.
  6. POST /v1/invoices//transaction to obtain an unsigned Solana transaction and last_valid_block_height. Verify its contents, sign with the payer wallet and submit through your Solana RPC. If the blockhash expires before submission, prepare a new transaction for the same unpaid, unexpired invoice.
  7. POST /v1/invoices//confirm with {"signature":"TRANSACTION_SIGNATURE"}. A 409 while the transaction is not finalized means retry confirmation. Do not pay again while confirmation is pending. GET /v1/invoices/ returns the invoice's paid status.

Payments go directly to PumpView's configured wallet. This is the pumpview-invoice-v1 protocol, not x402. No Coinbase account or facilitator is required. PumpView does not receive the payer's private key. The payer needs native USDC plus SOL for network fees and token account rent when applicable. A finalized payment must match the payer, recipient, mint, amount, memo and invoice payment window. Reconfirming a paid invoice does not grant access twice. One transaction cannot pay two invoices.

WebSocket streaming and recovery

Open the WSS endpoint with the Authorization header, then send a subscription as the first JSON message within 10 seconds:

{"filters": {"mints": [], "wallets": [], "dexes": [], "limit": 500}}

For clients without custom handshake headers, put authorization: "Bearer <API_KEY>" in the first message instead. The response contains type=trades, events, cursor and health. Save the cursor only after processing the associated batch. Reconnect with filters.after set to that cursor. A second connection for the same account receives an error message with status 429 and closes.

Events are retained in a bounded replay journal, not a permanent historical database. An expired cursor returns status 409; start a fresh snapshot and record the gap. The response cursor advances over scanned events even if filters produce an empty page. Check connected, source_connected, last_message_age_seconds, source_dropped_events and replay_gaps in health. Handle reconnection with backoff and avoid logging credentials. Use event_id to deduplicate replays.

MCP configuration

Use a client supporting remote Streamable HTTP and a custom Authorization header:

URL: https://api.pumpview.fun/mcp/
Authorization: Bearer <PUMPVIEW_API_KEY>

Available tools:

The MCP endpoint uses API keys. It does not advertise an OAuth authorization flow. Public initialization or tool discovery alone does not grant paid data access.

Trading API: build, sign locally, submit

Availability: Enabled in gateway configuration; individual routes depend on provider availability.

PumpView reports measured transaction inclusion in the current block in under 100 ms via its landing infrastructure. This is PumpView's own benchmark of inclusion in a block; confirmed/finalized are separate later commitment levels. Results depend on network and route conditions and are not a latency SLA.

Read GET /v1/swaps/config (or MCP get_trading_config) before trading. Authentication uses the same API key. No paid data subscription or data credits are required. An agent can complete steps 1–3 of wallet access above and skip the subscription invoice. Account users must link the signing wallet in the dashboard. Only that account's linked wallet can build swaps.

Supported pairs and costs

REST workflow

  1. Generate a unique request_id for this economic intent (16–80 letters, digits, underscores or hyphens). Save it before requesting a build. Reuse it with identical fields after a build timeout. Changing fields under the same ID returns 409.
  2. POST /v1/swaps/build with Authorization and this example body (10 USDC input, 1% slippage):
{"request_id":"my-swap-20261016-0001","wallet":"YOUR_LINKED_PUBLIC_KEY","input_mint":"USDC","output_mint":"SOL","amount":"10000000","slippage_bps":100,"tip_lamports":2000000,"max_priority_fee_lamports":1000000}

The response includes id, transaction_base64, expires_at, last_valid_block_height, the exact input and estimated/minimum output, fee asset/destination, tips breakdown and network fee estimate. This transaction is unsigned. Review its instructions and costs locally. A build expires for first submission after 60 seconds; the on-chain blockhash can expire earlier.

  1. Sign the exact versioned message locally. Do not rebuild it, change its blockhash, remove fees or send a private key to PumpView. For a Python client with an already authorized local signer (solders Keypair):
import base64
from solders.transaction import VersionedTransaction
unsigned = VersionedTransaction.from_bytes(base64.b64decode(build["transaction_base64"]))
# Inspect unsigned.message against your approved intent and cost limits first.
signed = VersionedTransaction(unsigned.message, [signer])
payload = {"signed_transaction_base64": base64.b64encode(bytes(signed)).decode()}
  1. POST /v1/swaps/{id}/submit with Authorization and payload. PumpView verifies the message and signature, simulates the first submission, persists the signature, then sends through Kolibrio. A response marked submitted is not a confirmation.
  2. Poll GET /v1/swaps/{id} with Authorization. States: built, submitted, confirmed, finalized, failed, expired. The response includes the signature when submitted. The execution receipt is available at confirmed; no wait for finalized is required. Further status polls update finality to finalized. A failed transaction does not execute the swap/platform-fee/tip transfers atomically, but Solana may still charge network fees.

receipt is null until successful transaction metadata is available. RPC metadata may briefly lag confirmed; keep polling the same ID without submitting a second trade. A receipt includes commitment, slot, block_time, actual network_fee_lamports, actual platform_fee.amount in its mint's atomic units, signed wallet_sol_change_lamports, and wallet_token_changes (mint, decimals, signed amount). All amounts are integer strings. Token changes reflect actual wallet balances, including token transfer taxes. The native SOL change includes swap proceeds/spend, tips, network fees, account rent and refunds; it is not the swap output alone. Build-time output estimates remain separate. Receipt commitment records the metadata snapshot, so it can temporarily remain confirmed after status reaches finalized while final metadata catches up. Confirmed is an early report, not final settlement; continue polling if finality is required.

After a timeout or delivery_uncertain, poll the existing swap ID. If the build response was lost, repeat the same build request ID first. Retrying submit is allowed only with the same signed bytes; it can rebroadcast the same signature after a short lease, never a new transaction. Do not automatically issue a new build, change the blockhash or send a second economic trade. An expired unsigned build returns 410. Expiry after submission is based on finalized block height and status lookup; the client should reconcile the existing signature before explicitly authorizing a replacement. Signing a transaction and broadcasting it elsewhere is outside the worker's delivery tracking.

MCP workflow

get_trading_config → build_swap → local wallet review/signature → submit_swap → get_swap_status.

The tools use the same fields, fees, identity and limits as REST. build_swap does not spend funds. submit_swap is annotated as destructive because it broadcasts an authorized signed transaction. An MCP client must not infer permission to spend from tool discovery or a data query.

Account and API-key trading volume

Call GET /v1/swaps/usage with your API key, or MCP get_trading_usage. The account dashboard shows the same statistics. No paid data package is required.

curl https://api.pumpview.fun/v1/swaps/usage \
  -H "Authorization: Bearer $PUMPVIEW_API_KEY"

The response contains totals and by_api_key. Each has swap_count, sol_volume, usdc_volume, estimated_volume_usd and unpriced_swaps. Amounts are decimal strings. available: false means temporarily unavailable, not zero volume.

Only successful swaps executed through PumpView count, from confirmed onward. A buy and a sell count as two swaps. Finalization, repeated polls and submit retries never add duplicate volume. Background reconciliation collects confirmations even when the client stops polling. Attribution stays with the API key that first built the swap; a direct account-session build has api_key_id: null. Revoking a key does not erase its trading history. Builds, failed/expired transactions, data-feed events and swaps broadcast independently outside PumpView are excluded.

USDC is the volume leg when the pair includes USDC; otherwise SOL/WSOL is used. Exact input is counted on a base-asset buy; actual gross base output is counted on a sell. Tips, rent and network fees are not added to volume. USD is an estimate using the base-asset price at build time, not a current-price revaluation. If a price is unavailable, Unlimited can still trade; exact SOL/USDC volume counts and unpriced_swaps identifies the USD subtotal's missing entries. Before volume accounting was enabled, builds without a recorded API-key ID are unattributed and may lack a USD price snapshot.

Event fields and data coverage

Field Meaning
event_id, cursor Stable summary identity and replay position
signature, slot, commitment Transaction signature, slot when available, confirmed commitment
event_kind, instruction_index decoded_swap_summary; instruction_index is currently null
mint, quote_mint, dex, pool Token, wrapped SOL quote mint, decoder DEX name, pool when available
wallet, wallet_role Decoder-reported trader; not a guarantee of transaction fee payer identity
side, token_amount, quote_amount Buy/sell classification, absolute token and SOL quantities
price_sol, price_usd_estimate, amount_usd_estimate Decoder price and estimated USD values
transaction_fee_lamports, protocol_fee_lamports, jito_tip_estimate_lamports Separate fee estimates; transaction fees can repeat across summaries for the same signature
received_at_ms, published_at_ms Server processing timestamps, not guaranteed on-chain execution timestamps
price_filter, amount_precision pumpview_v1; decoder_float

PumpView preserves its existing suspicious-price filter. Coverage is limited to the decoder's supported SOL pairs with existing MEV/router exclusions. A transaction may produce multiple DEX/token summaries, and the feed is not a complete record of every individual Solana swap. Values preserve existing decoder float precision; USD values and Jito tips are estimates. The data feed does not promise archival history, zero loss or a fixed latency SLA. Trading route coverage is separate from data-feed coverage.

Errors