feat: June 2026 newsletter

.prettierrc.json

@@ -1,7 +1,10 @@
 {
   "overrides": [
     {
-      "files": ["*.md"],
+      "files": [
+        "*.md",
+        "*.html"
+      ],
       "options": {
         "proseWrap": "always"
       }

.yarnrc.yml

@@ -0,0 +1,4 @@
+approvedGitRepositories:
+  - "**"
+
+enableScripts: true

package.json

@@ -1,11 +1,11 @@
 {
-  "name": "Outreach",
+  "name": "outreach",
   "version": "1.0.0",
   "main": "index.js",
   "repository": "git@github.com:OAI/Outreach.git",
-  "author": "Chris Wood <chris@arborcomputing.com>",
   "license": "UNLICENSED",
   "scripts": {
-    "convert:markdown:html": "./bin/pandoc-wrapper.sh markdown html"
-  }
+    "convert:markdown": "./scripts/pandoc-wrapper.sh"
+  },
+  "packageManager": "yarn@4.14.1+sha512.64df448055b2d37ba269d7db535a469b8da93f8ef1140c25fd7a83c00a8fbaacb214ca0e02553b92a2c54cef78bb67d0b4817fab02001df0e24fac0faccc3b42"
 }

scripts/pandoc-wrapper.sh

@@ -0,0 +1,67 @@
+#!/bin/bash
+
+# Check if pandoc is installed
+if ! command -v pandoc &> /dev/null; then
+    echo "Error: pandoc is not installed" >&2
+    exit 1
+fi
+
+# Check arguments
+STDOUT=false
+if [ "$3" = "--stdout" ]; then
+    STDOUT=true
+fi
+
+if [ $# -lt 2 ] || [ $# -gt 3 ] || { [ $# -eq 3 ] && [ "$3" != "--stdout" ]; }; then
+    echo "Usage: $0 <source_filename> <target_format> [--stdout]" >&2
+    exit 1
+fi
+
+SOURCE_FILE="$1"
+TARGET_FORMAT="$2"
+
+# Check if source file exists
+if [ ! -f "$SOURCE_FILE" ]; then
+    echo "Error: Source file '$SOURCE_FILE' does not exist" >&2
+    exit 1
+fi
+
+if [ "$STDOUT" = true ]; then
+    # Run pandoc, stripping the first H1 heading, outputting to stdout
+    awk '/^# / && !found { found=1; next } { print }' "$SOURCE_FILE" | pandoc -t "$TARGET_FORMAT" --wrap=none
+    if [ $? -ne 0 ]; then
+        echo "Error: pandoc conversion failed" >&2
+        exit 1
+    fi
+else
+    # Create build directory if it doesn't exist
+    mkdir -p build
+
+    # Get filename without path and extension
+    BASENAME=$(basename "$SOURCE_FILE" | sed 's/\.[^.]*$//')
+
+    # Determine output extension based on target format
+    case "$TARGET_FORMAT" in
+        html) EXT="html" ;;
+        pdf) EXT="pdf" ;;
+        docx) EXT="docx" ;;
+        markdown|md) EXT="md" ;;
+        latex|tex) EXT="tex" ;;
+        rst) EXT="rst" ;;
+        epub) EXT="epub" ;;
+        odt) EXT="odt" ;;
+        *) EXT="$TARGET_FORMAT" ;;
+    esac
+
+    OUTPUT_FILE="build/${BASENAME}.${EXT}"
+
+    # Run pandoc, stripping the first H1 heading from the input
+    awk '/^# / && !found { found=1; next } { print }' "$SOURCE_FILE" | pandoc -o "$OUTPUT_FILE" --wrap=none
+
+    if [ $? -eq 0 ]; then
+        echo "Successfully converted '$SOURCE_FILE' to '$OUTPUT_FILE'"
+    else
+        echo "Error: pandoc conversion failed" >&2
+        exit 1
+    fi
+fi

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/)