Platform API
Every platform capability, available over HTTP
The ManySignal API covers the full platform: ingest events, query findings, manage cases, deploy detection rules, trigger workflows, and query the entity graph. Every action available in the UI is available in the API. There are no UI-only capabilities.
REST API — curl + response
Consistent, versioned, and completely documented
The API is versioned at the URL path. Breaking changes increment the major version. Non-breaking additions (new fields, new endpoints) are added within the current version. The v1 API will not break without a deprecation period of at least 12 months.
Request
curl -X GET \
"https://api.manysignal.io/v1/findings?severity=high&status=open&limit=5" \
-H "Authorization: Bearer $MS_API_TOKEN" \
-H "X-Tenant-ID: $MS_TENANT_ID"Response
{
"data": [
{
"id": "fnd_01HXYZ1234ABCDEF",
"rule_id": "aws-iam-console-login-no-mfa",
"severity": "high",
"status": "open",
"created_at": "2026-08-09T14:32:01Z",
"entity": {
"id": "ent_user_alice",
"display_name": "[email protected]",
"type": "human_account",
"blast_radius": 72,
"is_privileged": true
},
"triage": {
"verdict": "true_positive",
"confidence": 0.91,
"completed_at": "2026-08-09T14:32:04Z"
},
"mitre": ["T1078.004"],
"case_id": "cas_00142"
}
],
"meta": {
"total": 23,
"page": 1,
"limit": 5
}
}What the API covers
Events
POST /events (ingest), GET /events (query), GET /events/:id
Findings
GET /findings, GET /findings/:id, PATCH /findings/:id/status
Cases
GET /cases, POST /cases, GET /cases/:id, POST /cases/:id/timeline
Detection rules
GET /rules, POST /rules, PUT /rules/:id, DELETE /rules/:id, POST /rules/:id/promote
Entity graph
GET /entities/:id, GET /entities/:id/neighbors, GET /entities/:id/blast-radius
Workflows
GET /workflows, POST /workflows, POST /workflows/:id/trigger
Audit trail
GET /audit-events (filter by actor, type, time range)
API design decisions
Resource IDs are stable
All resource IDs use a typed prefix (fnd_, cas_, ent_, rul_) and a ULID suffix. IDs are sortable by creation time and safe to store in external systems.
Pagination is cursor-based
All list endpoints use cursor-based pagination. Offset-based pagination is not available, as it produces inconsistent results on frequently-updated collections like the finding list.
Webhooks for real-time events
Subscribe to webhook topics (finding.created, case.escalated, workflow.completed) with HMAC-SHA256 request signing. Webhook deliveries are retried for 24 hours with exponential backoff.
Rate limits are tenant-wide
Rate limits apply per tenant, not per API key. Burst and sustained limits are published in the API docs. The Retry-After header is always present on 429 responses.
GraphQL for entity graph queries
Complex entity graph queries — multi-hop traversals, aggregations, time-range filters — are available via a GraphQL endpoint. The REST API is recommended for standard CRUD operations; GraphQL for graph queries.
OpenAPI 3.1 specification
A machine-readable OpenAPI spec is available at /v1/openapi.json. Client libraries are generated from the spec for Go, Python, TypeScript, and Java.
Platform API — FAQ
How do I authenticate to the API?
API keys are issued per team member or per service account from the Settings > API Keys page. Keys are scoped to a permission set: read-only, read-write, or admin. Keys are 256-bit random tokens prefixed with ms_ and stored only as a hash after initial display.
Is there an API sandbox environment?
Yes. A sandbox tenant is available for development and testing. Sandbox events do not count against production quotas, and sandbox findings do not trigger response actions. The sandbox is reset weekly.
What is the maximum event batch size for ingestion?
The POST /events endpoint accepts batches of up to 1,000 events per request. For higher-throughput ingestion, the Kafka-compatible consumer endpoint is recommended — it supports streaming ingestion without request-size limits.
Can I use the API to deploy detection rules from CI?
Yes. The CLI wraps the API for detection-as-code workflows. Direct API usage is also supported: POST /rules to create, PUT /rules/:id to update, POST /rules/:id/promote to move from alert-only to active.
What rate limits apply to the API?
Default rate limits are 1,000 requests per minute per API key for read endpoints and 200 per minute for write endpoints. The event ingestion endpoint is not rate-limited by default — it is metered against your ingestion quota. Enterprise customers can request elevated limits for specific endpoints.
Is the API versioned and backward compatible?
Yes. The API is versioned under /v1/. Breaking changes are introduced only in new major versions with a 12-month deprecation window for the previous version. Non-breaking additions (new response fields, new endpoints) do not require a version bump.
Can I receive real-time alerts via the API rather than polling?
Yes. Webhook subscriptions deliver findings, verdict updates, and case state changes to your endpoint in near-real-time. Webhooks are signed with an HMAC-SHA256 signature using your webhook secret. A retry policy with exponential backoff handles temporary endpoint failures.
Is an official client SDK available?
Yes. Official client libraries are available for Python, Go, and TypeScript. They wrap the REST API, handle authentication, and provide typed models for all request and response objects. Community-maintained libraries exist for Ruby, Java, and Rust.
How does the API integrate with our existing SOAR or security tooling?
ManySignal's API can serve as a data source for or receive actions from external SOAR platforms. Common integration patterns include: forwarding verdicts to Splunk SOAR or Palo Alto XSOAR via webhook, triggering ManySignal response actions from an external approval workflow, and pulling case data into a BI or compliance reporting tool.
Build on the same API the UI uses
The OpenAPI spec, a sandbox environment, and generated client libraries are available to all customers.