A Timeline of Postman’s Journey to Become an API Platform

A common question we often hear is: what is the Postman story and how did we evolve to become the API platform that supports the entire API lifecycle? Postman began as a simple API client and debugging tool, which quickly grew into a very adaptable API testing solution, but since then has rapidly expanded to meet so many other needs of our global users across the API lifecycle. While there are plenty of other capabilities that Postman has implemented over the years, this timeline shows the core progression of Postman from a client into the current API platform you see today—and it provides a reflection of many of our more than 17 million users’ own journeys.

It all began with providing a simple API client to make developers’ lives easier:

  • 2013: Client, Scripts, and Testing
    Postman begins as a browser-based solution for testing and debugging APIs, helping developers understand how APIs work or do not work, then saving that understanding as a reusable, shareable collection that can be run by others.
  • 2014: Runner and CLI Runner
    Collections become a standardized way to define, save, and then run one or many API requests that includes scripting for automation, allowing collections to be run on the desktop or via a command-line interface and CI/CD.
  • 2015: Documentation and Code Generation
    Documentation emerges as a priority, expanding the ability for developers to publish shareable and embeddable documentation that also has a variety of code snippets in different programming languages.
  • 2016: GitHub and GitLab Integration
    Source control integration for developers becomes important, allowing Postman to be more tightly linked to the developer’s existing software development lifecycle so that artifacts and tests can be kept in alignment with source control.
  • 2016: APM, Messaging Integration
    Following source control, the need to integrate with existing APM, notification, and messaging systems becomes an important part of developers’ workflows to produce and consume APIs as part of their work.
  • 2016: Monitoring
    Being able to schedule the monitoring of collections and extend the automation introduced by runners, and at the command-line and CI/CD pipeline level, allowing contracts, performance, integration, and other tests to be monitored.
  • 2017: Mocking
    Mocking is an essential part of the API lifecycle as part of testing, so Postman introduces the ability to deploy mock servers as defined by a collection and the examples it contains providing a simple way to create static mocks of APIs.
  • 2018: Team Workspaces, Comments, and Search
    Acknowledging the need for closer collaboration across teams, workspaces are launched, as well as the ability to comment on collections, and search across workspaces, APIs, and collections.
  • 2019: Builder
    With the increased usage of Postman to not just consume and test APIs, but also to deliver APIs, the API Builder is launched, allowing APIs to be designed and developed using OpenAPI, RAML, and GraphQL across team workspaces.
  • 2019: Interceptor
    To support the reverse engineering of the existing APIs that live behind web applications, Postman Interceptor is launched to allow web traffic in Chrome to be captured and then used to define a Postman Collection within a workspace.
  • 2019: Public Network
    The Public API Network is launched to support the needs of public API producers wanting to attract new users, and it also provides a public catalog for API consumers to use when looking for APIs to use in their applications.
  • 2020: Reporting
    Reporting is launched to support the needs of larger enterprises, providing a way for leadership to see activity across teams, workspaces, and APIs so that they can move towards greater governance of API operations.
  • 2020: Private Network
    The Private API Network is launched to support the need for enterprise organizations to have a single internal catalog where teams can publish and discover the APIs and microservices that are being developed across their teams and workspaces.
  • 2020: Public Workspaces
    The ability to change the visibility of a workspace to be a public workspace is introduced to support the needs of API producers when it comes to engaging with consumers by allowing them to view, fork, and interact with their APIs.
  • 2021: Websockets Support
    The platform signals a migration towards being a multi-protocol API platform, supporting WebSockets (and then Socket.IO), and ultimately laying the groundwork for gRPC and support for other protocols.
  • 2021: New Postman API Platform
    The new Postman API Platform launches with powerful capabilities and integrations supporting today’s API-first movement, which is leading individual innovators and enterprises into the future.

This timeline represents the journey of Postman from a browser extension to a desktop application to a comprehensive API platform—all made possible by our continued commitment to listen to and support the needs of API consumers and API producers. Postman provides teams what they need when it comes to designing, developing, and operating their APIs, and also when it comes to consuming and automating using private, partner, and public APIs.

Still, this represents just a subset of the Postman API Platform capabilities as we continue to support the growing (and changing) needs of developers across the world. Additionally, these core capabilities are built to help enterprise organizations get a handle on the productivity, quality, and overall governance of their operations now and into the future.

What do you think about this topic? Tell us in a comment below.

Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 thought on “A Timeline of Postman’s Journey to Become an API Platform

    Good