Skip to main content
Every event SURCHI delivers to your webhook endpoint has a type field that identifies exactly what happened on-chain. This page documents all available event types, their payload schemas, and how to subscribe to them. Use this reference alongside the Webhooks Overview to build a robust, event-driven integration.

All Event Types

Event Payload Examples

Each accordion below shows the complete JSON body delivered to your endpoint for that event type.
Fired when a token’s price crosses a threshold you configured. The alert_type field is either price_above or price_below.
Fired when SURCHI detects a new liquidity pool for a previously unseen token on a supported DEX. This event fires within seconds of pool creation.
Fired when the SURCHI AI audit engine re-evaluates a token contract and its risk score moves by more than the configured sensitivity threshold.
Fired when a wallet you are tracking executes a trade above the dollar threshold you configured during webhook setup.
Fired when a tracked wallet buys a token it has not held before, indicating a new position has been opened.
Fired when a tracked wallet’s cumulative realized PnL crosses a positive or negative milestone you defined.
Fired when the SURCHI AI audit engine identifies a contract as a honeypot — meaning buyers cannot sell their tokens.
Fired when a significant percentage of liquidity is removed from a token’s pool, which may indicate a rug pull.
Fired when a contract’s owner or admin authority is transferred to a new address.
Fired when a Pump.fun token completes its bonding curve and migrates to a Raydium liquidity pool. This event signals that the token has reached the graduation threshold of approximately 85 SOL raised.

Subscribing to Events

Pass an array of event type strings when creating or updating a webhook. To subscribe to all current and future event types, use the * wildcard.
Using the * wildcard means your endpoint will automatically receive any new event types SURCHI introduces in the future. If you prefer explicit control over which events your endpoint receives, list them individually.

Event Deduplication

Under certain conditions — network timeouts, retries, or infrastructure failover — SURCHI may deliver the same event to your endpoint more than once. To handle this safely, treat every event as potentially duplicated and use the top-level id field as an idempotency key. Before processing an event, check whether you have already stored or acted on that id. If it already exists in your records, acknowledge the webhook with a 200 response and skip processing. A simple implementation uses a database unique constraint or a Redis SET NX operation on the event id.