Immediate action
Use for an outage or condition where a delayed response materially increases impact.
Developer guide
A focused, server-side contract for sending urgent pages to Sevloom. Start with the request shape, test safely, then connect the same call to your monitoring or automation workflow.
Prerequisites
You need a Sevloom Cloud account, a service, a paired device, and a service API key. Keep the key on your server or in a secret manager; never expose it in browser or mobile code.
Sign in to Sevloom Cloud, create or select a workspace, and create a service for the team or system that will send pages.
Install the Sevloom app, generate a pairing code from the service dashboard, and pair one or more responder devices.
Open the service API keys section, create a labeled key, and copy it once. Store it as SEVLOOM_API_KEY in your server environment.
Use one of the examples below from trusted server-side code and confirm that the page arrives on the paired device.
Send a page
See the endpoint, authentication header, and request body together. Replace the placeholder API key with the key created in Sevloom Cloud.
curl --request POST https://page.sevloom.com/v1/send \
--header "X-Sevloom-API-Key: YOUR_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"severity": "sev2",
"title": "Checkout API unavailable",
"message": "5xx responses exceeded 20% for five minutes.",
"source": "checkout-api",
"environment": "production",
"deduplicationKey": "checkout-api-5xx",
"occurredAt": "2026-09-06T23:05:00.000Z",
"metadata": { "region": "us-east-1", "runbookUrl": "https://example.com/runbooks/checkout-api" }
}'Request attributes
Required attributes are listed first, followed by optional context fields.
severitystringtitlestringmessagestringdeduplicationKeystringsourcestringenvironmentstringoccurredAtstringmetadataobjectResponse
A successful request returns an accepted page identifier and a request ID for tracing. The response does not echo the full request payload.
{
"data": {
"id": "page identifier",
"status": "accepted",
"deduplicated": false,
"receivedAt": "2026-09-06T23:05:00.000Z"
},
"meta": {
"apiVersion": "v1",
"requestId": "request correlation ID"
}
}Errors
Use the HTTP status and request ID to diagnose failures. Retry only when the error is transient, and reuse the same deduplication key when retrying an uncertain request.
Severity
Severity is not inferred from the kind of error. A caller explicitly assigns SEV-1 through SEV-5 based on the response it needs. Every accepted request creates a page.
Use for an outage or condition where a delayed response materially increases impact.
Use for major degradation or a failed workflow that needs prompt attention.
Use for a meaningful issue that needs investigation without the strongest interruption.
Use for a lower-urgency operational condition that is still worth seeing.
Use for context that should create a page without a pager sound.
Deduplication
deduplicationKey is required. Reuse the same value when retrying after an uncertain network response or reporting the same condition. During the active deduplication window, Sevloom returns the existing page ID instead of creating a duplicate. Use a different stable key for a different condition. When the page corresponds to a ticket or incident, its stable identifier, such as INC-48291, is a good key.
INC-48291A ticket or incident ID stays stable across updates to the same issue.Also goodcheckout-api-5xxA stable monitor-condition identifier.Avoidcheckout-api-2026-09-06T23:05:00ZA timestamp makes every request look unrelated.Page lifecycle
The send endpoint returns accepted as a submission receipt because delivery is asynchronous. The page itself then follows the responder lifecycle: open until someone acknowledges it, then acknowledged. Sevloom records the page request, applies the deduplication key, and keeps each responder acknowledgement in the page history.