> For the complete documentation index, see [llms.txt](https://docs.raybot.app/start/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.raybot.app/start/dev/webhooks-api/example-payloads.md).

# Example Payloads

Real webhook payloads (sanitized) for the most common event types, so you can build and test your receiver against actual payload shapes.

Each page below shows a real payload for a live on-chain transaction, exactly as RayBot's delivery pipeline builds it. Wallet addresses and transaction hashes have been replaced with obvious placeholders; token mints, pools, and program IDs are real, so you can look them up.

Every delivery arrives as an HTTPS POST with the headers described in [Webhooks API → Delivery Payload](/start/dev/webhooks-api.md#delivery-payload). The `X-RayBot-Event` header matches the body's `event_type`.

### Event types

The main `event_type` values you can expect:

| `event_type`                         | When it fires                                                     |
| ------------------------------------ | ----------------------------------------------------------------- |
| `buy` / `sell`                       | A followed wallet trades a token against SOL, ETH or a stablecoin |
| `swap`                               | Token-to-token swap                                               |
| `transfer_in` / `transfer_out`       | Native or token transfer to / from a followed wallet              |
| `token_mint`                         | A followed wallet creates a token                                 |
| `add_liquidity` / `remove_liquidity` | Liquidity deposited into / withdrawn from a pool                  |
| `other`                              | Anything without its own type, e.g. fee claims                    |

Signals (`multi_buy`, `accumulation`) and the rarer types are covered in the [Webhooks](/start/dev/webhooks.md#payload-reference) payload reference.

### Solana

| Example                                                                             | `event_type`    | What happens                                        |
| ----------------------------------------------------------------------------------- | --------------- | --------------------------------------------------- |
| [SOL Transfer](/start/dev/webhooks-api/example-payloads/solana-sol-transfer.md)     | `transfer_in`   | SOL sent to a followed wallet                       |
| [Token Transfer](/start/dev/webhooks-api/example-payloads/solana-token-transfer.md) | `transfer_in`   | SPL token (USDT) sent to a followed wallet          |
| [Buy](/start/dev/webhooks-api/example-payloads/solana-buy.md)                       | `buy`           | First buy of a token on pump.fun, opens a position  |
| [Sell](/start/dev/webhooks-api/example-payloads/solana-sell.md)                     | `sell`          | Full position sold on pump.fun, with realized PnL   |
| [Add Liquidity](/start/dev/webhooks-api/example-payloads/solana-add-liquidity.md)   | `add_liquidity` | Two-sided deposit into a Meteora DLMM pool          |
| [Fee Claim](/start/dev/webhooks-api/example-payloads/solana-fee-claim.md)           | `other`         | pump.fun creator fees paid out to a followed wallet |

### EVM

| Example                                                                            | `event_type`   | What happens                              |
| ---------------------------------------------------------------------------------- | -------------- | ----------------------------------------- |
| [Native Transfer](/start/dev/webhooks-api/example-payloads/evm-native-transfer.md) | `transfer_in`  | ETH sent to a followed wallet on Base     |
| [Token Transfer](/start/dev/webhooks-api/example-payloads/evm-token-transfer.md)   | `transfer_out` | ERC-20 (USDC) sent from a followed wallet |
| [Buy](/start/dev/webhooks-api/example-payloads/evm-buy.md)                         | `buy`          | ETH swapped for a token on Base           |
| [Sell](/start/dev/webhooks-api/example-payloads/evm-sell.md)                       | `sell`         | Token sold for WETH, closing the position |

### Common structure

All payloads share the same top-level shape:

* `id` — the transaction signature (Solana) or transaction hash (EVM).
* `event_type` — one of the [event types](#event-types) above.
* `chain` / `source` — network and the program or platform that produced the event.
* `failed` — `true` if the transaction failed on-chain.
* `fee_payer` — who paid for the transaction.
* `followed_wallets` — which of your tracked addresses triggered this delivery, with the `wallet_name` you assigned. Solana wallets also carry `funded_at` and `sol_balance`.
* `token_changes` — balance deltas per tracked address: `direction` (`in`/`out`), `mint`, raw and decimal `amount`, and USD pricing.
* `tokens` — metadata for every mint referenced in `token_changes` (symbol, decimals, price, supply, socials).
* `position` — present on `buy`/`sell` events only: running position stats for the wallet and token (cost basis, invested total, realized/unrealized PnL), denominated in the chain's native currency.
* `fees` — priority fee and tips paid.
* `event` — the raw parsed event; its shape varies by chain and event type (EVM events include the low-level `transfers` breakdown). Some deliveries, such as a plain creator fee claim, have no `event` at all.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.raybot.app/start/dev/webhooks-api/example-payloads.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.