---
title: "Get the authenticated account"
method: GET
path: "/api/v1/account"
tags: ["Account"]
---

# Get the authenticated account

`GET /api/v1/account`

## Request

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

## Response `200`

Account

- Account
  - `id` integer
  - `github_id` integer: GitHub numeric ID of the account's owner. Since issue #311, sourced from `users.github_id` via the account's owner membership (`account_members`), not a column on `accounts` itself — display-only, never an authorization input. `0` for an owner whose identity is email-only (issue #315) rather than GitHub — never `null`.
  - `github_username` string: GitHub username of the account's owner, sourced the same way as github_id. `""` (empty string) for an email-only owner — never `null`.
  - `email` string, nullable: Any verified email identity held by the account's owner — either the address behind an email-identity sign-in (issue #315, sign-in part A) or one GitHub reported as verified and primary, adopted onto the owner's `users` row on a sign-in that found none on file yet (issue #390) — sourced from `users.email` via the account's owner membership, the same way github_id/github_username are. `null` when the owner holds no verified email of either kind. Display-only, never an authorization input; never present on any public, unauthenticated surface (`GET /feed/{token}`, `GET /feed/{token}/rss`). Omitted entirely (issue #323, team accounts B1) unless the authenticated caller's OWN role is `owner` (issue #325: an account can have more than one owner, so this is no longer "caller is THE owner") — a viewer or member on the same account never sees it, regardless of whether the account's (earliest) owner has adopted an email of either kind.
  - `notification_email` string, nullable
  - `role` 'viewer' | 'member' | 'owner': The AUTHENTICATED CALLER's own authority on this account (issue #323, team accounts B1) — not a property of the account itself. Always present. The SPA uses this to hide owner/member-only controls.
  - `is_admin` boolean: True when the authenticated account is in the admins table — i.e. the same answer auth.RequireAdmin returns for any admin-gated route. Always present on GET /api/v1/account and on the PATCH /api/v1/account success response.
  - `last_cap_hit_at` string, date-time, nullable: Timestamp of the latest successfully recorded POST /api/v1/monitors (or MCP create_monitor) rejection for hitting the per-account hard cap (100 monitors) — not a guaranteed latest-refusal timestamp. Updates are coalesced to at most once per account per minute, and a failure to record a hit is swallowed (the REST 409 or MCP tool-error result the client sees is unaffected either way), so a refusal can occur without advancing this field, and null does not prove the account has never been refused. Advisory only — the app uses it to time an upgrade offer; never cleared once set.
  - `silent_monitors` integer: Count of ENABLED monitors on this account with no ACTIVE attached recipient (issue #212). "Active" excludes a disabled recipient and a still-unconfirmed (`pending`) email recipient (issue #321) — a monitor whose only attached recipient is pending or disabled is counted as silent, the same as one with no attached recipient at all. Disabling a monitor removes it from this count — a disabled, unreachable monitor is not flagged as silent since it is not being checked. Present on both `GET` and `PATCH /api/v1/account`.
  - `created_at` string, date-time
  - `updated_at` string, date-time

## Other responses

- `401`: Unauthorized
- `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)