---
title: "Änderungsanfrage zu einer Status-Seite anlegen"
description: "Bittet die Organisation um eine Änderung an einer Status-Seite oder darum, eine self_service-Seite zu übernehmen. Lesezugriff genügt."
---

`POST /api/status-pages/:id/change-requests`

Lesezugriff auf die Status-Seite genügt: Organisationsrollen `admin`, `editor` und `readonly`, Kundennutzer (auch mit der Rolle `readonly`) und API-Tokens, jeweils in ihrem Kundenbereich. Der typische Aufrufer ist ein Kundennutzer, der eine `managed`-Seite nicht ändern darf (siehe [Wer eine Status-Seite ändern darf](/de/api/status-pages)) und die Organisation stattdessen um eine Änderung bittet. Mit `kind: request_managed` bittet ein Kunde die Organisation, eine `self_service`-Seite zu übernehmen.

Die Anfrage landet im selben Posteingang wie die Änderungsanfragen zu Monitoren: [Change Requests auflisten](/de/api/change-requests/list-change-requests) liefert sie mit `monitorType: "status_page"`, `monitorId` = ID der Status-Seite und `monitorName` = Name der Seite, und [Change Request auflösen](/de/api/change-requests/resolve-change-request) nimmt sie an oder lehnt sie ab. Wird eine Anfrage `request_managed` angenommen, steht die Seite danach auf `managementType: managed`.

## Pfad-Parameter

| Parameter | Beschreibung |
|---|---|
| `id` | ID oder `publicId` (UUID) der Status-Seite |

## Request-Body

| Feld | Typ | Pflicht | Standard | Beschreibung |
|------|-----|---------|----------|--------------|
| `kind` | string | Nein | `change` | `change` (Freitext-Wunsch) oder `request_managed` (die Organisation bitten, die Seite zu übernehmen) |
| `message` | string | Ja | - | Der Anfragetext (1 bis 2000 Zeichen) |

## Beispiel (cURL)

```bash
BASE_URL="https://uptimeify.io"
TOKEN="<dein-api-token>"

curl -X POST "$BASE_URL/api/status-pages/db58058e-4b58-4d97-a314-3bb8e279a182/change-requests" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "change",
    "message": "Bitte die neue Checkout-API als Komponente aufnehmen."
  }'
```

## Antwort

`201 Created`

```json
{
  "id": 14,
  "status": "open"
}
```

Offene Anfragen sind auf **10 je Kunde** begrenzt, über alle Arten hinweg (Monitore und Status-Seiten).

## Häufige Fehler

- `400 Bad Request` (`invalidRequestBody`), wenn `kind` weder `change` noch `request_managed` ist oder `message` leer oder länger als 2000 Zeichen ist
- `400 Bad Request` (`statusPageHasNoCustomer`), wenn die Seite keinen Kunden hat (`customerId: null`): Es gibt keinen Kunden, der fragen könnte, deshalb nimmt eine solche Seite keine Änderungsanfragen an
- `400 Invalid Status page identifier`, wenn `id` weder eine numerische ID noch eine UUID ist
- `401 Unauthorized`, wenn du nicht angemeldet bist
- `403 Forbidden` (`forbidden`), wenn deine Rolle keine Status-Seiten lesen darf, die Seite zu einem Kunden außerhalb deines Bereichs gehört oder ein kundengebundener Aufrufer eine Seite ohne Kunde nennt
- `403 Forbidden` (`authorizingUserUnresolved`), wenn der Aufruf über eine Agenten-Sitzung kommt, deren autorisierender Mensch nicht mehr auflösbar ist. Jede Anfrage hält die Person fest, die gefragt hat, deshalb entsteht keine Anfrage. Autorisiere die Verbindung neu oder stelle die Anfrage aus einer Sitzung, die zu einer Person gehört.
- `403 Forbidden` (`statusPagesModuleDisabled`), wenn das Statusseiten-Modul für deine Organisation nicht aktiv ist
- `404 Status page not found`, wenn es keine Status-Seite mit dieser ID gibt (ohne `data.code`), oder (`statusPageNotFound`), wenn sie zu einer anderen Organisation gehört
- `429 Too many open requests` (`tooManyOpenRequests`), wenn der Kunde schon 10 offene Anfragen hat
