> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Programmatic access to AI-surfaced, analyst-verified events across 1,000+ assets and 700+ sources.

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](/api-reference/monitoring/quickstart) walks
through getting a key and making a first request; [Authentication](/getting-started/authentication)
covers access tiers and key handling.

## Core concepts

<CardGroup cols={3}>
  <Card title="Development" icon="circle-dot">
    The atomic unit of coverage: a single dated, verified occurrence.
  </Card>

  <Card title="Event" icon="stack-2">
    A logical grouping of related developments over time.
  </Card>

  <Card title="Monitoring View" icon="filter">
    A saved filter over the stream, either deterministic or prompt-based.
  </Card>
</CardGroup>

**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.

<Note>
  Because unresolved filter tokens are dropped silently, an empty result set can mean either
  "nothing matched" or "your filter tokens were invalid". Validate asset and taxonomy tokens
  against [List Categories](/api-reference/monitoring/get-v2-categories) and the asset
  endpoints when a query unexpectedly returns nothing.
</Note>

## 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](/api-reference/monitoring/webhooks) for the payload
format, HMAC signature verification, and retry behavior.