Can OpenAPI 3.1 Express Retry Semantics for POST Endpoints?

Current Gap in Retry Modeling

The OpenAPI 3.1 specification does not provide a native construct for describing retry behavior. Developers traditionally rely on HTTP status codes, Retry-After headers, and idempotency keys to convey retry safety, but these mechanisms are not formally captured in the spec.

Vendor‑Specific Workarounds

In practice, many teams annotate endpoints with extensions such as x-retry or x-idempotency. While these annotations can be useful, they lack standardization, leading to inconsistent interpretations across tooling and clients.

Unresolved Decision Point

The core question remains: should OpenAPI introduce a formal retry model—perhaps as a new component under components—to define retry limits, backoff strategies, and duplicate‑write prevention, or should the community continue to rely on ad‑hoc extensions and best‑practice documentation?

Which approach to modeling retry safety should be adopted in the core spec to preserve interoperability?

Can a standardized retry component coexist with existing idempotency key conventions without breaking current tooling?

What impact would a formal retry extension have on client expectations and data integrity?