Latest updates and blog posts

Docs as code is a powerful methodology that aligns documentation processes with software development workflows. It treats documentation as a first-class citizen in the development lifecycle by applying a similar approach to the standard development process. Let’s explore what it is, how it works, and how you can get started.

API governance is critical for ensuring consistency, security, and quality in enterprise API programs. However, maintaining governance across a distributed organization can be challenging, especially as teams grow and APIs proliferate. In some cases, organizations opt to define guidelines rather than API governance in an attempt to reduce the work required day-to-day.

It all started with a PR on OpenAI’s open-source repository.

When I started as a Product Manager, I felt like a great integration between SaaS products would involve some UI elements. Something like buttons with the other tool’s logo on it. Then I realized the importance of “APIs” behind the scene, whether there would be a button or not.

APIs are at the core of modern enterprise architectures, powering integrations, automation, and digital products. Yet, API sprawl remains a persistent challenge—APIs are often scattered across different teams, tools, and repositories, making discovery and governance difficult.

Whether just starting to build an API and looking for feedback, or improving auditing an old API to see if it’s secure, consistent, and up to scratch, the approach is likely the same: API linting.

API Design-First, also known as “schema-first” or “contract-first”, is all about designing the interface of an API before writing any code. It’s about planning the API contract first, and defining what the API does and how it works so everyone’s on the same page before implementation starts. This approach has been around for a while, and over time, it’s evolved to meet the needs of different technologies. These days, OpenAPI has become the defacto standard for designing REST APIs, and AsyncAPI has become the defacto standard for describing event-driven APIs. This workflow can make life easier for everyone the whole way through the lifecycle of an API.

It’s been a while since we chatted with the Speakeasy folks. What’s more natural? Bump.sh and Speakeasy are the first two vendors ever to officially support OpenAPI Overlays.

As for each year, we’ve learned a lot in 2024.

At Bump.sh, we’re excited to announce a new feature we have been developing: The API Explorer, a web-based UI designed to help users send HTTP requests to documented APIs directly from their browser. While this tool offers enhanced usability, it also posed several unique challenges, especially around ensuring user privacy and compliance with CORS (Cross-Origin Resource Sharing) restrictions. This blog post takes a look at our approach and how we ended up creating an open-source proxy solution called cors-toujours.

A bit more than two months ago, we’ve released the very first OpenAPI cheat sheet. Ever. We were really proud.

This article explains how Bump.sh and Microcks can be used in tandem to establish a natural cycle of documentation, simulation (a.k.a mocking) and testing.

Partner APIs are far more common than public-facing APIs. Yet, inaccessible documentation for these APIs is often a big barrier to partner success. In fact, nearly 40% of developers say inconsistent docs are their biggest roadblock when it comes to API integration, found the 2024 State of the API Report. Pain points around API documentation can cause miscommunications, errors, and time delays.

Gathering user feedback is essential to improving your API and ensuring it meets users’ needs. With Bump.sh, you can integrate feedback forms directly into your OpenAPI documentation by embedding a link to a form using x-feedbackLink extension.

If you’ve worked with OpenAPI v3.x, you might have come across the discriminator field in schemas. It’s often used alongside oneOf, anyOf, or allOf when you’ve got different variations of a type—polymorphism, essentially. At first glance, it seems pretty handy; it’s meant to help you figure out which specific schema to use when certain values are present, but JSON Schema can handle this out of the box without using the poorly supported OpenAPI-only keyword discriminator.

You are building an API for a reason. You need to integrate with another business to make money. You need to get data to a new frontend application to get more users to make money. You have important business to do, so why should you waste time creating API documentation?

In the world of software development, an API contract plays a vital role in ensuring systems, teams, and machines can interact effectively.

APIs have become an essential part of software architecture and partner integrations. Many organizations today are shifting to a digital product mindset when designing and delivering APIs. As such, the importance of well-crafted API documentation cannot be overstated. At the heart of this crucial task is the technical writer, whose role extends far beyond writing documentation to include the full API design and development lifecycle. Let’s find out how technical writers can be a significant part of the API design process and how organizations should prepare to involve them throughout the API lifecycle.