Use Cases
These guides show how to build real integrations on the CloudSEK Integrations API. Each one maps a common goal to the endpoints that get you there, with working requests and the practical notes that save you a debugging session.
Every request and response shape here was verified against the live production API. The API Reference carries the full schemas, parameter lists, and error catalogue. When the two disagree, the reference wins.
Pick your integration
| Use case | What it does | Main endpoints |
|---|---|---|
| Feed alerts into a SIEM | Poll new alerts and load them into your SIEM | GET /v2/incidents/alerts |
| Changelog lifecycle sync | Track every status, priority, and assignment change | GET /v2/changelog |
| Two-way ticketing sync | Keep CloudSEK and your ITSM tool in the same state | PATCH /v2/incidents/{id} |
| SOAR playbooks | Acknowledge, assign, and remediate automatically | PATCH /v2/incidents/{id}, POST /v2/events/{id}/remediate |
| Bulk triage | Update many incidents or events in one async job | POST /v2/incidents/bulk, GET /v2/jobs/{jobId} |
| Reconciliation | Resync current state after drift or downtime | GET /v2/snapshot/incident |
Before you start
- Read the Getting Started page for the base URL, authentication, and rate limits.
- Keep the Identifiers cheat sheet handy. Most integration bugs come from mixing up identifier types or enum casing.
- Bookmark the Error handling playbook so your integration reacts correctly to each status code.
How the pieces fit together
A typical two-way integration chains several of these use cases:
- Ingest. Poll the alerts feed and open a ticket for each new alert.
- Sync outward. When a ticket changes, write the state back to CloudSEK.
- Sync inward. Poll the changelog to catch changes analysts make in CloudSEK, and update your tickets.
- Verify. Confirm your writes landed with snapshots.
The changelog and snapshot patterns are what keep both systems honest, so start with ingest, then layer sync and verification on top.