---
title: "List the authenticated account's audit events"
method: GET
path: "/api/v1/account/events"
tags: ["Account"]
---

# List the authenticated account's audit events

`GET /api/v1/account/events`

## Request

- Base URL: `https://api.uptimemonitoring.com`
- URL: `https://api.uptimemonitoring.com/api/v1/account/events`
- Auth: HTTP bearer

Returns the per-account audit log written transactionally with every
monitor / webhook / api-key mutation plus account-level signals
(suspension, notification_email change). Newest-first by
`(created_at DESC, id DESC)`. Paginated by opaque cursor — see the
`cursor` parameter and the `next_cursor` response field.

Rows become eligible for deletion after 90 days by a best-effort
daily sweep (not a maximum age — see internal/retention). `since`
filters older than the 90-day cutoff are rejected with HTTP 400.

## Query parameters

- `limit` integer
- `cursor` string
- `event_type` string[]
- `ref_type` 'monitor' | 'webhook' | 'recipient' | 'apikey'
- `ref_id` integer
- `since` string, date-time
- `until` string, date-time

## Response `200`

Paginated audit event list.

- AccountEventList
  - `events` AccountEvent[]
    - `id` integer
    - `account_id` integer
    - `event_type` 'monitor.created' | 'monitor.updated' | 'monitor.deleted' | 'webhook.created' | 'webhook.updated' | 'webhook.deleted' | 'recipient.created' | 'recipient.updated' | 'recipient.deleted' | 'recipient.confirmed' | 'recipient.unsubscribed' | 'monitor.recipients_set' | 'apikey.created' | 'apikey.rotated' | 'apikey.deleted' | 'account.suspended' | 'account.unsuspended' | 'account.notification_email_changed' | 'account.email_cap_hit' | 'account.member_role_changed' | 'account.member_removed' | 'account.invite_created' | 'account.invite_revoked' | 'account.invite_accepted' | 'monitor.status_page_enabled' | 'monitor.status_page_disabled' | 'account.identity_linked' | 'account.github_email_skipped'
    - `ref_type` 'monitor' | 'webhook' | 'recipient' | 'apikey' | 'null', nullable: Identifies the kind of entity `ref_id` refers to. Null for account-level events that have no associated entity.
    - `ref_id` integer, nullable: ID of the entity the event refers to. Null for account-level events.
    - `payload` object: Event-specific context. Shape varies per `event_type`; see the table in SPEC §Account Events for the contract. `account.identity_linked`'s payload is `{provider, user_id}` for a Google link, an explicit GitHub link, or a first GitHub sign-in merged into an existing user (issue #390) — in all three cases `provider` is `"google"` or `"github"` unambiguously. For an adopted email address (issue #390, GitHub-verified-email adoption) the payload is `{provider: "email", source: "github", user_id}` — `source` is optional, present only on a GitHub-sourced write, and useful only within the 90-day `account_events` retention window, not as durable provenance. An explicit `POST /api/v1/me/identities/email/verify` link writes the two-field form (`{provider: "email", user_id}`, no `source`), same as every historical row written before issue #390.
    - `created_at` string, date-time
    - `actor` string: Who or what caused this event (issue #323, team accounts B1): `"user:<id>"`, `"api-key:<id>@account:<accountID>"`, `"system"` for dispatcher-internal writes (e.g. auto-suspension from the port-scan heuristic or DNS-rebinding detection), or `"legacy"` for a row written by a pre-#323 binary with no actor columns at all. See `internal/audit.RenderActor`.
  - `next_cursor` string, nullable: Opaque base64url cursor for the next page, or null if this was the last page. Pass back verbatim as `?cursor=` on the next request — the value is URL-safe; clients must NOT percent-encode it.

## Other responses

- `400`: Invalid request.
- `401`: Missing or invalid credentials.
- `403`: Account is currently suspended. On `POST /api/v1/monitors`, and on a `PUT /api/v1/monitors/{monitorID}` that changes `url` or `type` (issue #335), this can also be returned by the per-account port-scan heuristic when the triggering request crossed the port-fan threshold inside the sliding window (10 minutes by default; `SCAN_WINDOW`). A host-fan trip does NOT suspend the account — see the 429 response instead.
- `429`: Per-account dispatcher rate limit exceeded (200 requests/minute). The `Retry-After` header gives the integer seconds until at least one token has refilled. The `X-RateLimit-*` trio reflects the bucket whose rejection produced this response — usually the global 200/min cap; on `POST /api/v1/monitors` a 429 may instead reflect the per-route 20/min creation limit.

---

[API](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api.md) · [All operations](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/llms.txt) · [OpenAPI document](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/revisions/ddcb2a8bc70f?raw)