Overview

The Blockworks Monitoring API replaces keyword alerts and manual checks with agents that continuously read, evaluate, and escalate the events that matter. Every event is reviewed by an intel analyst before it reaches your pipeline, so you get speed and accuracy rather than a firehose.

​

What you get

• Agentic coverage, not keyword rules. Agents understand context, severity, and relevance. They distinguish a $50M unlock from a blog post that mentions one.
• 1,000+ assets, including long-tail. Bitcoin through small-cap DeFi. Standardized coverage so you catch sector spillovers, not just the majors.
• 700+ sources ingested continuously. Onchain data, governance, filings, news, and social, all monitored in real time.
• Analyst-verified. Agents flag developing signals instantly; analysts verify before anything is marked verified: true.
• Structured output. Events, developments, a categorized taxonomy, and resolved assets, ready to feed dashboards, risk systems, on-call rotations, or custom workflows.

​

Base URL and authentication

All Monitoring endpoints live under /monitoring/v2 on the shared Blockworks API host, https://api.blockworks.com, and every request requires an API key in the X-Blockworks-API-Key header. The Quickstart walks through getting a key and making a first request; Authentication covers access tiers and key handling.

​

Core concepts

Development. The atomic unit of coverage: a single dated, verified occurrence (for example, “Binance.US lists TRX”). Tagged with category, subcategory, importance, resolved assets (each marked primary or secondary), and a nested event reference pointing at the parent event. Every endpoint that returns developments uses the same shape. Event. A logical grouping of related developments over time, such as a multi-stage hack together with its subsequent disclosures, responses, and post-mortems. Carries its own slug, createdAt / updatedAt, and aggregate developmentCount / documentCount. Monitoring View. A saved filter over the stream. simple views are deterministic predicates (assets, categories, importance). agentic views are prompt-based; the prompt is stored on the view itself and matched items come back in the canonical Development shape.

​

Summaries

Developments and events both expose a summary field, but they behave differently:

• Development summaries. For verified developments (verified: true), the summary is human-curated by the intel analyst team and reflects the most up-to-date information at the time of verification. Treat it as authoritative.
• Event summaries. Rolled up across the event’s child developments, so they update as new developments land. Expect some latency between a fresh development being added and the event-level summary catching up. If you need the latest narrative, read the most recent development under the event rather than the event summary.

​

Filter semantics

Most list endpoints share a filtering surface, and the failure modes are worth knowing before you build against them:

• assetIds accepts UUIDs or slugs. Unresolved tokens are silently dropped; if none of the supplied tokens resolve, you get an empty page rather than an error.
• intelCategories, intelSubcategories, assetSectors, assetSubsectors, and assetEcosystemNetworkIds are comma-separated and follow the same silent-drop rule.
• eventIds is the exception: unresolvable tokens return 400.
• Results are ordered most-recent-first and paginated.

​

Use cases

• Risk and response. Feed verified security_and_hacks developments for your portfolio assets straight into your on-call rotation.
• Portfolio intelligence. Save a monitoring view scoped to the assets you hold, including long-tail, and pull minimumImportance=medium developments on a cron.
• Research automation. Pull agentic views that surface developments matching a natural-language thesis, such as “stablecoin peg stress” or “L2 sequencer outages”.
• Client-facing alerting. Power customer-facing event timelines and notifications in your own product without running your own monitoring stack.
• Governance and ops dashboards. Filter for governance=true developments across the assets your DAO or treasury cares about.

​

Push delivery

Monitoring views can push matched developments to an endpoint you control instead of, or in addition to, polling. See Webhooks for the payload format, HMAC signature verification, and retry behavior.