Getting Started

The CloudSEK Integrations API lets your own tools talk to the CloudSEK platform. Pull alerts into a SIEM, sync incidents with your ticketing system, drive SOAR playbooks, and run bulk triage, all over plain HTTPS and JSON.

This page gets you from zero to your first successful API call. Once you're comfortable, the Use Cases section shows how to build complete integrations end to end.

What you can do

Goal	Where to start
Stream alerts into your SIEM	Feed alerts into a SIEM
Detect what changed since your last sync	Changelog lifecycle sync
Keep CloudSEK and your ticketing tool in step	Two-way ticketing sync
Automate acknowledge, assign, and remediate	SOAR playbooks
Update many incidents or events at once	Bulk triage with async jobs
Reconcile state after drift or downtime	Reconciliation with snapshots

Use CloudSEK with MCP

CloudSEK MCP connects Claude, Gemini, Codex, Kiro, and other MCP clients to the same CloudSEK data. Analysts can ask questions in plain English, combine account data with Global Threat Intelligence (GTI), and request incident or event updates from their AI client. The client controls whether tool calls require approval, so check its permission settings before enabling write tools.

Why use MCP

• One investigation across data sources. Review CloudSEK alerts, incidents, events, evidence, audit history, threat actors, CVEs, feeds, and IOCs in one conversation.
• Read and write access. Triage records, add comments, change status or ownership, remediate events, and submit bulk updates. Write tools need a token issued from 30 July 2026 or later; rotate an older one to enable them.
• Traceable changes. Single-record writes return an operation ID. Bulk jobs return a job ID with per-record results.
• Client choice. Use the hosted MCP endpoint from Claude Desktop, Claude Code, Gemini CLI, Codex CLI, Kiro, Cursor, or a custom MCP client.
• No second GTI credential. Hosted deployments include GTI actor, feed, CVE, and IOC tools.

API or MCP?

Use the API for service-to-service integrations, scheduled jobs, and fixed workflows. Use MCP when an analyst needs to investigate data or approve a change through an AI client. Both use CloudSEK integration credentials and can support read and write operations.

MCP use cases

Goal	Start here
Prepare a daily SOC brief with priorities, actors, and CVEs	Morning triage
Review an incident with alerts, audit history, IOCs, and actor context	Incident investigation
Check an IP, domain, URL, or hash against GTI and account data	IOC enrichment
Close an incident and verify the audit entry	Incident closure with audit verification
Review event evidence before remediation	Event evidence review and remediation
Preview and update a group of incidents	Bulk queue cleanup
Reassign open work during analyst offboarding	Analyst offboarding

MCP references

Reference	What it covers
MCP setup	Credentials, Node.js, client selection, security, and connection checks
Available tools	Account data, update tools, write behavior, and GTI tools
Workflows and prompts	Ready-to-use prompts for investigations, reporting, and updates
Frequently asked questions	Alert visibility, write access, approval behavior, and token revocation
Troubleshooting	Client connection, authentication, empty results, write failures, and bulk jobs

Base URL

All requests go to:

https://api.cloudsek.com

Authentication

Every request carries a bearer token in the Authorization header:

Authorization: Bearer <your-access-token>

One token covers everything. Create or rotate it in the CloudSEK platform under Integrations → Alerts API → Create token (or Rotate Token). That is the only place tokens come from.

• Read routes (alerts, changelog, snapshots, job status) work with any Alerts API token.
• Write routes (update incident, post comment, remediate, bulk actions) need a token issued from 30 July 2026 or later. Every Alerts API token created from that date carries write access natively.

Treat the token like a password. If a write route is refused, the token was most likely created before the write release. Rotate it against your existing integration configuration and the replacement will have write access. Nothing else needs to change, and read routes keep working throughout.

Your first request

Fetch the most recent alerts. This works with any integration token:

curl -s "https://api.cloudsek.com/v2/incidents/alerts?limit=10&page=1" \
  -H "Authorization: Bearer $TOKEN"

You get back a paginated envelope:

{
  "data": [ { "...": "alert documents" } ],
  "current_limit": 10,
  "total_count": 1204,
  "current_count": 10,
  "total_page": 121,
  "current_page": 1
}

To page through results, walk current_page up to total_page. Each alert carries an embedded incident_details block whose incident_id (for example XVA-24388918) is the same identifier the write routes accept. You can go straight from reading an alert to writing back to its incident with no extra lookup.

Rate limits

Route type	Budget
Reads (alerts, changelog, snapshots, jobs)	20 requests per minute per token
Single-entity writes	Separate per-token budget
Bulk writes	Separate, lower per-token budget

When you exceed a budget you get 429 with a Retry-After header. Wait that many seconds, then retry the same request. Pace read polling about 3 seconds apart to stay under the limit.

Key concepts

A few ideas show up across every endpoint. Learning them once saves debugging later.

• Incidents vs events. An incident (identified by a Display ID like XVA-1234) groups related events. An event is a single finding, identified by a base64 event_record_identifier.
• Machine values round-trip, display values don't. Anything you read from changelog rows, snapshot rows, or write responses can be passed straight back into filters and writes. The human-readable labels in alert payloads cannot.
• Enum inputs are case-sensitive. Use P1, not p1. Use Open, not open. A wrong-case value returns 400 VALIDATION_ERROR.
• Writes are idempotent. Repeating an identical write returns the prior result instead of creating a duplicate, so retries after a timeout are safe.

The full breakdown lives in the Identifiers and vocabulary cheat sheet.

Response shape

Successful writes return a standard envelope with an operation_id you can use to trace the change:

{
  "success": true,
  "data": { "...": "the updated entity" },
  "operation_id": "019fa850-09bb-7114-9ed4-bb8c88999475",
  "request_id": "req-1785235245499-1c0pms",
  "timestamp": "2026-07-28T10:39:53.051Z"
}

Errors use the same envelope with success: false:

{
  "success": false,
  "error": { "code": "VALIDATION_ERROR", "message": "...", "details": {} },
  "timestamp": "..."
}

See the Error handling and retry playbook for what each code means and how to respond.

Next steps

• Browse the API Reference for every endpoint, its full schema, and an interactive "Try it" panel.
• Pick a Use Case that matches what you're building and follow it end to end.
• Connect an AI assistant to CloudSEK with the MCP Connector.