API Reference

How Does the Cyproli API Support Security Operations?

The Cyproli API turns research and monitoring into executable workflows. Instead of keeping threat intelligence and operational controls in separate tools, teams can pull active threat signals, trigger incident-response playbooks, and route alerts into the systems they already use — Slack, PagerDuty, Telegram, or internal automation. The API is designed for Web3 security teams that need deterministic, machine-readable state rather than a dashboard they have to watch.

Every endpoint returns structured data that can be consumed by automation: environment-scoped detections, policy lane states, and incident lifecycle records. This lets a treasury, a bridge operator, or a multisig coordinator bake security checks directly into their execution flow instead of relying on manual review. Authentication uses scoped API keys per environment, so read-only monitoring lanes can be separated from lanes that can trigger responses.

Which Endpoints Should Teams Start With?

What Are the Authentication and Rate-Limit Expectations?

Each API key is bound to an environment and a permission scope. Read-only keys can pull telemetry; write keys are required for endpoints that trigger playbooks or change routing. This separation is what lets teams grant broad visibility to auditors without granting them execution authority.

Rate limits are documented per endpoint and designed for steady operational polling rather than bulk backfills. Teams that need high-frequency telemetry should use the streaming or snapshot endpoints rather than hammering the incident API. Errors return structured codes so automation can branch on the outcome instead of parsing prose.

How Do Teams Integrate the API Into Their Approval and Monitoring Flow?

The most effective integrations embed API checks into the transaction pipeline rather than treating the API as a separate monitoring screen. For example, a treasury can query /v1/threats/active for a specific route or signer before signing a high-value transfer, and pause if the response includes a relevant active threat. A bridge operator can trigger /v1/incidents/trigger from a relayer that detects a verification anomaly, ensuring the incident sequence starts the moment a signal appears instead of after a human notices a dashboard.

This pattern keeps the API at the decision point: policy lane state, environment scope, and incident lifecycle data are pulled into the exact workflow that needs them. The result is that security controls stop being a review step and become part of the execution path itself, which is where they actually change outcomes.

What Does a Typical Response Look Like?

{ "threats": [ { "id": "thr_8f3a", "asset": "bridge-route:eth-usdc", "severity": "high", "lane": "validation", "summary": "Verifier set change detected on active route", "firstSeen": "2026-08-14T08:05:00Z" } ], "nextCursor": "thr_8f3b" }

Responses follow a consistent shape: a top-level entity array, stable identifiers, severity and lane fields for routing, and a cursor for pagination. Severity and lane fields are the keys to automation — they let teams route by policy without parsing free text. Every entity includes an immutable id so downstream systems can deduplicate events reliably even when a webhook delivery repeats.

How Should Teams Handle Errors and Retries?

The API uses standard HTTP status codes with structured error bodies. A 401 means the key is invalid or lacks the required scope; a 429 means the rate limit was reached and the response includes a retry-after value; a 4xx with a validation detail means the request body failed a check. Automation should treat these three classes differently rather than retrying them identically.

Webhook consumers should acknowledge deliveries with a 2xx and expect at-least-once delivery semantics, so they must deduplicate on the entity id. The combination of structured errors and stable ids is what makes the API safe to wire into unattended security automation, where a misbehaving integration could otherwise multiply an alert or drop a critical trigger. Teams should also document which endpoints are safe to poll at high frequency and which are event-driven, so their automation matches the API's designed usage rather than fighting it.

How Should Teams Start a New Integration?

Begin with read-only endpoints and a small scope: pull active threats for one asset class, wire them into an alert channel, and confirm the routing behaves as expected. Once the read path is stable, add write actions such as incident triggering with a key scoped to that environment only. This staged rollout mirrors the discipline documented across the research layer and keeps a new integration from becoming a second source of incident risk while it is still being learned.

How Do API Workflows Connect to the Broader Cyproli Research Corpus?

The API operationalizes the patterns documented across the research layer. Teams evaluating a new bridge route can start with the research hub to understand route risk scoring and isolation architecture, then use the API to monitor those same routes and escalate on drift. A multisig team that needs signer OpSec and beneficiary verification can wire the API into the final signer review lane described in the final review checklist. The reference and the research layer are two ends of the same workflow: the pages explain the control, the API makes it executable, and the combination gives a team both the policy and the plumbing to enforce it in production.