# API reference

Every endpoint below answers at `https://api.pingtower.com`, over TLS —
almost all of them with a bearer token. Which token you send decides which
plane you are on — the prefixes are mutually exclusive, so one kind can
never be mistaken for another.

This page is generated from the daemon's route table rather than written by
hand, and a build gate fails when the two disagree. Nothing here can outlive
the code it describes.

It covers the planes an integration talks to: the **ingest plane**, where
your services write events; the **API-key plane**, where everything else is
read and configured; and the slice of the **account plane** that pairing and
push need — linking a hosted account to a self-hosted box, device
registration, relay keys. The rest of the account plane — signing up,
creating tenants, minting the API keys used here — is the shipped clients'
surface and is not documented as an integration point.

The full machine-readable spec, including every parameter and schema, is at
[/api/openapi.json](https://www.pingtower.com/api/openapi.json).

## Authentication

Requests carry a bearer token; the prefix decides which plane it opens, so
one kind of token can never be mistaken for another. The few routes marked
`Auth: none` authenticate by the one-shot code or key they redeem.

- **API key** — `Authorization: Bearer ptk_<tenant>_<secret>`. A tenant API key. Operations marked x-pingtower-role: manager additionally require the key's live membership role to be owner or admin. See docs/architecture/transport-auth for the plane's boundaries.
- **ingest token** — `Authorization: Bearer pti_<tenant>_<secret>`. A source's ingest token. The tenant segment routes the write; the secret is verified against that tenant's own sources table. See docs/architecture/transport-auth for the plane's boundaries.
- **session token** — `Authorization: Bearer pts_<secret>`. An account session token. The account plane only — a session manages tenants and never touches alert data directly. See docs/architecture/transport-auth for the plane's boundaries.

## actions

Operator-defined HTTP runbook actions and their execution log.

### GET /v1/projects/{id}/actions

List runbook actions. Auth: API key.

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

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

### POST /v1/projects/{id}/actions

Create a runbook action. Auth: API key.

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.

```sh
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}'
```

### GET /v1/projects/{id}/actions/{aid}

Read one runbook action. Auth: API key.

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

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

### PUT /v1/projects/{id}/actions/{aid}

Update a runbook action. Auth: API key.

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.

```sh
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 /v1/projects/{id}/actions/{aid}

Delete a runbook action. Auth: API key.

Removes the action. Its execution-log rows stay.

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

### GET /v1/projects/{id}/actions/{aid}/executions

List an action's executions. Auth: API key.

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

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

### POST /v1/projects/{id}/actions/{aid}/test

Test-fire a runbook action. Auth: API key.

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.

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

## alerts

The alert stream, and acknowledging or resolving what it carries.

### POST /v1/alerts/{id}/ack

Acknowledge an alert. Auth: API key.

Marks the alert as being worked on, which stops its renotify timer without closing it. Acknowledging an alert that is already resolved is a conflict, not a no-op.

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

### POST /v1/alerts/{id}/resolve

Resolve an alert. Auth: API key.

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.

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

### GET /v1/pull

Long-poll the alert stream. Auth: API key.

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.

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

## devices

Push-notification device registration, scoped to the calling account.

### GET /v1/account/devices

List this account's device push tokens (account plane). Auth: session token.

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.

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

### POST /v1/account/devices

Register a device push token (account plane). Auth: session token.

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.

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

### DELETE /v1/account/devices/{token}

Unregister a device push token (account plane). Auth: session token.

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.

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

### GET /v1/devices

List the account's registered devices. Auth: API key.

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.

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

### POST /v1/devices

Register a device push token. Auth: API key.

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.

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

### DELETE /v1/devices/{token}

Unregister a device push token. Auth: API key.

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.

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

## ingest

Writing events into a project from an instrumented service.

### POST /v1/ingest

Ingest one event. Auth: ingest token.

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.

```sh
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"]}'
```

## integrations

Typed delivery channels — webhook, Telegram, Slack, and APNs.

### GET /v1/projects/{id}/integrations

List typed integrations. Auth: API key.

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.

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

### POST /v1/projects/{id}/integrations

Create a typed integration. Auth: API key.

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.

```sh
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/..."}'
```

### GET /v1/projects/{id}/integrations/{iid}

Read one integration. Auth: API key.

The channel as stored, minus its credentials.

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

### PUT /v1/projects/{id}/integrations/{iid}

Update an integration. Auth: API key.

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.

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

### DELETE /v1/projects/{id}/integrations/{iid}

Delete an integration. Auth: API key.

Removes the channel and its stored credentials.

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

### GET /v1/projects/{id}/integrations/{iid}/deliveries

List an integration's deliveries. Auth: API key.

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

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

### POST /v1/projects/{id}/integrations/{iid}/disable

Disable an integration. Auth: API key.

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

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

### POST /v1/projects/{id}/integrations/{iid}/enable

Enable an integration. Auth: API key.

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

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

### POST /v1/projects/{id}/integrations/{iid}/test

Test-fire an integration. Auth: API key.

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.

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

## logs

Retained log lines, for the sources configured to keep them.

### GET /v1/projects/{id}/logtail

Read retained log lines. Auth: API key.

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.

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

## oncall

On-call schedules, their overrides, and who is paging right now.

### GET /v1/projects/{id}/oncall/schedules

List on-call schedules. Auth: API key.

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

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

### POST /v1/projects/{id}/oncall/schedules

Create an on-call schedule. Auth: API key.

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.

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

### GET /v1/projects/{id}/oncall/schedules/{sid}

Read one on-call schedule. Auth: API key.

The schedule as stored, including its layers.

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

### PUT /v1/projects/{id}/oncall/schedules/{sid}

Update an on-call schedule. Auth: API key.

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

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

### DELETE /v1/projects/{id}/oncall/schedules/{sid}

Delete an on-call schedule. Auth: API key.

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

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

### GET /v1/projects/{id}/oncall/schedules/{sid}/current

Who is on call right now. Auth: API key.

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.

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

### GET /v1/projects/{id}/oncall/schedules/{sid}/overrides

List a schedule's overrides. Auth: API key.

Every override on the schedule, past and future.

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

### POST /v1/projects/{id}/oncall/schedules/{sid}/overrides

Add an on-call override. Auth: API key.

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.

```sh
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":"2026-08-12T09:00:00Z",
       "ends_at":"2026-08-12T17:00:00Z"}'
```

### DELETE /v1/projects/{id}/oncall/schedules/{sid}/overrides/{oid}

Delete an on-call override. Auth: API key.

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

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

## pairing

Linking a hosted account to a box account, and deciding whose phone rings.

### POST /v1/pair

Redeem a pairing code for a data credential. Auth: none.

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.

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

### POST /v1/pair/codes

Issue a pairing code for someone joining this box. Auth: API key (manager role).

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.

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

### GET /v1/pair/verify

Redeem a pairing receipt (called by pingtower.com). Auth: none.

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.

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

### POST /v1/tenants/{tid}/pair

Link this account to a box account. Auth: session token.

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.

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

### GET /v1/tenants/{tid}/pairings

List who on this tenant is pageable, and who was. Auth: session token.

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.

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

### DELETE /v1/tenants/{tid}/pairings/{aid}

Stop paging one person for this tenant. Auth: session token.

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.

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

### POST /v1/tenants/{tid}/relay-key

Rotate the tenant's relay credential. Auth: session token.

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.

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

## projects

Projects — the namespace every source, rule, and report lives in.

### GET /v1/projects

List the tenant's projects. Auth: API key.

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.

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

### POST /v1/projects

Create a project. Auth: API key.

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.

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

### DELETE /v1/projects/{id}

Delete a project. Auth: API key (manager role).

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.

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

### POST /v1/projects/{id}/rename

Rename a project. Auth: API key (manager role).

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.

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

## relay

Receiving a self-hosted box's alerts and paging its tenant's phones.

### GET /v1/relay

Read whether this box can page a phone. Auth: API key.

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.

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

### PUT /v1/relay

Configure where this box sends alerts to be paged. Auth: API key (manager role).

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.

```sh
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"}'
```

### POST /v1/relay/{key_id}

Relay a self-hosted alert to its tenant's phones. Auth: none.

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.

```sh
# 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", ...}'
```

## reports

Incident reports and the shareable public status page behind each one.

### GET /v1/projects/{id}/reports

List a project's reports. Auth: API key.

Every report on the project, with its status and public UUID.

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

### POST /v1/projects/{id}/reports

Create an incident report. Auth: API key.

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.

```sh
curl -X POST https://api.pingtower.com/v1/projects/demo/reports \
  -H "Authorization: Bearer ptk_<tenant>_..." \
  -d '{"title":"API degraded","status":"investigating"}'
```

### GET /v1/projects/{id}/reports/{rid}

Read one report. Auth: API key.

The report with its authored entries, newest last.

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

### PUT /v1/projects/{id}/reports/{rid}

Update a report. Auth: API key.

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.

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

### DELETE /v1/projects/{id}/reports/{rid}

Delete a report. Auth: API key.

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

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

### POST /v1/projects/{id}/reports/{rid}/entries

Append a report entry. Auth: API key.

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.

```sh
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."}'
```

### PUT /v1/projects/{id}/reports/{rid}/entries/{eid}

Revise a report entry. Auth: API key.

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

```sh
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 /v1/projects/{id}/reports/{rid}/entries/{eid}

Delete a report entry. Auth: API key.

Removes the entry from the public timeline.

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

### POST /v1/projects/{id}/reports/{rid}/rotate-uuid

Rotate a report's public link. Auth: API key.

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.

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

## rules

Match conditions that turn events into alerts, and their escalation ladders.

### GET /v1/projects/{id}/rules

List a project's rules. Auth: API key.

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

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

### POST /v1/projects/{id}/rules

Create a rule. Auth: API key.

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.

```sh
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}'
```

### GET /v1/projects/{id}/rules/{name}

Read one rule. Auth: API key.

The rule as stored, including any escalation ladder.

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

### PUT /v1/projects/{id}/rules/{name}

Update a rule. Auth: API key.

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.

```sh
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 /v1/projects/{id}/rules/{name}

Delete a rule. Auth: API key.

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

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

## sources

Named event producers within a project, each holding an ingest token.

### GET /v1/projects/{id}/sources

List a project's sources. Auth: API key.

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.

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

### POST /v1/projects/{id}/sources

Create a source. Auth: API key.

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.

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

### PUT /v1/projects/{id}/sources/{name}

Update a source. Auth: API key.

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.

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

### DELETE /v1/projects/{id}/sources/{name}

Delete a source. Auth: API key.

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

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

### POST /v1/projects/{id}/sources/{name}/rotate-token

Rotate a source's ingest token. Auth: API key (manager role).

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.

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

## webhooks

The plain delivery-endpoint surface over the shared outbox.

### GET /v1/projects/{id}/webhooks

List delivery endpoints. Auth: API key.

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

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

### POST /v1/projects/{id}/webhooks

Create a delivery endpoint. Auth: API key.

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.

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

### PATCH /v1/projects/{id}/webhooks/{wid}

Enable or disable a delivery endpoint. Auth: API key.

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.

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

### DELETE /v1/projects/{id}/webhooks/{wid}

Delete a delivery endpoint. Auth: API key.

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

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