July 2026 Summaries

Multi-protocol API programs are essential for achieving real scale, often requiring the integration of gRPC for internal service-to-service communication and REST for public interfaces. These programs leverage tooling markets that provide runtime transcoders to enable gRPC services to handle HTTP requests, and generation platforms that produce documentation and client libraries. The selection of tools depends on whether the goal is to unify the developer-facing outputs across both protocols, which necessitates cross-protocol generation from a single definition set. This field divides into three layers: runtime transcoding for reachability, schema conversion for bridging gRPC and REST, and generation platforms that create documentation and SDKs from multiple definition formats. Tools like Fern, Buf, and Connect operate within these layers, each offering different advantages for specific organizational needs. Fern provides comprehensive generation capabilities across multiple formats, Buf focuses on governance and breaking-change management for gRPC-heavy organizations, and Connect facilitates browser reachability without a proxy. The choice of tools should consider the compatibility and unification of definitions to ensure consistent outputs, while also addressing the nuances of protocol differences in field naming, error models, and streaming semantics.

Event-driven APIs often lack comprehensive reference documentation compared to REST APIs, with developers typically receiving an asyncapi.yaml file and a basic README. AsyncAPI documentation generators aim to fill this gap by parsing AsyncAPI documents to produce browsable reference documentation that includes channels, operations, messages, and protocol bindings. These generators vary significantly in functionality, with some also emitting client code, architecture diagrams, or maintaining versioning and change tracking through hosted sites. The shift to AsyncAPI 3.x introduces a structural change by separating operations from channels, enhancing clarity for bi-directional communication flows. However, generated documentation often omits crucial integration aspects, such as connection lifecycle and authentication processes, which require additional authored prose. Tools like Fern allow for the generation of both WebSocket API references and typed client libraries from a single AsyncAPI document, advocating for a unified documentation and client generation workflow to maintain consistency and accuracy. This approach contrasts with OpenAPI, which focuses on synchronous request-response interactions, highlighting the distinct challenges of documenting event-driven APIs.

Fern has developed an innovative approach to leveraging AI in their marketing efforts, significantly enhancing their paid advertising strategy. By using a series of Claude agents and other AI tools, Fern has managed to double their qualified demos, secure 90% of the search impression share on brand and competitor terms, and increase site traffic by 202%. This strategy involves a detailed process where campaigns are meticulously planned, executed, and reviewed in a feedback loop. Each campaign is tailored to a specific audience and angle, using custom landing pages and automated image generation to ensure brand consistency. The collaboration with media-buying partner Outshine allows Fern to focus on creative strategy while maintaining efficient ad spending. Despite these successes, the top of the funnel requires improvement, prompting the next phase to focus on awareness ads to build a retargeting pool for more effective conversions. The entire process is supported by Claude skills and a local tool that streamline campaign management, with the potential for further collaboration and sharing of this framework.

Creating and maintaining partner API documentation traditionally involves setting up a separate portal, which can lead to discrepancies and increased maintenance as it duplicates the content of the public API documentation. A more efficient approach utilizes a single API definition with audience filtering and role-based access control (RBAC) to manage visibility for public, partner, and internal users. By tagging endpoints, schemas, and properties with audience identifiers within the API specification, and using authentication methods such as JWT, OAuth, or SSO, teams can control access without forking documentation sites. This integrated method ensures that the documentation remains synchronized, reduces maintenance burdens, and allows partners to test API endpoints directly from the documentation. Platforms like Fern facilitate this by providing audience filtering and RBAC, ensuring that all content and search functions respect access controls, thereby maintaining security and consistency across documentation.

Unified REST and gRPC documentation is the practice of documenting both protocols from a single source of truth, enabling synchronized updates and a coherent developer experience. This approach addresses the challenge of different documentation systems for REST, which prioritizes broad compatibility and reach, and gRPC, which focuses on speed and strong contracts. The differences in specification formats and transport methods—OpenAPI for REST and Protocol Buffers for gRPC—often result in separate documentation. However, a unified system employs tools that accept both formats, ensuring that API references, guides, and code examples are consistent and up-to-date. By generating documentation and SDKs from the same definitions, platforms like Fern provide a seamless experience across protocols, although practical differences remain in areas such as SDK coverage and testing capabilities. Unified documentation does not mean merging the protocols but rather maintaining their distinct characteristics while ensuring they are accurately represented within a single portal.

The author describes their journey in creating background art for the Fern blog using Midjourney, a text-to-image model, to achieve a calm and polished aesthetic that aligns with the brand's identity. Initially experimenting with various styles such as "technobotanicals," surreal minimalism, and woodblock landscapes, the author found these approaches either too attention-grabbing or not fitting the desired mood. Inspiration struck during a visit to the Philadelphia Museum of Art, where the serene and muted qualities of Hiroshi Yoshida's woodblock prints resonated, leading to a breakthrough in creating backgrounds that complement rather than compete with the blog's content. By feeding Yoshida's prints into Midjourney's /describe command and refining the output with personalized elements, the author developed a template that consistently delivers cohesive imagery across different scenes and launches, such as the Rust SDK generator launch featuring crabs and the Swift launch with swifts. The process is ongoing, with each new launch providing an opportunity for further creative exploration.

Adi David's journey to joining Fern was influenced by his previous role as a forward deployed engineer at a software analytics company, where he extensively used Fern for documentation and SDKs, particularly appreciating its role-based access control (RBAC) features. His positive experiences with the product and the collaborative environment at Fern led him to take on a sales engineering role, which allowed him to continue building features and supporting customers post-sale. At Fern, he encountered challenges similar to those he'd faced as a user, such as the inability to preview role-specific views before merging documentation changes. This led him to develop a new feature that allows customers to preview their docs site under specific roles or configurations without merging PRs. His role emphasizes autonomy, allowing him to transform customer requests and his own experiences into tangible product improvements, such as adding a config option to turn off the MCP server for authenticated sites, demonstrating his proactive approach to solving real-world problems.

Insurance carriers face unique challenges when selecting an API documentation platform due to the need for compliance with regulated data, such as personally identifiable information (PII) and protected health information (PHI), and the demand for partner-specific access controls. These platforms must handle large, complex schemas in line with ACORD data standards and offer features like spec-driven reference generation, multi-language SDK support, and private deployment options to meet data residency requirements. The comparison of platforms like Fern, ReadMe, Mintlify, Stoplight, and GitBook highlights their varying capabilities, with Fern standing out for its comprehensive support of full-stack private deployment, content-level access control, and multi-language SDK generation, making it particularly suitable for the insurance industry's regulatory needs. While platforms like ReadMe and GitBook offer user-friendly interfaces and AI features, they often lack the self-hosting and access control capabilities essential for compliance-driven carriers, positioning Fern as the most aligned choice for insurance carrier API programs.

Time-to-hello-world (TTHW) is a critical metric for measuring the time it takes for enterprise partner developers to make their first successful API call, serving as an indicator of integration friction. Unlike public API onboarding, which is often straightforward, enterprise partner onboarding involves structural challenges such as credential provisioning, sandbox environment access, and compliance reviews, all of which can delay the integration process. To reduce TTHW, companies are encouraged to eliminate manual steps by generating SDKs, creating interactive documentation, and enabling self-service access from a single API definition, which allows partners to self-serve rather than rely on manual intervention. Fern exemplifies this approach by providing a streamlined path through the automatic generation of typed SDKs, interactive API references, and machine-readable outputs, which ensure accuracy and reduce onboarding time significantly. By treating onboarding as generated infrastructure, enterprise partner programs can onboard partners more efficiently, thus reducing the need for solutions engineers and accelerating time-to-market.

An API CLI generator is a tool designed to automatically produce a command-line interface from a machine-readable API description, such as an OpenAPI specification, allowing the CLI to stay synchronized with the API as it evolves. This approach offers a significant advantage over hand-written CLIs by ensuring complete and current endpoint coverage without the manual effort of updating commands whenever the API changes. The generator parses the API spec to build a model of operations, which it then maps to a command structure, producing a runnable CLI that includes authentication, structured output, pagination, retries, and help text based on the spec's descriptions. By generating CLIs, teams benefit from a scalable solution that supports both human users and AI agents, with features like JSON output and machine-readable command schemas facilitating integration into automation pipelines. Tools like Fern exemplify this by generating a CLI from the same API specification used for SDKs and documentation, ensuring all tools remain aligned with the API's source of truth.

Enterprises using GitLab self-managed within secure networks face unique challenges in selecting API documentation platforms, particularly when self-hosting is a critical requirement. While many tools offer GitLab integration, few support deployment within an enterprise's own infrastructure, which is vital for regulated or air-gapped environments. Platforms like Fern stand out by providing spec-driven documentation, SDK generation, and CLI tools from a single API definition, all while supporting self-hosted deployment and maintaining GitLab self-managed compatibility without requiring repository cloning. This approach ensures that reference documents remain synchronized with API changes and comply with security and data residency requirements. Other options like Redocly and SwaggerHub offer self-managed GitLab support and on-premises capabilities but may require additional tools for comprehensive developer experiences. Docusaurus provides flexibility through a static site model, but it necessitates manual integration for API specifications. The choice is ultimately driven by the need for a platform that integrates seamlessly with self-managed GitLab, offers complete control over deployment, and maintains documentation fidelity to the API specification.

Developers often demand command-line interfaces (CLIs) to efficiently interact with APIs, automate workflows, and integrate with CI pipelines, but manually creating and maintaining a CLI can be labor-intensive and prone to drift as APIs evolve. The key challenge lies not in argument parsing but in keeping the CLI up-to-date with the API's endpoints, parameters, and authentication schemes. This guide suggests that generating a CLI from an API specification, such as OpenAPI, is a scalable solution that ensures consistency and completeness without the manual upkeep. By leveraging tools like Fern, developers can produce a fully functional CLI that maps endpoints to commands, manages authentication, handles pagination, and formats output in both human-readable and structured JSON formats. This approach not only aligns the CLI with SDKs and documentation but also caters to both human developers and AI agents, offering a reliable and deterministic interface. The decision to hand-write a CLI or generate it depends on the API's size and frequency of change, with generation being preferred for extensive and evolving APIs to maintain synchronization and trustworthiness.

OpenAPI Generator and Fern serve as tools for generating SDKs from API specifications, but they differ significantly in their approach and offerings. OpenAPI Generator is a free, open-source tool that uses Mustache templates to generate client libraries, server stubs, and documentation across over 50 languages, emphasizing breadth and allowing for extensive customization at the cost of ongoing maintenance. In contrast, Fern is a managed platform that generates idiomatic, type-safe client libraries in nine languages and synchronizes API reference documentation, focusing on quality and ease of use by automating the package lifecycle and preserving customizations with its Replay feature. While OpenAPI Generator is suitable for teams needing extensive language coverage and self-hosted control, Fern is better suited for those prioritizing SDK quality, synchronized documentation, and reduced maintenance efforts.

Fern, a company hosting documentation for developer platforms, revamped its system to enhance performance by breaking down its documentation sites from a single, large JSON blob into smaller, content-addressed pieces. This restructuring allows for more efficient updates and faster rendering times, significantly improving from previous cold render times of 1-3 minutes to just 5-10 seconds. By identifying each piece of content by its hash and storing it in layers, the new system reduces the need to reload unchanged parts, enabling quicker publishing and resolving URL paths more efficiently. The transformation also decreased average cold load times from over 10 seconds to as low as 2.5 seconds for large sites, with customers experiencing substantial performance improvements. The transition to this new storage methodology is seamless and automatic for existing users, requiring no action or downtime, while promising to eliminate inefficiencies and enhance the user experience across the board.