Version dates

• PrPr 2026-10-06 now also applies to POST /v1/monitors and DELETE /v1/monitors/{id} (it previously applied only to GET /v1/monitors/{id}). On POST, the versioned request takes Monitor-CreateRequest and returns Monitor-Resource. On DELETE, the versioned behavior checks before removing anything and returns 400 for a composite monitor, 403 when the caller can view but not edit the monitor or an app manages it, and 409 when a composite monitor is built on it. Both are alpha and return 403 until the account is enabled; callers without the header keep the stable default request and behavior.

Breaking changes

• POST /v1/monitors operation identifier renamed from createMonitor to CreateMonitor. Generated clients may rename the corresponding method; raw HTTP callers are unaffected.
• DELETE /v1/monitors/{id} operation identifier renamed from deleteMonitor to DeleteMonitor. Generated clients may rename the corresponding method; raw HTTP callers are unaffected.
• POST /v1/monitors request and 201 response are now documented as Monitor-CreateRequest and Monitor-Resource, and the MonitorV2 and MonitorV2Health schemas were removed from the spec. The default (no-header) request and response bodies on the wire do not change. Generated clients lose the MonitorV2 model and their create method now types the body as the versioned shape, so code that builds a MonitorV2 for create needs to change. This breaks generated clients only, not the wire contract.
• DELETE /v1/monitors/{id} path parameter id is now modeled as a string with format: int64 instead of an integer. The URL value remains textual on the wire, but generated clients may need to change the parameter type.

Deprecations

None.

Migration

1. Regenerate generated clients and update the create and delete calls:

- created := client.createMonitor(monitorV2)
+ created := client.CreateMonitor(createRequest)   // Monitor-CreateRequest
- client.deleteMonitor(41000123)
+ client.DeleteMonitor("41000123")

2. If you create monitors through a generated client and want to keep the default request shape, send the request without the generated model: build the JSON body yourself (same body as before) and post it with the raw HTTP client, or pin your generated client to the previous spec until you move to Monitor-CreateRequest. The server accepts the unchanged default body as long as no Observe-Api-Version header is sent.

3. Opt into the versioned create and delete only after the account is enabled:

Observe-Api-Version: 2026-10-06

A 403 means the account has not been enabled yet; retry without the header to use the stable behavior. With the versioned DELETE, handle 409 (remove the monitor from the composites named in the message first) and 400 (the monitor is a composite monitor, which this endpoint does not delete).

Raw HTTP callers who do not send the header and do not depend on generated model names or typed parameter signatures do not need to change code.