feat: June 2026 newsletter

src/website/blog/2025-08-29-why-we-run-the-oai-track.md

@@ -0,0 +1,27 @@
+Summer is nearly over in the northern hemisphere, we are three-quarters of the way through 2025, and already we’ve had great attendance at our OpenAPI Initiative (OAI) Track at Apidays New York, Helsinki, Munich, and DeveloperWeek San Francisco. We still have [API:World Santa Clara](https://www.openapis.org/events/apiworld-santa-clara-2025), and Apidays [London](https://www.openapis.org/events/apidays-london-2025), and [Paris](https://www.openapis.org/events/apidays-paris-2025) to come, with our dedicated stage and all day track at API:World!
+
+With all these events past and planned, it seems like a good time to take stock and restate why we do the OAI Track.
+
+### Community Engagement
+
+The first “why” seems pretty obvious. The Specifications that fall under the OAI banner - OpenAPI, Arazzo, and Overlay - lead the API community in providing standardized, interoperable foundations for building and consuming APIs. The OAI Track gives us a forum to connect directly with the global community, strengthen collaboration across industries, and create a shared understanding of the role open standards play in shaping the API economy. It is also a space where newcomers to the community can learn, ask questions, and find ways to get involved.
+
+### Showcasing OpenAPI
+
+The OAI Track also attracts some great speakers, with an increasing number of sessions covering the intersection between AI and OpenAPI. APIs being the bedrock of successful AI-strategies and repeatable AI outcomes, with well-described APIs being the most usable in AI applications and use cases in their current form. The narrative on OpenAPI in the AI world is still being written, with many success stories of how organizations are embracing AI in creating, consuming, and using API descriptions created in OpenAPI. The first release of Arazzo has also coincided with new protocols like Model Context Protocol, which in itself demonstrates the need for describing API-based workflows for both humans and machines, which Arazzo natively provides.
+
+The OAI Track gives us a platform to highlight not just the specifications themselves, but the wide variety of real-world implementations, case studies, best practices, and emerging opportunities. This is a chance for practitioners to share lessons learned, for tool builders to demonstrate innovation, and for the wider community to see the tangible impact of the OAI specifications in action.
+
+### Creating a Feedback Loop
+
+Just as important as showcasing is listening. The OAI Track creates a structured opportunity for direct feedback from the developer and practitioner communities. We learn insights on where the specifications are helping, where they could be clearer, and what gaps remain. This feedback goes to the heart of the development efforts, with specification contributors like [Frank Kilcommins](https://www.linkedin.com/in/frank-kilcommins/) and [Lorna Mitchell](https://www.linkedin.com/in/lornajane/) regularly leading or presenting at the OAI Track.
+
+By turning this feedback into tangible improvements in our specifications the OAI ensures that specifications evolve in a way that reflects the needs of the people who depend on them most. Hearing from the community directly is vital to evolving the OAI Specifications in a way that meets the needs of the people who depend on it most.
+
+### What’s Next for the OAI Track
+
+The OAI Track will continue to grow with this very successful format being taken forward into 2026. We are also holding breakfast sessions at Apidays London and Paris specifically focused on what it means to be an OAI member, and how we are changing our membership in the future.
+
+Hope to see you at the OAI Track soon!
+
+Contributors: [Erik Wilde](https://www.linkedin.com/in/erikwilde/), [Frank Kilcommins](https://www.linkedin.com/in/frank-kilcommins/), [Chris Wood](https://www.linkedin.com/in/sensiblewood).

src/website/blog/2025-09-22-introducing-v320.md

@@ -0,0 +1,92 @@
+We are delighted and proud to announce the release of v3.2.0 of the OpenAPI Specification!
+
+Our latest minor version brings a host of new features across a number of areas including supported HTTP methods, a new tag structure, support for streaming media types, and a whole lot more!
+
+Here's a quick rundown of the headline features.
+
+### Multipurpose Tags with Nesting
+
+One of the most significant changes, particularly for rendering a graphical view of an OpenAPI description, is the change to the [Tags](https://spec.openapis.org/oas/v3.2.0.html#tag-object) object. The new Tag Object structure introduces `summary` for short descriptions, `parent` for nesting, and `kind` for classifying Tags, allow a taxonomy to be developed, supported by a [registry](https://spec.openapis.org/registry/tag-kind/index.html) of commonly supported values.
+
+`kind` is useful because it allows tooling to selectively include and ignore Tags when parsing an OpenAPI description, as shown in the example below.
+
+```yaml
+tags:
+  # Only used for rendering
+
+  - name: products
+    summary: Products
+    description: All product operations
+    kind: nav
+
+  - name: books
+    summary: Books & Literature
+    description: Book catalog and recommendations
+    parent: products
+    kind: nav
+
+  # Used for grouping Badge related operations in generated code
+
+  - name: digital-delivery
+    summary: Digital Delivery
+    description: Instantly delivered digital products
+    kind: badge
+```
+
+Tags can therefore be created for different purposes, making the structure of the Tag Object much more flexible.
+
+As you migrate to v3.2.0, be sure to contribute to the Kind registry to share useful Tags across the community!
+
+### HTTP Method Changes
+
+v3.2.0 also includes a number of new features for more advanced HTTP method support.
+
+Firstly, the new version offers built-in support for the `query` HTTP method. `query` provides support for safely querying the state of a resource in an idempotent way using a **query payload**. You can therefore define more complex query terms in your OpenAPI descriptions, with support from Schema Objects, with a separation from `post` methods that you might have used in the past for such operations.
+
+Support for other HTTP methods that are not first-class citizens in OpenAPI is now provided by the `additionalOperations`. You can define a Map of HTTP methods you choose to include in your API design, and that can be processed by tooling, that are implemented as standard Operation Objects:
+
+```yaml
+paths:
+  /:
+    additionalOperations:
+      connect:
+        operationId:
+          ## A standard Operation Object
+```
+
+The other major enhancement is the introduction of `querystring`, which provides the means to define all query parameters as a Schema Object, allowing for greater control in defining how query parameters are defined and coexist in a given API operation.
+
+### Sequential and Streaming Data
+
+A welcome addition in this version of OpenAPI is increased support for streaming data, which is a critical enhancement to support creating well-described APIs across so many use cases, including chat, AI, IoT, and financial services.
+
+OpenAPI now supports the following types:
+
+- **Server-Sent Events**: `text/event-stream`
+- **JSON Lines**: `application/jsonl`
+- **JSON Sequences**: `application/json-seq`
+- **Multipart Mixed**: `multipart/mixed`
+
+These types work in tandem with the `itemSchema` keyword, which defines what a streamed event looks like over the wire. The addition of this support is a significant enhancement for both understanding streaming APIs **and** for tooling makers who typically need to ingest many different data structures, represented by many Schema Objects, through a single Operation.
+
+### New Security Features
+
+There are also a number of new features in Security.
+
+v3.2.0 introduces support for OAuth 2.0 Device Authorization Flow. [Device Authorization Flow](https://datatracker.ietf.org/doc/html/rfc8628) is an OAuth profile that supports End User authorization on limited input devices - think smart TVs and kiosks - and therefore requires a specialized flow to cater for handoff to an input device. Given the proliferation of such limited input devices providing support for Device Authorization Flow is a real boost for API Providers bringing their APIs to broadcasting platforms.
+
+The core OAuth Flow object has also been enhanced to include the `oauth2MetadataUrl` property, which defines a URL at which [OAuth 2.0 Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414) can be retrieved, supporting OAuth flows. Providing links to metadata, in the same way as the OpenID property `openIdConnectUrl` allows an OpenAPI description to be a key reference point for API Consumers, providing both functional and security information. Such reference points are particularly important in sectors like open finance, which rely heavily on publishing OAuth and OpenID Connect metadata for automatic discovery of services.
+
+### Other Features
+
+We've only covered some headline changes here, in an effort to bring together the most impactful changes in this release.
+
+For more details please review:
+
+- The Specification [page](https://spec.openapis.org/oas/v3.2.0.html) for v3.2.0.
+- The [Release Notes](https://github.com/OAI/OpenAPI-Specification/releases/tag/3.2.0) on GitHub, which provides a headline list of all changes.
+- Our Learn site, where you'll find a [migration guide](https://learn.openapis.org/upgrading/v3.1-to-v3.2.html).
+
+As ever, our thanks and appreciation go to our great community members who worked so hard to bring this version together! Special thanks go to [Henry Andrews](https://github.com/handrews) and [Lorna Mitchell](https://www.linkedin.com/in/lornajane/) for their significant contributions to this effort!
+
+Contributors: [Lorna Mitchell](https://www.linkedin.com/in/lornajane/), [Chris Wood](https://www.linkedin.com/in/sensiblewood/)

src/website/blog/2025-09-29-jentic-member-profile.md

@@ -0,0 +1,63 @@
+We are pleased to welcome Jentic to the OpenAPI family! [Jentic](https://jentic.com/) joined the OpenAPI Initiative in early 2025, and is building the bridge between the AI World and the API World, providing agents with targeted, repeatable, and efficient workflows. Jentic agents are built on OpenAPI and Arazzo, making these specifications crucial building blocks in the Jentic platform.
+
+We talked with [Erik Wilde](https://www.linkedin.com/in/erikwilde/), Head of Enterprise Strategy for Jentic and, of course, OAI Ambassador and lead for the OAI Track!
+
+_Thank you Erik for taking the time to talk to us!_
+
+### Please tell us a bit about your organization and your needs as an API provider in publishing well-described APIs.
+
+Jentic is using APIs in two ways: The first is by building on existing APIs and providing a layer of workflows on top of these APIs which can be used by agents. This allows agents to use targeted, repeatable, and efficient workflows. The second way of using APIs is by exposing the workflows themselves as APIs, so that they can be used throughout the entire organization like any other API.
+
+### What is the most important factor in your decision to become an OpenAPI Initiative member?
+
+Jentic uses OAI’s open standards as the very core of our platform. Like so many other organizations, we need those standards to be robust, and we need a healthy ecosystem to be in place to maintain and evolve these standards. For Jentic, supporting OAI means to support the very foundation that our business is built on, and it also means to support the growing ecosystem of API users out there who need OAI to be successful with their API and AI initiatives.
+
+### How would you like to see the OpenAPI Specification evolve in the future?
+
+For now, OpenAPI itself is established and very stable, and while we look forward to OpenAPI 3.2 and beyond, OpenAPI itself is a great foundation as it is. Our focus is a bit more on Arazzo, but I guess that’s covered in the next question…
+
+### Do you use Arazzo, and if so how important is Arazzo’s development in expanding how APIs are described?
+
+For us, Arazzo is less expanding how APIs are described, but more expanding the space which is covered by open standards. We see it as an extremely relevant and powerful addition to the API space. Ideally, we would like to see Arazzo extending beyond orchestrating OpenAPI APIs. We know that AsyncAPI is in the pipeline, and it would be interesting to look beyond that and explore how Arazzo can pull in as many APIs as possible, regardless of how they are described.
+
+### Do you use Overlay, and if so how important is creating standardized automation languages for OpenAPI descriptions?
+
+So far, Jentic is not using Overlay, but we are looking at it and are excited by its possibilities. One area that we are looking at is applying overlays to Arazzo: Since we describe our workflows in Arazzo, it could be interesting to support different views of these workflows, in the same way as Overlay supports different views of an OpenAPI-described API.
+
+### If you could have one feature included in future versions of the OpenAPI Specification what would it be and why?
+
+Since APIs will be increasingly consumed by AI, directly or indirectly, it would be great to see OpenAPI supporting the needs of this class of consumers a little bit better. This does not necessarily mean that any new functionality is needed, it may just be that the richness of the descriptions could be improved for AI consumers. Currently, nobody exactly knows what this could look like, but it would be great to see this class of consumers being considered in updates to the specification.
+
+### What role do the OpenAPI Initiative specifications play in the evolution of APIs and AI?
+
+OAI and OpenAPI play essential roles in the evolution of APIs and AI. The entire API is bigger than just OAI’s specifications, but their market share is big enough that any progress or lack thereof has a notable impact of how the API space evolves. When it comes to AI and specifically AI agents, APIs play an absolutely critical role: AI Agents must be able to gather input and perform actions, and without APIs, this is impossible. Many of the APIs that AI agents are using will be described in OpenAPI, which makes it obvious how critical the role of OAI’s specifications is.
+
+### Any final thoughts that provide insights on how you use OpenAPI that you feel is of interest to the community?
+
+We firmly believe in the power of standards. They provide a shared model and terminology, and they create a rich ecosystem of practices and tooling. Using open specifications as your source of truth, and focusing on the quality of the descriptions that you create, will become more important than ever. The API space, which has been around for a little longer, and the newer AI space will grow closer and closer, and using standards as the connective fabric is the winning strategy in the increasingly complex digital world that we are living in.
+
+---
+
+### Joining the OpenAPI Initiative
+
+Want to become a member of the OpenAPI Initiative? Find more information [here](https://www.openapis.org/membershipjoin).
+
+While you think about it, please checkout these resources:
+
+- [How to contribute guide](https://www.openapis.org/participate/how-to-contribute).
+- Our Specifications [homepage](https://spec.openapis.org/), with the latest versions of [OpenAPI](https://spec.openapis.org/oas/), [Arazzo](https://spec.openapis.org/arazzo/), and [Overlay](https://spec.openapis.org/overlay/).
+- OpenAPI Initiative on [GitHub](https://github.com/OAI), where we develop our specifications.
+
+### About the OpenAPI Initiative
+
+The OpenAPI Initiative was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor-neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software.
+
+The OpenAPI Initiative has grown to a multi-specification that, first and foremost, provides the OpenAPI Specification, the most popular API description language available to API providers and consumers. The OpenAPI Initiative also supports the development of the Arazzo Specification, which caters for complex workflows invoking many APIs, and the Overlay Specification which provides the means to deterministically and reliably update an OpenAPI description through automation.
+
+To learn what OpenAPI can do for you please visit our [What is OpenAPI page](https://www.openapis.org/what-is-openapi).
+
+### About Linux Foundation
+
+Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at the [Linux Foundation homepage](https://linuxfoundation.org).
+
+Contributors: [Erik Wilde](https://www.linkedin.com/in/erikwilde/), [Chris Wood](https://www.linkedin.com/in/sensiblewood/)