API reference

List runbook actions

Every action on the project. Stored headers and bodies marshal as "-" rather than in cleartext.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/actions \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create a runbook action

An action is an HTTP call the daemon makes on your behalf when an alert fires. events defaults to alert.opened; alert.escalated is opt-in per action. The timeout is capped so a slow target cannot pin the worker, and header names and values are length- and charset-limited like every other field here.

headers and body are sealed at rest and never echoed back by a read, so a read-modify-write update that omits them keeps what is stored rather than clearing it.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/actions \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"restart-api","method":"POST",
       "url":"https://ops.internal/restart","timeout_seconds":10}'

Read one runbook action

The action as stored, with its sealed headers and body redacted.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/actions/<aid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

Update a runbook action

An omitted enabled, headers, or body keeps the stored value rather than resetting it — necessary because a read never hands the sealed fields back, so a client that reads then writes cannot resend them. Send body as an explicit empty string to clear it.

Path parameters

Request body

Responses

Example

curl -X PUT https://api.pingtower.com/v1/projects/demo/actions/<aid> \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"restart-api","method":"POST",
       "url":"https://ops.internal/restart","enabled":false}'

Delete a runbook action

Removes the action. Its execution-log rows stay.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/actions/<aid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

List an action's executions

The execution log the background drain worker fills in as alert-triggered runs settle, plus any terminal rows from test fires.

Path parameters

Query parameters

Responses

Example

curl "https://api.pingtower.com/v1/projects/demo/actions/<aid>/executions?limit=50" \
  -H "Authorization: Bearer ptk_<tenant>_..."

Test-fire a runbook action

Runs the action once, synchronously, with its stored headers and body, through the same guarded executor and per-action timeout every alert-driven run uses. The result is recorded as one terminal execution-log row rather than a retryable queued one.

A daemon started without a configured executor answers 503.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/actions/<aid>/test \
  -H "Authorization: Bearer ptk_<tenant>_..."

Acknowledge an alert

Marks the alert as being worked on, which stops its renotify timer without closing it. Acknowledging an alert that is already acked or resolved changes nothing and returns 200 with the alert as it stands; only an unknown id is an error.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/alerts/42/ack \
  -H "Authorization: Bearer ptk_<tenant>_..."

Resolve an alert

Closes the alert. A resolved alert stops counting against the project's open_alerts and stops renotifying; the matching rule opens a new alert if the condition recurs.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/alerts/42/resolve \
  -H "Authorization: Bearer ptk_<tenant>_..."

Long-poll the alert stream

Returns alerts newer than cursor, in id order, and the cursor to pass next. With wait set, the request parks until an alert arrives or the wait elapses, so a poller costs one connection rather than a busy loop. The tenant's store is held for the whole park, including the wait.

Query parameters

Responses

Example

curl "https://api.pingtower.com/v1/pull?cursor=0&wait=25" \
  -H "Authorization: Bearer ptk_<tenant>_..."

List this account's device push tokens (account plane)

Every device token registered to the calling session's account, with the platform and last-seen time of each. The session-authenticated counterpart to GET /v1/devices.

Responses

Example

curl https://api.pingtower.com/v1/account/devices \
  -H "Authorization: Bearer pts_..."

Register a device push token (account plane)

The same registry as POST /v1/devices, reached with a session token instead of a tenant API key. Prefer this one.

Registering a handset was never a tenant-scoped act — a device token belongs to an account, and the tenant key was only ever expressing which bearer the client happened to hold. Authenticating it with a tenant key becomes wrong once a tenant's data plane can live on a box the tenant runs: that tenant's only data key is minted by its box, and no data key issued anywhere would reach this registry. A session token has neither problem, and it exists before any tenant is selected.

Body, token format, critical_alerts, and the 20-per-account limit are identical to POST /v1/devices. The tenant-key routes remain for shipped clients.

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/account/devices \
  -H "Authorization: Bearer pts_..." \
  -d '{"token":"<64 hex>","platform":"ios","critical_alerts":true}'

Unregister a device push token (account plane)

The sign-out half of the contract above, session-authenticated. Call it before a different account signs into the same physical device, or the outgoing account's row lingers and keeps pushing to that handset.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/account/devices/<64 hex> \
  -H "Authorization: Bearer pts_..."

List the account's registered devices

Every device token registered to the calling key's account — not to its tenant. An account in three tenants sees one list, whichever tenant's key it asks with.

Responses

Example

curl https://api.pingtower.com/v1/devices \
  -H "Authorization: Bearer ptk_<tenant>_..."

Register a device push token

The token is account-scoped, not tenant-scoped: the same handset registered from two tenants resolves to one row per account. Another account registering the same physical device does not retire this account's row.

That makes DELETE /v1/devices/{token} the client's sign-out obligation. Call it before a different account signs in on this device, or the outgoing account keeps receiving its tenant's pushes here. An uninstall is reclaimed without client cooperation — APNs reports the token permanently gone and the daemon prunes it.

The token must be exactly 64 hex characters, the format Apple's token-based provider API expects. The strictness is deliberate: two strings differing only in case or in stray characters would otherwise each take their own row while addressing the same handset.

critical_alerts is optional and defaults to false. It is the handset's own answer to whether a critical push would actually break through Do Not Disturb, a Focus, or a silenced ringer — an omitted key (every shipped App Store build today) means the daemon must not treat this device as able to receive one. Every registration is a complete, fresh report: re-registering with a changed value overwrites what is stored, in either direction.

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/devices \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"token":"<64 hex>","platform":"ios","critical_alerts":true}'

Unregister a device push token

The sign-out half of the contract above. Call this before a different account signs into the same physical device, or the outgoing account's row lingers and keeps pushing to that handset.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/devices/<64 hex> \
  -H "Authorization: Bearer ptk_<tenant>_..."

Ingest one event

The only route an ingest token may call. The token's tenant segment picks the store; the secret is verified against that tenant's own sources table, and the source it resolves to decides which project the event lands in — nothing in the body names a project.

Levels are HTTP-ish: 100 debug, 200 info, 300 warn, 400 error, 500 critical. Key values arrive as arbitrary JSON scalars and are stringified. The per-field caps are defence in depth below the overall body limit: one event is a log line plus a handful of structured keys, not a bulk payload.

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/ingest \
  -H "Authorization: Bearer pti_<tenant>_..." \
  -d '{"message":"user bob logged in","level":200,
       "keys":{"name":"bob"},"tags":["auth"]}'

List typed integrations

Every channel on the project. Credentials are never echoed back. An apns row additionally carries device_count, joined at request time from the account's registered devices.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/integrations \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create a typed integration

Which credential fields are required depends on type: webhook needs url (secret is optional and minted when absent), telegram needs token and chat_id, slack needs webhook_url.

An apns integration takes no credentials at all. The push provider key is one operator-wide credential rather than a per-project one, and its recipients come from tenant membership — so every credential field is rejected on that type rather than quietly ignored.

Path parameters

Request body

Responses

The 201 response body here is assembled across branches, so its exact key set depends on the path taken. The example shows the shape; a guessed schema would be worse than the omission.

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/integrations \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"type":"slack","name":"eng-alerts",
       "webhook_url":"https://hooks.slack.com/services/..."}'

Read one integration

The channel as stored, minus its credentials.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/integrations/<iid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

Update an integration

type is pinned server-side to the stored value and cannot be changed. A blank credential field keeps what is already stored, and an omitted name or events key keeps what is already stored — only a key that is present, including an explicitly empty one, changes anything. Read a channel, edit one field, send it back: nothing you did not mention moves.

Path parameters

Request body

Responses

Example

curl -X PUT https://api.pingtower.com/v1/projects/demo/integrations/<iid> \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"eng-alerts-oncall"}'

Delete an integration

Removes the channel and its stored credentials.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/integrations/<iid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

List an integration's deliveries

The delivery log for one channel — what was attempted, when, and how it ended. This is where a silently failing channel becomes visible.

Path parameters

Query parameters

Responses

Example

curl "https://api.pingtower.com/v1/projects/demo/integrations/<iid>/deliveries?limit=50" \
  -H "Authorization: Bearer ptk_<tenant>_..."

Disable an integration

Stops delivery through the channel while keeping its configuration and credentials in place.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/integrations/<iid>/disable \
  -H "Authorization: Bearer ptk_<tenant>_..."

Enable an integration

Resumes delivery through the channel and clears its failure streak — the way back from a circuit-broken endpoint.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/integrations/<iid>/enable \
  -H "Authorization: Bearer ptk_<tenant>_..."

Test-fire an integration

Sends a synthetic alert.test event through the channel synchronously, so you learn whether the credentials work without waiting on the drain tick or opening a real alert. The response reports the channel's own answer, so a 200 here can still carry ok=false with the remote error.

A daemon started without a configured sender answers 503: delivery is optional, and the rest of the API runs without it.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/integrations/<iid>/test \
  -H "Authorization: Bearer ptk_<tenant>_..."

Read retained log lines

Returns the most recent retained events for the project, newest last. Only sources created or updated with retain_logs set have anything here; the rest keep no line-level history at all.

Path parameters

Query parameters

Responses

Example

curl "https://api.pingtower.com/v1/projects/demo/logtail?limit=50" \
  -H "Authorization: Bearer ptk_<tenant>_..."

List on-call schedules

Every schedule on the project, with its layers and participants.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/oncall/schedules \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create an on-call schedule

Every participant is checked against the tenant's memberships at write time. A schedule routing through a non-member would silently page nobody, so it is rejected with a 422 listing each offending account rather than accepted and left to fail quietly at 3am.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/oncall/schedules \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"primary","timezone":"UTC",
       "layers":[{"name":"weekly","participants":["<account_id>","<account_id>"],
                  "rotation_start":1756677600,"shift_minutes":10080}]}'

Read one on-call schedule

The schedule as stored, including its layers.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/oncall/schedules/primary \
  -H "Authorization: Bearer ptk_<tenant>_..."

Update an on-call schedule

Replaces the schedule's layers and participants, re-checking every participant against the tenant's memberships.

Path parameters

Request body

Responses

Example

curl -X PUT https://api.pingtower.com/v1/projects/demo/oncall/schedules/primary \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"primary","timezone":"UTC",
       "layers":[{"name":"daily","participants":["<account_id>","<account_id>"],
                  "rotation_start":1756677600,"shift_minutes":1440}]}'

Delete an on-call schedule

Refused while a rule's escalation ladder still names the schedule — deleting it would leave that ladder paging nobody. Detach the ladder step first.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/oncall/schedules/primary \
  -H "Authorization: Bearer ptk_<tenant>_..."

Who is on call right now

Resolves the schedule's layers and any active override against the current time, and answers with the account and its email — or on_call=false when the rotation leaves nobody covering this moment.

Path parameters

Responses

The 200 response body here is assembled across branches, so its exact key set depends on the path taken. The example shows the shape; a guessed schema would be worse than the omission.

Example

curl https://api.pingtower.com/v1/projects/demo/oncall/schedules/primary/current \
  -H "Authorization: Bearer ptk_<tenant>_..."

List a schedule's overrides

Every override on the schedule, past and future.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/oncall/schedules/primary/overrides \
  -H "Authorization: Bearer ptk_<tenant>_..."

Add an on-call override

A time-bounded substitution covering [starts_at, ends_at). The duration is capped: an override is not a way to permanently reassign a schedule — that belongs in the schedule's own layers — so an effectively-permanent window is rejected at write time rather than silently accepted.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/oncall/schedules/primary/overrides \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"account_id":"<account_id>","starts_at":1755000000,
       "ends_at":1755028800}'

Delete an on-call override

Removes the substitution, returning the window to whatever the schedule's layers resolve to.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/oncall/schedules/primary/overrides/<oid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

Redeem a pairing code for a data credential

The box half of pairing, and the only route in the product that mints a tenant API key without a session. The code is the credential: a one-shot secret the box's operator issued with `pingtower pair` and read out to a person, valid for an hour and unrecoverable from the database afterwards.

What comes back is a `ptk_` this box minted for an account this box holds, so the data plane it opens is the box's own — no assertion signed elsewhere, and nothing that stops working when pingtower.com does. The receipt alongside it is for pingtower.com, which redeems it once at GET /v1/pair/verify to satisfy itself that the person claiming this pairing really did pair.

Every failure answers 401 with one message. "Already redeemed" and "no such code" are exactly the distinction a holder of a candidate code would like back, and neither helps the legitimate holder, who has the operator standing next to them.

Request body

Responses

Example

curl -X POST https://box.example.com/v1/pair \
  -d '{"code":"<48 hex>","display_name":"nightowl",
       "email":"[email protected]","password":"<8-72 bytes>"}'

Issue a pairing code for someone joining this box

Mints a one-shot code that admits one person to this tenant, and returns a join code carrying it once this box knows its counterpart on pingtower.com. Manager-gated: issuing a code is the act of admitting somebody, which is the same rank that decides who this tenant's pages reach.

It exists so that adding a teammate does not require a shell on the box. `pingtower pair` is still the bootstrap path and still the one that works when nothing else does — on a new box there is no account, no membership, and no key to authenticate this call with.

The code names a **seat**, not an account: whoever redeems it brings or creates their own account on this box, with a password they choose. Nothing is created here, so a code that is never redeemed leaves nothing behind — unlike the CLI's account-bound form, which creates an account, a membership, and a generated password whether or not anybody turns up.

`email` optionally binds the seat to one address, and is worth setting whenever the issuer knows who they are inviting: an unbound seat is one that whoever holds the code may take, so a leaked code admits a stranger rather than the intended person. A code may not be issued at a role above the issuer's own.

`ttl_seconds` defaults to an hour and is capped at seven days. An hour suits a code read out while somebody is standing there; a seat sent by chat is acted on later.

Request body

Responses

The 201 response body here is assembled across branches, so its exact key set depends on the path taken. The example shows the shape; a guessed schema would be worse than the omission.

Example

curl -X POST https://box.example.com/v1/pair/codes \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"role":"member","email":"[email protected]","ttl_seconds":86400}'

Redeem a pairing receipt (called by pingtower.com)

The other end of the callback. pingtower.com fetches this once, while the user is waiting, to learn which of the box's accounts a receipt vouches for — without it, any signed-in account that learned a tenant id could attach itself to that tenant's roster.

It answers the box account id and nothing else, and the receipt is one-shot and short-lived, so a caller who somehow guessed one learns an identifier they had already claimed to know.

Clients do not call this. It is documented because a self-hoster's box must answer it, and because an operator reading their access log is entitled to know what pingtower.com asked for.

Query parameters

Responses

Example

curl "https://box.example.com/v1/pair/verify?receipt=<48 hex>"

Link this account to a box account

Records that the caller is a particular account on the tenant's box, and therefore that this account's phones may be paged for that tenant. It grants no data access: on a self-hosted tenant that is the box's to grant, which is also why invite and role-change refuse for these tenants.

The tenant's first pairing is self-authorizing — the account that created the tenant is the one that just set its data plane URL — and is the only one that receives the relay credential, since that credential authorizes paging the whole tenant. Every pairing after it must present a receipt, which pingtower.com redeems against the box before writing anything.

That redemption runs pingtower.com→box, over public HTTPS, through the SSRF-guarded client. So the requirement it implies is worth stating plainly: a box on a private address or a tailnet can pair the person who created the tenant and nobody after. The phone may be on the tailnet; pingtower.com never is. A team's box needs a publicly resolvable HTTPS endpoint, and the 401 this route answers with says so.

Path parameters

Request body

Responses

The 201 response body here is assembled across branches, so its exact key set depends on the path taken. The example shows the shape; a guessed schema would be worse than the omission.

Example

curl -X POST https://api.pingtower.com/v1/tenants/<tid>/pair \
  -H "Authorization: Bearer pts_..." \
  -d '{"box_account_id":"<box account>","receipt":"<48 hex>"}'

List who on this tenant is pageable, and who was

The roster behind the pages. Each row names a hosted account, the box account it is linked to, when the link was made, and `revoked_at` — null while the pairing is live. Revoked rows are returned deliberately: "was paired and is not any more" is what an owner auditing the roster is looking for, and omitting them would make a revocation look identical to never having paired.

A box cannot answer this itself. The pairings live on pingtower.com, so a box's own escalation ladder renders names it has no way to resolve a pairing for — a rung that pages nobody looks exactly like one that works. A client holding both hosts joins this list to the box's ladder on `box_account_id` and can say which is which.

Visible to any member rather than to managers only: knowing whether you yourself are pageable is not privileged, and it is the fact a person most needs before the night they are not woken. A hosted tenant has no box, so it answers 409 rather than an empty list, which would read as a tenant that pages nobody.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/tenants/<tid>/pairings \
  -H "Authorization: Bearer pts_..."

Stop paging one person for this tenant

The act that stops the pages, and the counterpart to removing someone's box membership, which stops their data access. Neither implies the other: doing only the first leaves a leaver reading and writing the data in silence, and doing only the second leaves them receiving pushes that carry log lines.

It writes one column on one row and consults nothing else, so nothing about the tenant's schedules, ladders, or store can make it fail. Revoking the last pairing is allowed and means "this box pages nobody". Re-pairing restores it.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/tenants/<tid>/pairings/<aid> \
  -H "Authorization: Bearer pts_..."

Rotate the tenant's relay credential

Mints a fresh relay credential and revokes every earlier one — the tenant-wide kill switch for a box that has been compromised or is misbehaving, as against revoking one person's pairing, which is per person and reversible.

The secret is returned exactly once, and the app is its courier to the box exactly as at pairing. Owner-gated: until the box is reconfigured with the new credential, its pages stop.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/tenants/<tid>/relay-key \
  -H "Authorization: Bearer pts_..."

List the tenant's projects

The project index: every project the API key's tenant owns, each entry carrying its name, config version, source and rule counts, open alert count, and creation time, name-ordered. Paginate with after, which takes the name the previous page ended on.

Query parameters

Responses

The 200 response body here is assembled across branches, so its exact key set depends on the path taken. The example shows the shape; a guessed schema would be worse than the omission.

Example

curl "https://api.pingtower.com/v1/projects?limit=50" \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create a project

Projects are explicit rows rather than namespaces conjured on first write, so a typo in a later request fails with a 404 instead of silently creating a second project. The name is caller-chosen and is the id every nested route addresses.

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"demo"}'

Delete a project

Removes the project with its sources, rules, alerts, and reports. Any public status pages the project's reports published stop resolving. Requires an owner or admin key.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo \
  -H "Authorization: Bearer ptk_<tenant>_..."

Rename a project

Changes the name every nested route addresses the project by. Existing ingest tokens keep working — they resolve through the source row, not through the project name. Requires an owner or admin key.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/rename \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"demo-eu"}'

Read whether this box can page a phone

Answers whether a relay credential has been configured on this tenant, and the URL its alerts are sent to. The secret is never returned.

It exists so "does this page anybody?" is a question with an answer. A ladder rung that pages nobody looks identical to one that works, and the version of that discovery nobody wants is the one made during an incident.

A tenant hosted by pingtower.com answers `configured: false` and always will: it has no box, and its pushes go out through its own apns integration instead.

Responses

Example

curl https://box.example.com/v1/relay \
  -H "Authorization: Bearer ptk_<tenant>_..."

Configure where this box sends alerts to be paged

Records the relay credential pingtower.com minted at pairing, and wires every project on this tenant to it — the ones that exist now, and the ones created afterwards, which inherit it at creation.

That second half is the point of the route. Delivery endpoints are per project, so configuring a relay by hand would mean pasting a credential once per project, and a project created next week would page nobody with nothing to say so. The endpoint it writes is an ordinary webhook integration named "pingtower.com relay": same outbox, same HMAC signature, same retry and circuit breaker as any endpoint configured by hand.

The app calls this, not a person. It holds both ends of the pairing moment — the code it just redeemed here, and the credential it just received from pingtower.com — so no operator copies a secret between two web UIs.

Manager-gated: it decides where this tenant's alerts go to become pages, which is the same rank that decides who those pages reach. Writing it again replaces the credential rather than adding a second relay, so rotating a compromised key is this call with the new secret.

The secret is write-only. No read route selects it, so a box member cannot recover it from a project they can otherwise see.

`hosted_tenant_id` and `box_public_url` are the other half of the same link, and both are optional. They tell the box which tenant it is on pingtower.com and the URL pingtower.com reaches it at — two facts a box cannot derive, since the ids are separate namespaces and a box behind a proxy does not reliably know the name it is reached by. `pingtower pair` reads them back to print a single join code instead of leaving an operator to read out three strings. Neither is a secret: knowing a tenant id grants nothing, because every pairing but a tenant's first must survive the verify callback.

They are recorded only when both are present, so a half-written counterpart cannot produce a join code that resolves to the wrong place. Omitting them leaves whatever was recorded before untouched.

Request body

Responses

Example

curl -X PUT https://box.example.com/v1/relay \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"relay_url":"https://api.pingtower.com/v1/relay/rk_<id>",
       "relay_secret":"<48 hex>",
       "hosted_tenant_id":"<hosted tenant>",
       "box_public_url":"https://box.example.com"}'

Relay a self-hosted alert to its tenant's phones

The one inbound route a self-hosted box calls, and the reason self-hosting can page a phone at all. The box's rule fires, its ladder resolves, its outbox delivers the resulting event here, and pingtower.com sends the push under the operator's APNs credential — which is the one thing a box cannot do for itself, because Apple accepts a push for an app's bundle id only from a key issued under the team that owns it.

Clients do not call this. A box does, and it does so as an ordinary HMAC-signed webhook delivery: the body is the same `WebhookEvent` any webhook endpoint receives, signed the same way, retried by the same durable outbox. The relay key id rides in the path because a webhook endpoint holds a URL and a secret and nothing else, so there is nowhere to put a header — which is what keeps the box's half of the relay configuration rather than code.

The tenant comes from the key id and never from the body. A tenant id read out of relayed JSON would let any box page any tenant's phones.

An unknown key id, a revoked key id, and a bad signature answer alike, so the route cannot be used to enumerate live keys. A timestamp more than five minutes from now is refused separately — only a caller already holding the secret can reach that check. The body is capped at 64KB and refused on Content-Length before it is read, and each tenant's relay traffic is rate limited on the far side of the key lookup.

Delivery is at-least-once, so the route is idempotent on (tenant, alert, event, timestamp): a replayed delivery answers 200 without sending a second push. A delivery whose push fails answers 5xx *and* forgets the claim, so the box's retry is treated as a first attempt.

Whose phones ring is decided by `box_pairings`, on every event kind. An escalation's `page_accounts` arrive as box account ids and are translated; every other event kind fans out to the tenant's members narrowed to those holding a live pairing. A box account with no live pairing resolves to no devices either way, which is what makes revoking a pairing stop pages immediately.

Path parameters

Responses

Example

# A box does this; the URL is what its operator pasted at pairing.
curl -X POST https://api.pingtower.com/v1/relay/rk_<id> \
  -H "X-Pingtower-Timestamp: 1754870400" \
  -H "X-Pingtower-Signature: <hmac-sha256 of ts.body>" \
  -d '{"event":"alert.opened","alert_id":"a1","project":"api", ...}'

List a project's reports

Every report on the project, with its public UUID and whether it is password-protected.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/reports \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create an incident report

A report gets an unguessable public UUID and a shareable status page at /public/reports/{uuid}. Setting view_password gates that page behind a bcrypt check; without one, anyone holding the UUID can read it.

alert_id, if set, must name a live alert in the same project.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/reports \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"title":"API degraded","description":"Gateway timeouts from 03:12 UTC.",
       "alert_id":"<alert_id>"}'

Read one report

The report with its authored entries, newest last.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/reports/<rid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

Update a report

view_password is tri-state: omitting the key keeps the current password, an explicit empty string clears it and reopens the public page, and any other value replaces it.

Path parameters

Request body

Responses

Example

curl -X PUT https://api.pingtower.com/v1/projects/demo/reports/<rid> \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"title":"API degraded (resolved)","view_password":""}'

Delete a report

Removes the report and unpublishes its status page — the public URL 404s from then on.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/reports/<rid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

Append a report entry

One authored update on the incident timeline. The markdown is rendered to sanitized HTML exactly once, here at write — standard formatting survives, scripts and event handlers do not.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/reports/<rid>/entries \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"content_md":"Root cause identified; rolling back."}'

Revise a report entry

Re-renders the entry's markdown through the same sanitizer.

Path parameters

Request body

Responses

Example

curl -X PUT https://api.pingtower.com/v1/projects/demo/reports/<rid>/entries/<eid> \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"content_md":"Rollback complete; monitoring."}'

Delete a report entry

Removes the entry from the public timeline.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/reports/<rid>/entries/<eid> \
  -H "Authorization: Bearer ptk_<tenant>_..."

Rotate a report's public link

The response to a leaked status-page URL. A fresh UUID is registered, the report re-keyed, and the old UUID dropped, so every copy of the old link 404s immediately.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/reports/<rid>/rotate-uuid \
  -H "Authorization: Bearer ptk_<tenant>_..."

List a project's rules

Every rule in the project, with its match condition, renotify interval, and escalation ladder.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/rules \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create a rule

A rule turns matching events into alerts. Any account a ladder step names is checked against the tenant's memberships at write time: a ladder routing through a non-member would silently page nobody, so it is rejected with a 422 instead.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/rules \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"errors","match":{"min_level":400},"renotify_minutes":15}'

Read one rule

The rule as stored, including any escalation ladder.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/rules/errors \
  -H "Authorization: Bearer ptk_<tenant>_..."

Update a rule

A rule's name is immutable and comes from the path. Sending a different name in the body is rejected rather than treated as a rename; delete and recreate instead.

Path parameters

Request body

Responses

Example

curl -X PUT https://api.pingtower.com/v1/projects/demo/rules/errors \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"match":{"min_level":500},"renotify_minutes":5}'

Delete a rule

Stops the rule opening further alerts. Alerts it already opened stay where they are.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/rules/errors \
  -H "Authorization: Bearer ptk_<tenant>_..."

List a project's sources

Each source is one named event producer. The listing never returns a source's ingest token — that is shown once, when the source is created or its token is rotated.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/sources \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create a source

Mints the source's pti_ ingest token and returns it once. Store it when you see it; there is no route that reads it back, only rotate-token, which replaces it.

retain_logs decides whether this source's events are kept for GET /v1/projects/{id}/logtail. Omitted on create it means "do not retain", which is why it is optional here and required on update.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/sources \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"name":"api","retain_logs":true}'

Update a source

retain_logs must be sent explicitly. An omitted field is rejected with a 400 rather than read as false, which would otherwise turn log retention off by accident on any partial update.

Path parameters

Request body

Responses

Example

curl -X PUT https://api.pingtower.com/v1/projects/demo/sources/api \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"retain_logs":false}'

Delete a source

Retires the source and its ingest token. Anything still holding that token starts failing authentication on POST /v1/ingest.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/sources/api \
  -H "Authorization: Bearer ptk_<tenant>_..."

Rotate a source's ingest token

Issues a new pti_ token and returns it once, invalidating the previous one immediately — this is the response to a leaked token, so there is no overlap window. Requires an owner or admin key.

Path parameters

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/sources/api/rotate-token \
  -H "Authorization: Bearer ptk_<tenant>_..."

List delivery endpoints

Every endpoint on the project, with its enabled state and failure streak.

Path parameters

Responses

Example

curl https://api.pingtower.com/v1/projects/demo/webhooks \
  -H "Authorization: Bearer ptk_<tenant>_..."

Create a delivery endpoint

The plain endpoint surface over the shared delivery outbox. Omitting secret makes the server mint one and return it once; omitting events subscribes the endpoint to every event.

A row created here is the same row the typed integrations routes see — the two families are two views onto one table, not two schemas.

Path parameters

Request body

Responses

Example

curl -X POST https://api.pingtower.com/v1/projects/demo/webhooks \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"url":"https://example.internal/hooks/pingtower"}'

Enable or disable a delivery endpoint

enabled must be sent explicitly — an omitted field is rejected rather than read as false, which would disable the endpoint by accident. Re-enabling clears the endpoint's failure streak, which is the only way to recover a circuit-broken endpoint short of deleting it.

Path parameters

Request body

Responses

Example

curl -X PATCH https://api.pingtower.com/v1/projects/demo/webhooks/<wid> \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"enabled":true}'

Delete a delivery endpoint

Removes the endpoint. Deliveries already queued for it are dropped.

Path parameters

Responses

Example

curl -X DELETE https://api.pingtower.com/v1/projects/demo/webhooks/<wid> \
  -H "Authorization: Bearer ptk_<tenant>_..."