Three ways to set one up
All three create the same endpoints and rules through the same API, so you can start in one and continue in another: a rule an agent creates shows up in the dashboard, and a rule built in the dashboard can be read and edited over REST.Set up your alert with an agent
Describe the event and destination you want. Use the hosted MCP server to configure the alert and inspect the test delivery, with previews where the event supports them.
Build your alert in the dashboard
Add a destination, choose your rule and inspect the delivery log in one place. Preview frequency for event types that support estimates before saving.
Create alerts from your own code
Register an endpoint and create rules with your API key. Follow the REST setup calls when alerts belong in your application’s own configuration workflow.
Alerts in a chat channel
To get alerts in Slack or Discord without running a receiver, register the channel’s incoming-webhook URL as the endpoint, in the dashboard or with the same create call: a Slack URL startinghttps://hooks.slack.com/services/, or a Discord URL starting https://discord.com/api/webhooks/. The endpoint’s format is detected from the URL as slack or discord, and each alert arrives as a message card instead of the signed JSON that the receiver in the quickstart checks. A test delivery posts a short card saying the channel is connected. Rules, the estimate, the delivery log and the plan allowances work the same way for every endpoint.
How it works
- An endpoint is the URL that receives deliveries. Each one has its own signing secret, shown once when you create it.
- A rule points one endpoint at one event type, optionally narrowed by venue, symbols, watched addresses, conditions and parameters. The API and the dashboard call a rule a subscription: its routes are under
/v1/webhooks/subscriptions, and the dashboard button is New subscription. A rule with no configuration matches every event of its type. - A delivery is one POST to your endpoint. It is retried until your receiver answers with a 2xx or 24 hours pass, and each delivery has an entry in the endpoint’s delivery log.
- Watched addresses are the wallets your
account.*rules report on. The dashboard lists them under Watched wallets.
Plan availability
Webhook delivery starts on the Build plan. The estimate and the dry-run answer on every plan, Free included, for the event types each one supports; Estimate and dry-run lists them. A wallet event type also needs a watched address to preview, and Free cannot hold one. Endpoints, rules, watched addresses and deliveries a day grow with each plan, and deliveries do not use API credits; Limits and plans has the numbers.Go further
Choose the signal worth acting on
Find a market, watched-wallet, archive, export or billing event, then check its venues, scope and current availability.
Make each alert relevant to you
Narrow the event to the venue, symbols or registered addresses you care about, and use its declared conditions and parameters.
Check the noise before saving a rule
For supported event types, compare recent frequency and available matching-event previews so you can choose a threshold deliberately.
Follow activity from the wallets you choose
Register watched addresses before creating account rules, then narrow each rule to the wallets and activity you want to hear about.
Build a receiver you can trust
Verify signed JSON deliveries against the raw body, read the event envelope and record work before acknowledging it.
Keep alerts useful when delivery fails
Inspect the delivery log, distinguish disabled endpoints from paused rules, and follow the recovery path that fits the failure.
Choose delivery capacity for your workflow
Delivery starts on Build. Compare endpoint, rule, watched-address and daily-delivery allowances, plus the previews available on Free.