diff --git a/src/website/blog/2025-08-29-why-we-run-the-oai-track.md b/src/website/blog/2025-08-29-why-we-run-the-oai-track.md new file mode 100644 index 0000000..efa192d --- /dev/null +++ b/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). diff --git a/src/website/blog/2025-09-22-introducing-v320.md b/src/website/blog/2025-09-22-introducing-v320.md new file mode 100644 index 0000000..05d627f --- /dev/null +++ b/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/) diff --git a/src/website/blog/2025-09-29-jentic-member-profile.md b/src/website/blog/2025-09-29-jentic-member-profile.md new file mode 100644 index 0000000..5559877 --- /dev/null +++ b/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/) diff --git a/src/website/blog/2025-10-01-september-newsletter.md b/src/website/blog/2025-10-01-september-newsletter.md new file mode 100644 index 0000000..7ade057 --- /dev/null +++ b/src/website/blog/2025-10-01-september-newsletter.md @@ -0,0 +1,71 @@ +Welcome to the OpenAPI Initiative (OAI) September 2025 newsletter! We’ve had a break over the vacation season in the northern hemisphere, but are back to bring you initiative news, information on events and educational resources, and this time round, news of our v3.2 OpenAPI release! + +### Initiative News + +It goes without saying that the big news - wait, **_enormous_** - news for this edition of the newsletter is two new releases of the OpenAPI Specification! We have a new minor release at [version 3.2.0](https://spec.openapis.org/oas/v3.2.0.html), which has helped us also deliver a patch version of 3.1 at [3.1.2](https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.2). + +#### Versions 3.2.0 Features + +Version 3.2.0 brings together a feast of new features including: + +- A brand new Tag Object structure, providing greater flexibility and richness in tagging objects. +- Support for the `QUERY` HTTP method for implementing operations searching collections, plus the new `additionalOperations` keyword that allows HTTP methods not included in the Specification to be described. +- 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. +- A new `querystring` keyword that allows all query parameters supported by an API to be described through a Schema Object. +- Security Scheme enhancements, including support for OAuth 2.0 Device Authorization Flow and OAuth 2.0 Server Metadata. + +You can read more about the enhancement in our [blog post](https://www.openapis.org/blog/2025/09/23/announcing-openapi-v3-2), which includes both links to key resources such as the release itself and our comprehensive migration guide published on our Learn site. + +Thanks go to the TSC and all contributors for this release, particularly [Henry Andrews](https://github.com/handrews) and [Lorna Mitchell](https://www.linkedin.com/in/lornajane/) for their significant contributions to getting this version over the line! + +#### Moonwalk Update + +Back at the start of the year we gave a [status update](https://www.openapis.org/blog/2025/02/05/moonwalk-2025-update) on the progress of Moonwalk: its goals, desired outcomes, and what this Special Interest Group aims to achieve. In that post we said: “_The timeline for Moonwalk reaching a 4.0.0 release remains open-ended_”, and with the release of v3.2.0 what you are actually seeing is the first incremental step of the larger Moonwalk project. Many of the features of v3.2.0 were ideated through Moonwalk, and our focus is now on delivering more backwards-compatible incremental steps in the 3.x line. We will also keep an eye out for problems that show us that we **need** to break compatibility and make a 4.0 release, but we would like to discover that need through community feedback. + +Key message is: **Don’t wait for Moonwalk**! Moonwalk is an ideas engine, and feeds the progress on the main development line of the OpenAPI Specification. It may come to pass that there is **never** a v4.0 of OpenAPI. If you were hanging on for v4.0, make the leap to v3.2 now. + +### Membership News + +We are pleased to welcome new members to the OpenAPI Initiative! + +[Jentic](https://jentic.com) joined early 2025. Jentic 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. You can read more in our [interview](https://www.openapis.org/blog/2025/09/26/the-openapi-initiative-welcomes-jentic) with [Erik Wilde](https://www.linkedin.com/in/erikwilde/), who as well as being OAI Ambassador is also Head of Enterprise Strategy at Jentic. + +We have also been joined in September by [Apideck](https://www.apideck.com/). Apideck is a Unified API provider, with an API that seeks to simplify integration across different SAAS platforms through one simple integration. [Gertjan De Wilde](https://www.linkedin.com/in/gertjandewilde/) describes their motivation for joining as being _“..time to stand behind the spec that has enabled us to build our company.”_, which is of course fantastic news, and a great motivation for anyone looking for anyone thinking about becoming a member. We are looking forward to bringing you our new member profile on Apideck very soon! + +If you are interested in membership we have held two breakfasts at Apidays (New York and London), where we introduce what membership means and take a look at the revised member benefits we are looking to offer. If you want to find out more, please check out our recent post on [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7378728523152388096), which includes our presentation from this event. + +### Events News + +We have been busy with OAI Track since our last newsletter as event season has picked up again. + +[API:World](https://www.openapis.org/events/apiworld-santa-clara-2025) was held in Santa Clara in September, where we were lucky enough to host our own OpenAPI Summit. Organized and hosted by Erik Wilde and [Frank Kilcommins](https://www.linkedin.com/in/frank-kilcommins), the conference kicked off with a workshop held by Erik and Frank that looked at best practices for leveraging OpenAPI and Arazzo when scaling your APIs. This was followed by a full day programme of topics focusing on the MCP ([Emmanuel Paraskakis](https://www.linkedin.com/in/emmanuelparaskakis/)), the role of metadata in building well-connected systems ([Simon Heimler](https://www.linkedin.com/in/simonheimler/)), and building great governance for APIs ([Jeremy Glassenberg](https://www.linkedin.com/in/jglassenberg/)). + +[Apidays London](https://www.apidays.global/events/london), whilst not a Summit, still had a host of great talks including an overview of the v3.2.0 release (Lorna Mitchell) and a look at architecting agent-ready infrastructure ([Sean Blanchfield](https://www.linkedin.com/in/seanblanchfield/)). + +Last stop for this year will be [Apidays Paris](https://www.apidays.global/events/paris), the flagship Apidays event. Please keep an eye out for updates on our agenda for the OAI Track! + +Finally, we’ve started issuing digital badges for attendance at OAI events. Our first badges went to participants at our OSS Mini Summit events in Denver and Amsterdam. Be sure to lookout for events and workshops that issue badges in the future! + +### Ecosystem Spotlight + +The Ecosystem Spotlight for this edition comes from [Shane O’Connor](https://www.linkedin.com/in/shaneopenapi/), Go to Market Lead at OAI member [Scalar](https://scalar.com/). + +Shane highlights the great work Scalar are doing improving parsing time with their OpenAPI parser: + +_Scalar has released a modern OpenAPI parser that’s gaining traction for its performance and comprehensive feature set. Written in TypeScript, @scalar/openapi-parser supports OpenAPI 3.1, 3.0 and Swagger 2.0, with support for the newly released OpenAPI 3.2 specification coming very soon. The parser is already trusted by teams at Mintlify & Kong demonstrating its production readiness across diverse use cases, and offering highly significant performance improvements over existing parsers._ + +_Beyond performance, @scalar/openapi-parser offers a comprehensive utility suite including reference dereferencing with tracking callbacks, document filtering, and automatic upgrading from Swagger 2.0 to OpenAPI 3.1 (soon to be 3.2). What distinguishes this parser is its plugin architecture for handling external references. This architecture enables a crucial differentiator: the parser works seamlessly on both server-side and browser environments, unlike many alternatives that are limited to Node.js. Developers can extend it with custom plugins to fetch definitions from databases, CDNs, or any data source. The onDereference callback provides visibility into schema resolution, invaluable for debugging complex multi-file specifications._ + +_As OpenAPI documents grow in complexity and with OpenAPI 3.2 bringing new features, having a performant parser that handles everything from legacy Swagger 2.0 to the latest specification becomes critical for maintaining responsive development workflows. Scalar’s parser represents a modern solution that’s actively evolving alongside the OpenAPI specification itself._ + +If you’d like to contribute to the Ecosystem Spotlight in our next newsletter, please get in touch on the [Outreach channel](https://open-api.slack.com/archives/C0KM0KXU6) on Slack. + +### Finally + +Thank you for reading our newsletter. As always, we welcome suggestions on how we can improve it or bring you information that can help make the most of how you use specifications published by the OpenAPI Initiative. + +Please get in touch on the Outreach channel on Slack if you would like to work with us to tell your story, to feature in the Ecosystem Spotlight section, or get involved with any of the initiatives described above. We’d also like from organizations, tooling makers, or community members on their reaction to our v3.2 release, and to share any stories in their adoption journey. + +Until next time! + +Contributors: Shane O’Connor, Henry Andrews, [Chris Wood](https://www.linkedin.com/in/sensiblewood). diff --git a/src/website/blog/2025-10-16-apideck-member-profile.md b/src/website/blog/2025-10-16-apideck-member-profile.md new file mode 100644 index 0000000..70b0829 --- /dev/null +++ b/src/website/blog/2025-10-16-apideck-member-profile.md @@ -0,0 +1,71 @@ +The OpenAPI Initiative (OAI) is proud to welcome Apideck as a new member! + +Apideck is the first Unified API platform to join OAI, and their membership is reflection of their huge commitment to open source. Alongside joining OAI, Apideck also created and maintains [Portman](https://github.com/apideck-libraries/portman), an open-source library that streamlines API contract testing using OpenAPI definitions. + +We caught up with Gertjan De Wilde, Co-founder and CEO of Apideck, to find out more about their motivation for supporting OAI, where OpenAPI, Arazzo, and Overlay fit in their product and architecture, and their outlook for the future as an OAI member. + +### Please tell us a bit about your organization and your needs as an API provider in publishing well-described APIs. + +[Apideck](https://www.apideck.com/) is a Unified API platform that provides 200+ integrations across multiple categories, including Accounting, HRIS, CRM, and others. We normalize disparate APIs into consistent, predictable interfaces. As the first unified API company to join OAI, we have unique needs: we must maintain consistency across hundreds of different API providers. Well-described APIs using OpenAPI specifications are essential for us to document complex integrations in a standardized way and provide predictable interfaces that developers can trust. Our entire business model hinges on transforming diverse API implementations into a unified, coherent interface with an exceptional developer experience. + +### What is the most important factor in your decision to become an OpenAPI Initiative member? + +OpenAPI isn't just a specification for us: it's the foundation of our product architecture and business model. Every one of our 200+ unified connectors, every SDK we generate, and every validation we run starts with an OpenAPI contract. It's the backbone that made our entire business possible, and frankly, we wouldn't exist in our current form without it. + +That's why joining OAI feels like closing the loop. We've been adopters for years, building on top of this incredible standard. Now it's time to become active contributors: to give back to the ecosystem that enabled everything we've built, and to help shape how the next generation of APIs and AI agents communicate. As standards become increasingly critical in the AI agent revolution, we want to be at the table, ensuring OpenAPI evolves to meet these emerging needs. + +### How would you like to see the OpenAPI Specification evolve in the future? + +We'd like to see the specification evolve to better support API aggregation, normalization, and unification challenges. As a unified API company, we deal with the full spectrum of API quality and need specifications that can handle complex scenarios. The specification should also prioritize AI-readiness with enhanced semantic clarity about what each API operation actually does, making it easier for AI agents to understand and interact with APIs programmatically. + +### Do you use Arazzo, and if so how important is Arazzo's development in expanding how APIs are described? + +Arazzo's development for orchestrating complex multi-API workflows is particularly relevant to us as a unified API company. When you're normalizing hundreds of APIs across dozens of categories, workflow orchestration becomes critical. We're already putting Arazzo to work: using it to auto-generate tests for our SDKs across 6 languages, ensuring that our implementations handle multi-step workflows correctly and consistently. + +We see Arazzo as an important evolution in describing not just individual APIs, but how they work together in real-world integration scenarios. This matters even more in the context of AI agents, which need to chain multiple API calls together to accomplish complex tasks. Having a standard way to describe these orchestrations will be essential for both human developers and autonomous agents. + +### Do you use Overlay, and if so how important is creating standardized automation languages for OpenAPI descriptions? + +Yes, we use Overlay extensively in our SDK generation process. It's become critical for us to inject different SDK examples and generate different flavors of OpenAPI specifications tailored to our various tooling needs. When you're generating SDKs across 6 languages from a single source OpenAPI spec, having a standardized way to apply transformations and customizations is essential. + +We're also using Overlay to augment and enrich our API descriptions and documentation: layering in additional context, examples, and metadata without modifying the upstream specifications directly. This separation of concerns is invaluable when you're maintaining 200+ connector specifications that need to stay synchronized with vendor APIs while also being optimized for our unified API layer. + +For us, standardized automation languages like Overlay represent the difference between maintainable, scalable tooling and an unmaintainable mess of custom scripts. As OpenAPI becomes the lingua franca for API-first development and AI agent interactions, having robust, standardized ways to transform and augment these descriptions programmatically isn't just important: it's foundational to building reliable automation at scale. + +### If you could have one feature included in future versions of the OpenAPI Specification what would it be and why? + +It's not really a feature, but we would like to see an official OpenAPI registry comparable to the [MCP server registry](https://github.com/modelcontextprotocol/registry) recently launched. The API ecosystem desperately needs a centralized, authoritative place where developers and AI agents can discover and access OpenAPI specifications. We've actually built our own API search engine, called the [API Tracker](https://apitracker.io/), precisely because this gap exists. An official OpenAPI registry would take this further, providing verified, up-to-date specifications with quality scores, version histories, and standardized authentication patterns. Just as the MCP registry is accelerating AI integrations, an official OpenAPI registry would accelerate API adoption across the entire ecosystem. It would become the single source of truth for both human developers and AI agents looking to integrate with APIs, dramatically reducing the friction in API discovery and integration. + +### What role do the OpenAPI Initiative specifications play in the evolution of APIs and AI? + +OpenAPI is becoming the standard interface for AI agents to understand and interact with any API. Developers aren't the only ones reading API documentation anymore. AI agents need machine-readable specifications even more than humans do. They require structured, standardized descriptions to navigate authentication flows programmatically, understand what each operation does, and validate if their API calls are correct. Combined with protocols like MCP (Model Context Protocol), OpenAPI specifications enable AI assistants to not just understand but actually execute API calls in real-time. + +### Any final thoughts that provide insights on how you use OpenAPI that you feel is of interest to the community? + +We've open-sourced [Portman](https://github.com/apideck-libraries/portman), our CLI tool that converts OpenAPI specifications into Postman collections with automated contract testing. With 600+ GitHub stars and 25+ contributors, it shows how OpenAPI can be leveraged beyond documentation to create powerful testing workflows. This demonstrates our belief that open standards and open-source tools reinforce each other. Standards enable better tools, tools validate standards, and the community amplifies the impact of both. We encourage other API companies to not just adopt OpenAPI but to contribute their tools and learnings back to the ecosystem. + +_Contributors: [Gertjan De Wilde](https://www.linkedin.com/in/gertjandewilde/), [Kateryna Poryvay](https://www.linkedin.com/in/katerynaporyvay/), [Saurabh Rai](https://www.linkedin.com/in/srbhr/), [Chris Wood](https://www.linkedin.com/in/sensiblewood/)_ + +--- + +#### 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). diff --git a/src/website/blog/2026-04-09-june-2026-newsletter.md b/src/website/blog/2026-04-09-june-2026-newsletter.md new file mode 100644 index 0000000..888b62e --- /dev/null +++ b/src/website/blog/2026-04-09-june-2026-newsletter.md @@ -0,0 +1,210 @@ +--- +slug: openapi-initiative-newsletter-june-2026 +publication-date: 2026-06-09 +author: Chris Wood +--- + +# OpenAPI Initiative Newsletter – June 2026 + +Welcome to the OpenAPI Initiative (OAI) June 2026 newsletter! + +We are excited to bring all the latest specification, events, and community news +across the OpenAPI, Arazzo, and Overlay specifications and the wider community. + +### OpenAPI Specification + +The OpenAPI Specification (OAS) team is evaluating changes for v3.3, with a +number of items in scope. + +Firstly, the team is investigating a concept that we're calling "Standardized API Features", +or SAFs. As the name suggests SAFs are intended to provide a mechanism for +characterizing features of OAS according to two properties, namely: the feature has standardised +behavior defined by an external specification (such as an RFC), and it requires +an exception to the normal rules for describing API operations in OAS. Cookies +are the clearest example: their behavior is defined by RFC 6265, and they need +special treatment in OAS because the Cookie header cannot simply be described +using the standard header parameter approach. + +The SAF concept is therefore intended to help the specification community learn +from past design mistakes and reason more clearly about which API features +deserve first-class, dedicated treatment in the Specification versus those that +can be described generically. The SAF concept therefore provides significant +affordances for the development of new features in both v3.3 and all future +versions. + +Alongside and supported by the work on SAFs v3.3 promises to be one focused on +API Security, with investigations already taking place on supporting the +[FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html) +and +[Grant Negotiation and Authorization Protocol](https://datatracker.ietf.org/doc/html/rfc9635) +(GNAP) available. Discussions have already +[started](https://github.com/OAI/OpenAPI-Specification/discussions/5304) on what +a Security Profile might look like, and the work on SAF will help shape how this +is introduced. + +### Arazzo Specification + +The Arazzo Specification v1.1.0 has also been +[released](https://www.openapis.org/blog/2026/05/19/announcing-arazzo-specification-1-1). +This is a minor release built on the 1.0 foundation, with the headline addition +being AsyncAPI support. For the first time, a single Arazzo document can +describe workflows that span both synchronous HTTP operations and event-driven +asynchronous APIs. + +Other significant additions include fully supported chained workflow execution +(enabling reusable sub-workflows such as token refresh flows), a new Selector +Object for fine-grained data extraction via JSONPath, XPath, or JSON Pointer, +and alignment with OpenAPI 3.2's querystring option on the Parameter Object. The +release also tightens specification precision with a complete ABNF grammar for +runtime expressions, formally defined truthy/falsy evaluation semantics, and a +new $self field providing a canonical URI for unambiguous multi-document +referencing. + +Existing 1.0.x documents remain valid without structural changes, and the +roadmap ahead targets gRPC, GraphQL, SOAP, MCP, and A2A step types, +actor-in-loop support, transformer/function support, and loops. + +### Overlay Specification + +2026 has already seen the release of Overlay v1.1.0, which we covered in our +February newsletter. A release v1.2.0 is currently in the works, which will +implement **Reusable Actions**. + +Reusable Actions are important because they vastly increase the means for +creating Overlay actions that can be used in multiple places, both within and +across documents. As a framework for implementing automated pipelines this +feature is key, as it ensures that Overlay documents provide the full corpus of +knowledge for the pipeline. + +The release date for v1.2.0 is yet to be fixed, but we'll keep you up to date +with news on the release. + +### Getting Involved + +We want to acknowledge the efforts of our specification team members and +community in bringing these releases together. Many hours are spent in ideation, +drafting, and review, and the specifications are always on the lookout for help. + +The work on Security Profiles also shows how the involvement of experts across +the industry is tremendously important, and discussions between OAI more widely +and the FAPI Working Group have taken place. This level of community engagement +across different standards bodies is vital in helping OAS, Arazzo, and Overlay +evolve and develop to meet the needs of the ecosystem, especially in supporting +Agents and AI more generally with features that support automation and autonomy. + +If you want to get involved - either by helping with the authoring, or bringing +fresh ideas or expertise to the community - you can come and join the +specification meetings for OpenAPI, Arazzo, and Overlay on our +[Community Calendar](https://www.openapis.org/get-involved/about). If you can't +make the meetings you can also get keep in touch, ask questions, or suggest +ideas on Slack, using the +[#spec](https://open-api.slack.com/archives/C1137F8HF), +[#arazzo](https://open-api.slack.com/archives/C022K8VD7AP), and +[#overlays](https://open-api.slack.com/archives/C023Y5YJ474) channels. + +Finally, each specification is open to discussions on Github, so you can also +raise ideas or contribute there. See the +[OpenAPI](https://github.com/OAI/OpenAPI-Specification/discussions), +[Arazzo](https://github.com/OAI/Arazzo-Specification/discussions), and +[Overlay](https://github.com/OAI/Overlay-Specification/discussions) repository +discussions for more details. + +### Events News + +The OAI Track - led by [Erik Wilde](https://www.linkedin.com/in/erikwilde/) - +has continued to bring exciting and insightful sessions to conferences around +the world, with DeveloperWeek San Jose, and Apidays Singapore and New York +already complete. + +The agenda of these events was dominated by the intersection of OpenAPI and +artificial intelligence, with a consistent focus on what it means for an API to +be truly "AI-ready." Speakers like +[Emmanuel Paraskakis](https://www.linkedin.com/in/emmanuelparaskakis/) and +[Kin Lane](https://www.linkedin.com/in/kinlane/) repeatedly returned to the idea +that OpenAPI documents must evolve beyond human-readable documentation to become +machine-actionable contracts that AI agents can discover, reason over, and +execute reliably. A second strong thread was the shift toward spec-first and +API-first development practices, framing the OpenAPI description as the single +source of truth that drives design, code generation, testing, and governance. + +Workflow orchestration has also emerged as a distinct concern, with multiple +sessions led by +[Frank Kilcommins](https://www.linkedin.com/in/frank-kilcommins/) exploring how +standards like Arazzo and MCP can extend OpenAPI into the multi-step, +agent-driven interactions that modern AI systems require. Underpinning all of +this was a practical emphasis on tooling and automation and moving from from +AI-assisted API design and automated linting to SDK generation and contract +testing, reflecting an industry moving from manual API development toward highly +automated, standards-driven pipelines. + +The busy conference season continues, with +[Apidays Amsterdam](https://www.openapis.org/events/apidays-amersterdam-2026) +and [Apidays Munich](https://www.openapis.org/events/apidays-munich-2026) in +June and July respectively. We'll be continuing with the themes above, so if you +are interested in hearing more about the intersection between OpenAPI and AI, be +sure to make it to the OAI Tracks! + +### Ecosystem Spotlight - Interledger Foundation and Open Payments API + +The Interledger Foundation SDK Grant program is funding work to improve the +developer experience for the [Open Payments API](https://openpayments.dev/), +which is an open standard for payment interoperability across different +providers, rails, and ecosystems. The SDK Grant program is specifically +interested in making GNAP available in the OpenAPI Specification as a key +affordance to their developer experience goal. + +The Interledger Foundation has therefore funded three proposals that advance +both the OpenAPI and Arazzo Specifications while improving the developer +experience for the Open Payments API. + +The grantees are: + +- [Henry Andrews](https://www.linkedin.com/in/handrews/) is leading work to add + GNAP as a Security Scheme to the OpenAPI Specification, addressing a gap in + security description capabilities that matters increasingly for code + generation and AI agents. +- [Chris Wood](https://linkedin.com/in/sensiblewood) is supporting the GNAP + implementation, producing a TypeScript version for Microsoft's open-source + Kiota SDK generator, and updating OAI educational materials to reflect the new + support. +- [Vincent Biret](https://www.linkedin.com/in/vincentbiret/) is implementing + Arazzo workflow support in Kiota for C#/.NET as a reference implementation, + enabling client code to generate higher-level API workflow SDKs directly from + Arazzo documents. + +These three work streams demonstrate how OAI specifications underpin real-world +tooling investment and deliver benefits across the broader web API ecosystem. + +### Outreach + +Telling and promoting success stories from the community is a big part of what +outreach at OAI aims to achieve. We'd like to hear from you if you would like to +work with us to tell your story, to feature in the Ecosystem Spotlight section, +or get involved with any of the initiatives described above. We’d also really +like to hear from organizations, tooling makers, or community members who have +success stories to tell, so we can celebrate their successes on the blog. + +We are also actively investigating new ways of engaging with the community and +especially with OAI members, with office hours and tooling forums to address the +needs of the community more readily. + +You can in touch by: + +- Using the [#outreach](https://open-api.slack.com/archives/C0KM0KXU6) channel + on Slack. +- Emailing us at [outreach@openapis.org](mailto:outreach@openapis.org). +- Getting in touch at our + [LinkedIn page](https://www.linkedin.com/company/open-api-initiative). + +If you have something to share, be sure to get in touch! + +### Finally... + +Thank you for reading our newsletter. As always, we welcome suggestions on how +we can improve it or bring you information that can help make the most of how +you use specifications published by OAI. + +Until next time! + +Contributors: [Chris Wood](https://linkedin.com/in/sensiblewood), +[Karen Etheridge](https://github.com/karenetheridge)