Alerts
Receive, triage and route the events Seqlense raises about your identities and wallets.
An alert is something Seqlense wants you to look at. It carries a severity, the entity it concerns, and a status you move as you work through it.
Alerts come from two places: Seqlense raises them itself, for instance when a market abuse scan flags a wallet, and you can raise your own through the API. Both kinds behave identically once created.
Alerts are scoped to your organization, resolved from the API key on the request, exactly like identities and wallets.
The shape of an alert
| Field | Meaning |
|---|---|
severity | INFO, MEDIUM, HIGH or CRITICAL |
source | who raised it: market_abuse for scan findings, or your own string |
title / message | the short line, and the detail |
entity_type / entity_id | what it is about, typically WALLET or IDENTITY |
metadata | free-form JSON, kept verbatim |
status | OPEN, ACKNOWLEDGED, RESOLVED or MUTED |
source matters more than it looks: it is what notification channels filter
on, so pick a stable value per producer rather than a per-event one.
Raising one
POST /v1/alerts/ with at least a severity, a title and a message:
{
"severity": "HIGH",
"source": "my-risk-engine",
"title": "Unusual counterparty",
"message": "Wallet 0xabc… received funds from a newly created address.",
"entity_type": "WALLET",
"entity_id": "…"
}Linking an alert to an entity is worth the effort: it is what lets the alert page take a reader through to the wallet or identity concerned.
Working through them
GET /v1/alerts/ lists them, filtered by status, severity, source or entity.
GET /v1/alerts/count returns the counts you would put on a dashboard without
pulling the alerts themselves.
An alert then moves through its life:
POST /v1/alerts/acknowledge: someone has taken itPOST /v1/alerts/resolve: it is dealt withPOST /v1/alerts/bulk-action: the same, over many at once
Where alerts go
A notification channel decides where an alert is delivered: a webhook, a
Discord or Slack hook, or the in-app inbox. GET /v1/alerts/channels lists
them, POST creates one, and POST /v1/alerts/channels/test sends a harmless
test event through it so you can confirm the plumbing before relying on it.
Each channel carries three optional filters:
| Filter | Effect |
|---|---|
filter_severity | only these severities |
filter_sources | only these sources |
filter_entity_types | only these entity types |
Filters are opt-in: an empty filter matches everything. A channel that lists specific sources will therefore stop receiving anything from a new producer until that source is added to it. This is the usual reason a new alert type appears in the app but never reaches Slack.
What was actually sent
GET /v1/alerts/history is the delivery log: every attempt, its channel, and
whether it succeeded. It answers "was this alert really sent, and where" without
guessing from the channel configuration.