HttpMethod enum omits PATCH, but Devices API returns PATCH in HAL hints.allow

[fletcher-arklink]

Description

The Management API OpenAPI specification defines the shared HttpMethod
schema without PATCH:

HttpMethod:
  type: string
  enum:
    - DELETE
    - GET
    - POST
    - PUT

However, the Devices API returns PATCH inside the HAL link metadata for
GET /api/v1/devices.

This causes clients generated from the OpenAPI specification to reject an
otherwise valid device response.

Endpoint

GET /api/v1/devices?expand=userSummary

Observed in an Okta Identity Engine org on July 28, 2026.

Relevant response fragment

{
"id": "guo...",
"_links": {
"self": {
"href": "https://example.okta.com/api/v1/devices/guo...",
"hints": {
"allow": ["GET", "PATCH", "PUT"]
}
}
}
}

Actual behavior

Code generated from the current specification models
_links.*.hints.allow as an array of HttpMethod.

Deserializing the response fails because PATCH is not included in the
allowed enum values. For example, an OpenAPI-generated Go client returns an
error equivalent to:

PATCH is not a valid HttpMethod

The relevant schema is components.schemas.HttpMethod in:

dist/current/management-oneOfInheritance-noExamples.yaml

The specification contains PATCH operations elsewhere, but the shared
HttpMethod enum used by HrefHints.allow does not include it.

Expected behavior

Responses returned by the documented Devices API should deserialize using
models generated from the published OpenAPI specification.

Suggested fix

Add PATCH to components.schemas.HttpMethod:

  HttpMethod:
    type: string
    enum:
      - DELETE
      - GET
      - PATCH
      - POST
      - PUT

Please apply the correction to all generated variants of the current
Management API specification.

[daniel-arklink]

+1, I'm also experiencing this issue