---
title: "Create API key"
method: POST
path: "/api/v1/keys"
tags: ["Keys"]
---

# Create API key

`POST /api/v1/keys`

## Request

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

Creates a new API key. The plaintext key is returned **once** in the `key`
field — it cannot be retrieved again. Max 10 keys per account.

## Request body

- object
  - `label` string: Optional human-readable label for the key. Trimmed of surrounding whitespace before persistence. Must be 3..100 characters after trimming, or omitted entirely.

## Response `201`

Key created. The `key` field contains the plaintext (shown once).

- APIKeyCreated: API key with the one-time plaintext included.
  - `id` integer
  - `account_id` integer
  - `key_prefix` string
  - `label` string, nullable
  - `revoked_at` string, date-time, nullable
  - `created_at` string, date-time
  - `key` string: Full plaintext API key. **Shown once** — store it securely.

## 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.
- `409`: Account has reached the 10-key limit.
- `413`: Request body exceeds the 64 KB hard limit. Per docs/SPEC.md §Hard Limits the dispatcher rejects any payload larger than 65,536 bytes before it is decoded.
- `415`: The request `Content-Type` is not `application/json`. Write operations (POST, PUT, PATCH) require that header; a missing or non-JSON media type is rejected before the body is read. The `charset` parameter is accepted and ignored, so `application/json; charset=utf-8` is valid.
- `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.
- `500`: Two distinct failure shapes share this status, distinguishable by the `error` body: 1. **Generic pre-persistence failure** — key material generation or an unclassified store error before any commit was attempted. Body: `{"error": "internal error"}`. No key was written; safe to retry. 2. **Commit outcome unknown** (e.g. a connection drop mid-commit) — the message names the candidate key's ID and prefix; a key with that ID/prefix may or may not have been created. A `GET /api/v1/keys` that doesn't show it is not proof it was never created (a commit can become visible moments after a read on another connection), and this stays true even after waiting and listing again: negative reads remain inconclusive. Do not automatically create another key. If the candidate does appear and another usable key already exists, revoke the candidate directly; if it is the account's only key, authenticate via a dashboard session (not the withheld candidate) to create and verify a replacement first — `DELETE /api/v1/keys/{keyID}` refuses to remove an account's last key regardless of whether its plaintext was ever received.

---

[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)