Skip to main content
CodeAlchemy
OpenAPI

OpenAPI in 2026: Overlay 1.1, Moonwalk SIG, FAPI/AuthZEN, and agent-ready APIs

CodeAlchemy Team··7 min read

Source: OpenAPI Initiative newsletter

OpenAPI

The OpenAPI Initiative's February 2026 newsletter is the kind of issue that's worth reading even if you wouldn't normally subscribe to a community newsletter. It ties together threads that have been moving independently — overlays, security verticals, the Moonwalk SIG's work on agent-ready descriptions — and signals where OpenAPI is heading as LLM-shaped API consumers become a meaningful share of the audience.

Use this issue as a reading list — it's news, not a normative spec change by itself.

TL;DR

  • Overlay 1.1 is shipping (covered in detail in its own post).
  • Moonwalk SIG is exploring how OpenAPI should evolve for LLM agents — capability discovery, intent signaling, operation grouping.
  • Security verticals — FAPI (open banking) and AuthZEN profiles are being formalized.
  • Industry Standards SIG coordinates with vertical groups.
  • AI Readiness Scorecard — a community initiative to benchmark how interpretable an API description is for AI consumers.
  • Events — OpenAPI Summit at DeveloperWeek San Jose; ongoing Apidays / FOST partnership.

Agent-ready descriptions: the Moonwalk SIG

The Moonwalk SIG is the OpenAPI Initiative's working group for the next generation of the specification — what eventually lands as OpenAPI 4. February's newsletter calls out a specific direction: making documents more useful to LLM agents.

Three threads inside that direction:

  • Capability discovery. When an autonomous client lands on an API, the document should tell it what the API can do at a higher level than per-operation. "This API can manage billing for a SaaS account" is a different (and more useful) signal than "GET /subscriptions, POST /subscriptions, …".
  • Intent signaling. Operations should carry semantic markers — "this is a read", "this is a paginated list", "this is a bulk write" — that let agents reason about cost, idempotency, and side effects.
  • Operation grouping. Workflows often span multiple operations. Documents should let API authors describe these workflows so agents don't have to infer them from prose.

The OAI points readers to sig-moonwalk discussion #219 for scope. Worth a read if your team owns an external-facing API and is starting to see traffic from AI clients.

Security roadmap

The newsletter signals continued engagement with security verticals:

  • FAPI (Financial-grade API). The IETF / OpenID Foundation profile common in open banking. Future OpenAPI features may make it easier to declare FAPI compliance directly in a document, replacing the current pattern of vendor-specific extensions.
  • AuthZEN profiles. The OpenID AuthZEN working group is standardizing authorization protocols beyond OAuth. OpenAPI's security scheme objects need to grow to cover them.
  • Industry Standards SIG. A cross-cutting group that coordinates between OpenAPI and vertical industry bodies (banking, healthcare, telecom). The model is that OpenAPI provides a stable description format, and verticals contribute domain-specific extensions or profiles.

For teams in regulated industries, the takeaway is that OpenAPI is taking the verticals seriously — not as one-off patches but as ongoing collaboration.

Ecosystem voice: Frank Kilcommins on AI readiness

The newsletter quotes Frank Kilcommins (Jentic, Arazzo co-author) on the AI Readiness Scorecard — a community effort to score how well an API description supports AI consumers:

"AI systems don't just scan API descriptions; they must interpret, reason, and act on them reliably," notes Frank Kilcommins. "The scorecard provides concrete benchmarks and rich diagnostics on score breakdowns, so you know where you are and what investments will return the most reward."

The scorecard rates documents on dimensions like:

  • Operation summaries and descriptions quality.
  • Schema completeness — every input/output is fully typed.
  • Examples that an agent can use to learn patterns.
  • Error documentation — every operation lists the errors it can return.
  • Workflow context — operations that compose are documented as compositions.

For teams shipping public APIs, running the scorecard is becoming a useful supplement to traditional API quality checks (linting, contract tests, generated SDKs).

Arazzo: workflow descriptions

Worth flagging because it appears in the newsletter context: Arazzo is a sister specification to OpenAPI that describes workflows — multi-step interactions across one or more APIs. Where OpenAPI tells you what each operation does, Arazzo tells you how operations compose:

arazzo: 1.0.0
workflows:
  - workflowId: place-order
    steps:
      - stepId: create-cart
        operationId: createCart
      - stepId: add-items
        operationId: addItemToCart
        parameters:
          - name: cartId
            in: path
            value: $steps.create-cart.outputs.cartId
      - stepId: checkout
        operationId: checkout

Arazzo is exactly the kind of artifact LLM agents need to plan a multi-step interaction without inferring it from prose. Expect it to feature heavily in Moonwalk's roadmap.

Events: where the work happens

The newsletter highlights two events:

  • OpenAPI Summit at DeveloperWeek San Jose — annual touchpoint for spec maintainers, vendors, and large API operators.
  • Apidays and FOST partnership — ongoing co-located content at the broader API community conferences.

Conference talks from these events tend to be where new SIG directions get socialized before they show up in formal proposals. If you're operating an API at scale, sending one engineer to one of these conferences a year usually pays off.

Things this newsletter is **not**

A few clarifications in case you're trying to decide whether to read it carefully:

  • Not a spec release. This is editorial content, not a normative document. Spec changes are versioned and published separately (3.2 in September 2025, Overlay 1.1 in early 2026).
  • Not a complete roadmap. Future work is described loosely; concrete proposals appear as RFCs in the relevant SIG repositories.
  • Not vendor-locked. The OAI is genuinely vendor-neutral; the newsletter quotes contributors from many companies.

Suggested reading after this

How to participate in the OAI

If the directions in this newsletter resonate with where your team is investing, the OAI welcomes contributors at several levels:

  • Read the SIG repos. sig-moonwalk, the Industry Standards SIG, and the Tooling SIG all post their meeting notes publicly. Reading the notes is the lowest-effort way to track where the spec is heading.
  • Comment on RFCs. Major changes go through formal RFCs in the OpenAPI-Specification repo. Even short comments ("this would help us with the following use case") help maintainers calibrate priority.
  • Show up to working-group calls. Meetings are open and recorded. The OAI calendar lists times and Zoom links.
  • Sponsor work. OAI accepts sponsorship from organizations that benefit from a stable, vendor-neutral spec. Several major API platforms sponsor at the Foundation level.

The community is genuinely welcoming to new contributors. If you've been frustrated by an edge case in OpenAPI for years, the people who can fix it are the same people you'll meet at one of the SIG calls.

What to read between newsletters

The newsletter cadence is roughly every two months. Between issues, the most active sources are:

  • The `OpenAPI-Specification` repo discussions. Where most concrete proposals get refined.
  • The Apidays YouTube channel. Conference talks from major vendors, often previewing direction before it lands in formal proposals.
  • `@OpenApiSpec` on social. Quick announcements of new releases and SIG meetings.
  • The Tooling SIG meeting notes. Where vendor representatives discuss what they're shipping next.

Subscribing to one of these is enough to stay current; the newsletter exists for people who want a quarterly digest rather than a real-time feed.

References

Source / further reading: OpenAPI Initiative newsletter