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, 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 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 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, 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, 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, Kateryna Poryvay, Saurabh Rai

Joining the OpenAPI Initiative

Want to become a member of the OpenAPI Initiative? Find more information here.

While you think about it, please checkout these resources:

• How to contribute guide.
• Our Specifications homepage, with the latest versions of OpenAPI, Arazzo, and Overlay.
• OpenAPI Initiative on GitHub, 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.

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.

We are pleased to welcome Jentic to the OpenAPI family! Jentic 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, 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.

While you think about it, please checkout these resources:

• How to contribute guide.
• Our Specifications homepage, with the latest versions of OpenAPI, Arazzo, and Overlay.
• OpenAPI Initiative on GitHub, 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.

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.

Contributors: Erik Wilde, Chris Wood

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 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 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.

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:

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 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 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 for v3.2.0.
• The Release Notes on GitHub, which provides a headline list of all changes.
• Our Learn site, where you’ll find a migration guide.

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 and Lorna Mitchell for their significant contributions to this effort!

Contributors: Lorna Mitchell, Chris Wood

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, and Apidays London, and Paris to come this year, 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 and Lorna Mitchell 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, Frank Kilcommins, Chris Wood.

Welcome to our December 2024 newsletter, the final OpenAPI Initiative roundup of the year! Our newsletter brings you initiative news, details of new versions of our specifications, and information on events and educational resources.

Initiative News

In 2024 the OpenAPI Initiative (OAI) grew from one specification to three, with two new specifications added.

In May Arazzo version 1.0 was released. If you’ve not heard of Arazzo, it is a description language for describing sequences of API calls, and supports passing of dynamic data between steps. Arazzo is an attempt for API providers to help describe such sequences in an increasingly complex API-driven world, in order to reduce onboarding time for developers implementing flows and reduce cost and complexity.

October also saw the release of the Overlay Specification at version 1.0. Overlay is a specification for describing updates to an OpenAPI description document in a consistent, deterministic way. Overlay helps API providers update their OpenAPI descriptions through the API lifecycle, and supports building pipelines for API descriptions, supporting automation. Overlay and automation can help organizations manage the publication of their OpenAPI descriptions more accurately, with increased quality, at lower cost.

Finally the OpenAPI Specification was also uplifted to versions 3.0.4 and 3.1.1. Being patch releases these releases did not introduce new features, but sought to clarify features of the 3.0 and 3.1 specifications with a significant amount of new and revised supporting guidance added to the specifications. Updates include extensive guidance on modeling parameters, headers, and form data, handling URL percent-encoding, parsing documents and resolving references, and choosing which fields to use for examples. The specification now also link to the extension registries, the JSON Schema for OpenAPI Description documents, and the Learn OpenAPI site.

Looking ahead to 2025 there are already plans afoot for new versions of the OpenAPI Specification.

At the end of 2023 we announced project Moonwalk with an ambitious goal of shipping a major release by the end of 2024. While v4.0 of the OpenAPI Specification is still some way off, we have learned a great deal and are now planning v3.2 and v3.3 as incremental steps towards v4.0 that will be fully backwards-compatible with v3.1.

Version 3.2 is intended to deliver a small set of new features quickly in 2025. Two of these features, (hierarchical, categorizable tags and self-identifying documents, which take much of the pain out of external references) emerged from the Moonwalk effort. While the scope will no doubt evolve, other features under consideration include streaming JSON formats, additional HTTP methods, device authorization flow, and links to OAuth authorization server metadata. This sounds like a lot, but aside from the changes with tags, most of these features are straightforward.

Work on v3.3 will start immediately after 3.2, and will deliver bigger ideas from Moonwalk. Two areas under consideration – a major streamlining of parameter, header, and form data modeling, and expanded OpenID Connect features – were 3.2 proposals that could not be done quickly. A v3.3 release, which has no date at this time, lets us take incorporate more Moonwalk ideas to solve these problems thoroughly.

As for v4.0 itself, the Moonwalk effort motivated us to understand how the OAS is implemented, and how to ensure that the specification truly represents the needs of the community. Henry Andrews summarizes this introspection in his blog, where he lays out an idealized architecture. Moonwalk will continue to progress in 2025.

The work on new specifications and specification releases, the increased adoption of 3.1, and the significant interest in Arazzo and Overlay all bodes well for another busy year in 2025. You can read more about OAI moving from one to three specifications and plans for next year in our blog post covering the changes in the initiative and what will come next in our evolution.

Events

2024 was another great year for events, with our continued partnership with apidays plus an appearance at the JAX Mainz Conference. The OAI track appeared at apidays Singapore, New York, Helsinki, London, Australia, and finally Paris, with a huge array of different talks ranging from introductions to Arazzo, views on how OpenAPI helps with API governance, and the role of OpenAPI in the geospatial ecosystem. The range of talks, together with generally packed conference rooms, are indicators of both the health and interest in the OpenAPI ecosystem, and in the strategic value of openness and open standards in general.

Looking ahead to 2025, we already have an OAI-supported event in the train at DeveloperWeek, where Erik Wilde and Frank Kilcommins will be hosting the first OAI track of the year. Our OAI tracks have been features of apidays for the last two years, but DeveloperWeek brings the OAI to a large conference audience that is not dedicated to APIs. Broadening our reach and gaining the interest of communities outside the immediate API space will help widen the opportunity to attract new members who already use the OpenAPI Specification without even knowing it.

Outside the OAI tracks we also have TSC member Lorna Mitchell presenting at FOSDEM 2025 with an overview of the aforementioned expansion of OAI into three specifications. If you are planning or have a talk lined up on any aspect of OAI in 2025, let us know! We’d be happy to include it in the newsletter.

One other initiative we have started this year is our OpenAPI Hangouts, where members of the OAI community come together to discuss aspects of the specifications in a webinar style format, broadcast on LinkedIn and YouTube. We plan to expand these in 2025, covering more topics and engaging with more community members.

Education and Training

We’ve also taken steps in 2024 in education and training, with some improvements and new initiatives designed to help the understanding of our specifications in the community.

Our Learning site continues to develop, with valuable resources for explaining OpenAPI in a narrative format. The site includes great resources that include a detailed walkthrough of references, examples of OpenAPI descriptions sourced from the community, and details from new specifications like Overlay.

Alongside our learning site, in 2024 we also created our OpenAPI Fundamentals course, an online training course provided at Linux Foundation Training to increase awareness of the background, basic structure, and approaches to using the OpenAPI Specification. The course is available for free and provides a badge of completion.

We’ve also provided a number of in-person training courses, first at the Nordic APIs Platform Summit and then at apidays Paris. While participation in terms of number of attendees for these courses was mixed, they represented an important step in allowing us to investigate how we can better support the community for training and learning. We’ll continue to look for opportunities to support the community through in-person training in 2025, starting with a full-day workshop about “Practical API Management with OpenAPI” at DeveloperWeek in February 2025.

Finally

That’s it for this newsletter, and 2024! We’ve achieved so much this year, and that is down to our great teams of volunteers who support the development of our standards. Thank you so much to our community and all the contributors who bring our specifications to life. Happy holidays everyone!

As ever, we welcome suggestions on how we can improve this newsletter or bring you information that can help make the most of how you use specifications published by the OpenAPI Initiative. We are also looking for ways to highlight OpenAPI Initiative member contributions to the community. Please get in touch on the Outreach channel on Slack if you would like to work with us to tell your story.

Contributors: Chris Wood, Henry Andrews, Erik Wilde, Jeremy Fiel