Webhooks deliver real-time updates from the Codex API directly to an HTTP endpoint you control. Unlike subscriptions, which require a persistent connection, webhooks fit naturally into event-driven architectures, alerting systems, and background services.Documentation Index
Fetch the complete documentation index at: https://docs.codex.io/llms.txt
Use this file to discover all available pages before exploring further.
Delivery and retries
Codex sends webhook messages via HTTP POST and expects a 2xx response within 3 seconds. If your endpoint responds slowly or fails, the message will be retried up to two additional times with gradually increasing delays. If your service is down for long enough, some messages will be lost.Webhook usage breakdown:
- Processed means an event matched at a basic level (for example, maker, pair, or token address)
- Triggered means all conditions passed and Codex will try to publish
- Success means publishing was attempted and succeeded
- Failed means publishing was attempted and failed (usually a bad URL)
Creating a webhook
The fastest way to create and test a webhook is through the Codex Explorer, which provides a visual builder for every supported event type. To create one programmatically, use thecreateWebhooks mutation. Each event type has its own input field on the mutation (for example, tokenPairEventWebhooksInput or predictionTradeWebhooksInput). See the event type sections below for a ready-to-use creation example for each.
Organizing webhooks with bucketKey
You can optionally group and query your webhooks using a bucketKey. This is useful when you are managing many webhooks per user or per token, such as a price alert system.
bucketId and bucketSortKey must be provided together. If you don’t need to query webhooks by bucket, you can omit bucketKey entirely. Using both fields lets you independently query all alerts for a specific user and all alerts for a specific token.
The individual
bucketId and bucketSortKey fields on createWebhook are deprecated. Use the bucketKey object instead.Message structure
Every webhook message shares a common envelope. Thetype field tells you which event fired, and the data field contains the event-specific payload described in the event type sections.
The event type. One of
TOKEN_PAIR_EVENT, TOKEN_PAIR_EVENT_BATCH, TOKEN_PRICE_EVENT, TOKEN_PRICE_EVENT_BATCH, TOKEN_TRANSFER_EVENT, TOKEN_TRANSFER_EVENT_BATCH, MARKET_CAP_EVENT, MARKET_CAP_EVENT_BATCH, PREDICTION_TRADE_EVENT, or PREDICTION_TRADE_EVENT_BATCH.A unique identifier for this message. Use it to deduplicate retries on your side.
The ID of the webhook that triggered this message.
The ID used to group related messages for ordered delivery.
SHA256 hash of the
securityToken and deduplicationId. See Hash verification for how to validate it.The event-specific payload. The shape depends on
type. See the event type sections for each payload structure.Hash verification
Each webhook message includes ahash field you can use to verify the message came from Codex and hasn’t been tampered with. This protects your endpoint from spoofed or replayed requests.
The hash is a SHA256 digest of your webhook’s securityToken concatenated with the message’s deduplicationId. To verify, compute the same hash on your server and compare it to the value in the payload. If they match, the message is authentic.
Event types
TOKEN_PAIR_EVENT
The TOKEN_PAIR_EVENT webhook fires when a swap, mint, burn, or other liquidity event occurs on a trading pair. It delivers the full Pair and Event objects so you can reconstruct exactly what happened on-chain. This is the most commonly used webhook.
When to use it
- Tracking every trade made by a specific wallet
- Monitoring high-value swaps on a single token or pair
- Feeding a live trade tape for a specific pool
- Alerting on liquidity events (mints, burns) for a pair
tokenAddress: fire for events involving this tokennetworkId: one or more network IDs to listen onswapValue: filter by USD value of the swapmaker: fire for events made by a specific walletpairAddress: fire for events on a specific pairexchangeAddress: fire for events on a specific exchangeeventType: filter to specific event types (SWAP,MINT,BURN,SYNC,BUY,SELL,COLLECT,COLLECT_PROTOCOL)
tokenPairEventWebhookConditionInput.
Creation example
TOKEN_PRICE_EVENT
The TOKEN_PRICE_EVENT webhook fires when the price of a specific token crosses a threshold you define. Use it for price alerts on tokens you care about.
When to use it
- Price alerts for a single token (for example, “WETH above $4000”)
- Watchlist-style notifications for a small set of tokens
- Dashboard price tickers where polling is not acceptable
address: the token contract address (required)networkId: the network ID (required)priceUsd: price condition that must be met (required). Supportsgt,gte,lt,lte,eq
tokenPriceEventWebhookConditionInput.
Creation example
TOKEN_TRANSFER_EVENT
The TOKEN_TRANSFER_EVENT webhook fires when a token is transferred to or from a wallet you are monitoring. Use it to track wallet inflows and outflows in real time.
When to use it
- Monitoring whale wallet movements
- Triggering on-chain alerts for your own wallets
- Watching known exchange hot wallets or bridge addresses
tokenAddress: the token contract to tracknetworkId: one or more network IDsaddress: the wallet address to monitordirection:TO(receiving),FROM(sending), or both
tokenTransferEventWebhookConditionInput.
Creation example
MARKET_CAP_EVENT
The MARKET_CAP_EVENT webhook fires when a token’s market cap crosses a threshold you specify. Unlike token price webhooks, it factors in supply (both fully diluted and circulating).
When to use it
- Market cap milestone alerts (for example, “VIRTUAL crosses $1B FDV”)
- Large-cap filtering logic for automated tools
- Portfolio-level risk dashboards
tokenAddress: the token contract (required)networkId: the network ID (required)fdvMarketCapUsd: fully diluted market cap thresholdcirculatingMarketCapUsd: circulating market cap thresholdpairAddress: optional source pair constraintliquidityUsd,volumeUsd: optional pair-level liquidity and volume constraints
marketCapEventWebhookConditionInput.
Creation example
PREDICTION_TRADE_EVENT
The PREDICTION_TRADE_EVENT webhook fires when a prediction market trade occurs. Use it to track trades by a specific trader, on a specific market or event, or matching conditions like trade value or volume.
When to use it
- Tracking copy-traded wallets on Polymarket or Kalshi
- Notifying on large trades in a specific market or event
- Feeding a live trade tape for a prediction market dashboard
traderId: fire for a specific tradermarketId: fire for a specific marketeventId: fire for a specific eventeventType: filter by trade event type (TRADE,BUY,SELL,BUY_COUNTERPARTY,SELL_COUNTERPARTY,PAYOUT_REDEMPTION)tradeValueUsd: filter by trade value in USDamountToken: filter by number of tokens or shares traded
predictionTradeWebhookConditionInput.
Creation example
FAQ
How many tokens can I add to a single webhook?
How many tokens can I add to a single webhook?
Webhooks monitor one token at a time, but there is no limit on how many webhooks you can create. To watch many tokens, create one webhook per token (the
bucketKey field makes managing large sets straightforward).How do I push real-time buys via webhooks?
How do I push real-time buys via webhooks?
Create a
TOKEN_PAIR_EVENT webhook for the token and filter eventType to BUY. The webhook payload includes the full event object, so you don’t need a follow-up call to enrich the data. See the TOKEN_PAIR_EVENT section above for the full creation example.What is the `securityToken` field for, and how do I verify it?
What is the `securityToken` field for, and how do I verify it?
securityToken is your secret. Codex uses it to compute the hash field on every webhook message — a SHA256 digest of securityToken concatenated with the message’s deduplicationId. Compute the same hash on your endpoint and compare it to the hash value to verify the message came from Codex and hasn’t been tampered with. See Hash verification for the full snippet.How is webhook usage measured against my plan's monthly request limit?
How is webhook usage measured against my plan's monthly request limit?
Each webhook delivery counts as 1 request. If you also fire a follow-up API call to enrich the event (e.g. fetching token metadata), that’s a second request. So if you’re processing 10k buys per day with one enrichment call each, that’s 20k requests/day or roughly 600k/month.