---
title: "Create Status Page Change Request"
description: "Asks the organization for a change to a status page, or to take a self_service page over. Read access is enough."
---

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

Read access to the status page is enough: organization roles `admin`, `editor` and `readonly`, customer users (also with the role `readonly`) and API tokens, each within their customer scope. The typical caller is a customer user who may not change a `managed` page (see [Who may change a status page](/api/status-pages#who-may-change-a-status-page)) and asks the organization for a change instead. With `kind: request_managed` a customer asks the organization to take a `self_service` page over.

The request lands in the same inbox as monitor change requests: [List Change Requests](/api/change-requests/list-change-requests) returns it with `monitorType: "status_page"`, `monitorId` = the status page id and `monitorName` = the page name, and [Resolve Change Request](/api/change-requests/resolve-change-request) accepts or rejects it. Accepting a `request_managed` request sets the page to `managementType: managed`.

## Path parameters

| Parameter | Description |
|---|---|
| `id` | Status page ID or `publicId` (UUID) |

## Request Body

| Field | Type | Required | Default | Description |
|-------|------|----------|---------|-------------|
| `kind` | string | No | `change` | `change` (free-text wish) or `request_managed` (ask the organization to take the page over) |
| `message` | string | Yes | - | The request text (1 to 2000 characters) |

## Example (cURL)

```bash
BASE_URL="https://uptimeify.io"
TOKEN="<your-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": "Please add the new checkout API as a component."
  }'
```

## Response

`201 Created`

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

Open requests are limited to **10 per customer** across all types (monitors and status pages).

## Common errors

- `400 Bad Request` (`invalidRequestBody`) when `kind` is not `change` or `request_managed`, or `message` is empty or longer than 2000 characters
- `400 Bad Request` (`statusPageHasNoCustomer`) when the page has no customer (`customerId: null`): there is no customer who could ask, so such a page takes no change requests
- `400 Invalid Status page identifier` when `id` is neither a numeric ID nor a UUID
- `401 Unauthorized` when you are not logged in
- `403 Forbidden` (`forbidden`) when your role may not read status pages, the page belongs to a customer outside your scope, or a customer-bound caller names a page without a customer
- `403 Forbidden` (`authorizingUserUnresolved`) when the call arrives over an agent session whose authorizing human can no longer be resolved. Every request records the person who asked, so no request is created. Re-authorize the connection, or open the request from a session that belongs to a person.
- `403 Forbidden` (`statusPagesModuleDisabled`) when the status pages module is not active for your organization
- `404 Status page not found` when no status page has that ID (no `data.code`), or (`statusPageNotFound`) when it belongs to another organization
- `429 Too many open requests` (`tooManyOpenRequests`) when the customer already has 10 open requests