<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>OpenAPI on API Coding</title>
    <link>https://apicoding.com/tags/openapi/</link>
    <description>Recent content in OpenAPI on API Coding</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 20 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://apicoding.com/tags/openapi/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Five SDK Generators Compared: Speakeasy, Stainless, Fern, APIMatic, and OpenAPI Generator</title>
      <link>https://apicoding.com/2026/04/20/five-sdk-generators-compared-speakeasy-stainless-fern-apimatic-and-openapi-generator/</link>
      <pubDate>Mon, 20 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/2026/04/20/five-sdk-generators-compared-speakeasy-stainless-fern-apimatic-and-openapi-generator/</guid>
      <description>&lt;p&gt;Speakeasy has published a head-to-head comparison of the five most widely deployed SDK generators for OpenAPI specifications, covering Speakeasy itself alongside Stainless, Fern, APIMatic, and the open-source OpenAPI Generator. The evaluation spans language coverage, runtime type safety, dependency footprint, OpenAPI fidelity, enterprise feature sets, and deployment flexibility — the criteria that now determine whether an SDK generator clears enterprise procurement rather than just developer preference.&lt;/p&gt;&#xA;&lt;p&gt;SDK generators have moved from convenience tooling to infrastructure. API-first companies, including those building for AI agent integrations, now treat generated client libraries as a production artifact, and the differences between generators surface in SOC 2 audits and supply chain reviews rather than only in developer experience surveys.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OpenAPI Has Won. Here Is What That Actually Means for Your API.</title>
      <link>https://apicoding.com/2025/12/01/openapi-has-won.-here-is-what-that-actually-means-for-your-api./</link>
      <pubDate>Mon, 01 Dec 2025 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/2025/12/01/openapi-has-won.-here-is-what-that-actually-means-for-your-api./</guid>
      <description>&lt;p&gt;The API specification format wars ended without a formal declaration of victory. RAML, API Blueprint, WSDL, and a half-dozen proprietary formats all had moments of advocacy and adoption. OpenAPI — originally released as Swagger by Wordnik, donated to the Linux Foundation, and renamed — outlasted them through a combination of tooling ecosystem depth, industry adoption breadth, and the practical network effects that come from being the format that most developers encounter first.&lt;/p&gt;</description>
    </item>
    <item>
      <title>API Documentation That Developers Actually Use</title>
      <link>https://apicoding.com/2025/11/03/api-documentation-that-developers-actually-use/</link>
      <pubDate>Mon, 03 Nov 2025 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/2025/11/03/api-documentation-that-developers-actually-use/</guid>
      <description>&lt;p&gt;API documentation is where most APIs fail their consumers silently. The API itself may be well-designed, reliable, and feature-complete. If the documentation is incomplete, inaccurate, or organized without regard for how developers approach integration tasks, the API will generate support tickets, incorrect integrations, and the quiet abandonment of developers who find a better-documented competitor.&lt;/p&gt;&#xA;&lt;p&gt;The documentation failures that cause the most damage are predictable: reference documentation without examples, error responses that are documented without the conditions that produce them, authentication sections that explain the mechanism but not the specific steps to obtain credentials, and code examples that work when first published and become outdated as the API evolves.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
