Signal Cloud Overview
Signal Cloud's checked-in OpenAPI document describes an authenticated, Console-facing API for event exploration, analytics, detection, notifications, maintenance, and server status.
The published contract is intentionally scoped. It excludes event ingestion, adapter recovery, health, identity, administration, and operator-operation endpoints. This documentation describes only the contract represented by the Signal Cloud API reference, not the full product or deployment-specific workflows.
Documentation paths
- Getting started explains how to navigate the published contract.
- Authentication and permissions summarizes only the session and permission details present in that contract.
- Events and analytics describes the event explorer and analytics surface.
- Notifications and webhooks summarizes notification endpoints and their documented lifecycle.
The contract uses a configurable Cloud host. Select an API specification in the reference before reading its operation details, and do not treat the example host as a live deployment address.
First successful API check
If your deployment has given you an authorized Console session, a small read-only first check is GET /v1/events. Use the host supplied for that deployment and provide the operation's required time range when using its default explorer view. A successful response is HTTP 200 with the documented event response shape; an empty events array can still be a valid result for a range with no matching events.
The contract identifies a signal_session cookie but does not describe how to sign in or obtain it. Do not copy a session value into a public example or guess a credential flow. See Authentication and permissions for that boundary and Events and analytics for the query fields and response details.
When a request does not succeed
- For a
400, compare the query or body with the operation's required parameters and schema. - For a
403, check the operation's documented permission and community scope; access must be granted by the deployment. - For a
500, retain therequest_idfrom the documented error response and use the support path for your deployment.
The API reference is the source for exact status codes and operation-specific error responses.