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.
Deprecated. SHA256 hash of the
securityToken and deduplicationId. Prefer the X-Webhook-Timestamp and X-Webhook-Signature headers described in Verifying webhooks. The legacy hash does not cover the request body and is still emitted only for backwards compatibility.The event-specific payload. The shape depends on
type. See the event type sections for each payload structure.Verifying webhooks
Every webhook delivery includes two signature headers that authenticate the exact request body bytes and provide a freshness signal for replay protection:X-Webhook-Timestamp: Unix timestamp in seconds.X-Webhook-Signature: lowercase hex HMAC-SHA256 over{timestamp}.{rawBody}, using your webhook’ssecurityTokenas the key.
- Read the raw request body bytes as received, before any JSON parsing.
- Build the signed payload string
{timestamp}.{rawBody}. - Compute
hex(hmac_sha256(securityToken, signedPayload))and compare it toX-Webhook-Signatureusing a constant-time comparison. - Reject the request if
abs(now - X-Webhook-Timestamp) > 300seconds, or if either header is missing or malformed.
Verify the original raw request body bytes, then parse JSON only after the signature check passes. Re-serializing the parsed body will change whitespace and key order and produce a different signature.
- Next.js App Router: call
await request.text()once and use that exact string. - Next.js API routes: set
export const config = { api: { bodyParser: false } }, then read the request stream into a buffer. - Express: mount
express.raw({ type: "application/json" })on the webhook route, or capture the buffer inexpress.json({ verify }). - AWS Lambda + API Gateway: use
event.bodydirectly, base64-decoding whenevent.isBase64Encodedis true. - Rails/Rack: use
request.raw_post. Flask/Django:request.get_data()/request.body.
- Parsing and re-serializing JSON before verification.
- Verifying only
dataor the legacyhashfield instead of{timestamp}.{rawBody}. - Comparing signatures with
==instead of a constant-time helper. - Treating the timestamp as milliseconds.
X-Webhook-Timestampis Unix seconds. - Skipping the freshness check, which removes replay protection.
Hash verification (deprecated)
The legacyhash is a SHA256 digest of your webhook’s securityToken concatenated with the message’s deduplicationId:
Source IP addresses
Codex sends webhook deliveries from a fixed set of IP addresses. If you want to gate inbound webhook traffic at the network layer in addition to verifying the signature on each payload, allowlist these IPs at your firewall or load balancer:Network-level allowlisting complements signature verification, it doesn’t replace it. Always verify the signature on incoming payloads to confirm authenticity.
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 as the HMAC key for the X-Webhook-Signature header on every delivery, which authenticates the exact raw request body. See Verifying webhooks for the full verification flow. The legacy body hash field is also derived from securityToken but is deprecated because it doesn’t cover the body.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.