The Stops Along The API Lifecycle That Postman Services

I’m currently processing the common Postman use cases, and overlaying what the platform offers in context of historically what I’ve called my API lifecycle research. I plan on brining my vision more in alignment with Postman’s approach because I want to be telling consistent API lifecycle stories across API Evangelist and Postman, but also have things be in sync when I”m out speaking in public. I spent some time going through the Postman website and application and documented all of the stops along the API lifecycle they service, and then I took that and mapped it to the vocabulary I’ve been using to describe these areas as part of my own API lifecycle research. Providing me with a bulleted list of stops, not in any particular order, but demonstrating for me the scope of the impact Postman is making right now.

  • Definitions - Postman imports RAML, WADL, Swagger, and OpenAPI while also investing in their own API definition format called Postman Collections. (Postman) (API Evangelist)
  • Versioning - Via collections, Postman provides you with tooling for versioning your APIs. (Postman) (API Evangelist)
  • Collaboration - The killer feature of Postman is all about collaborating with your team around well defined API collections. (Postman)
  • Environment - You can define different environments with variables for use across different collections by teams.(Postman)
  • Examples - You can save API request responses as examples and publish them as part of API documentation. (Postman)
  • Search - Pro and enterprise users lets you search across collections, folders, requests, and responses.(Postman) (API Evangelist)
  • Sync - You can sync your Postman activity across accounts, devices, and Git repositories. (Postman)
  • Sharing - You can share collections using Postman in several ways, focusing on wide collaboration through the API lifecycle. (Postman)
  • Workspaces - You can define different workspaces where you collaborate with teams to define API activity across platforms. (Postman)
  • Marketplace - You can publish your APIs to the Postman Network, providing a marketplace of interesting APIs (Postman)
  • Templates - The ability to publish a specific type of collection as a template for other consumers to use. (Postman)
  • Button - There is a Run in Postman button embeddable code, as well as a link for running any single collection. (Postman)
  • Forking - You can fork collections allowing you to efficiently evolve definitions for APIs. (Postman)
  • Merging - You can also merge collections, helping better organize and manage many similar or common API definitions. (Postman)
  • Workflows - Allows you to sequence the execution of collections and have them run in any order that you define. (Postman)
  • Teams - With Pro and Enterprise you can build out, manage, and collaborate with teams using the application, API, and CLI. (Postman)
  • Roles - You can define roles for users within each of the Postman workplaces, controlling who has access. (Postman)
  • Permissions - You can define granular permissions across users and workspaces defining what they have access to. (Postman)
  • Notifications - Postman allows you to setup and configure notifications to be sent for important events across the platform. (Postman)
  • Canary - Being the first in line to get access to new API and application features from a platform as part of canary or beta program. (Postman)
  • Browsers - With Postman Interceptor you can reverse engineer APIs within the browser, mapping out the APIs you are using in real-time. (Postman) (API Evangelist)
  • API - Of course Postman has an API, allowing you to programmatically access and orchestrate across the Postman platform. (Postman)
  • Runners - Runners allow you to take any single, or group of API collections and run them one time or on a schedule. (Postman)
  • Virtualization - Generates a mock server from a collection, allowing each collection to return example responses to consumers. (Postman) (API Evangelist)
  • Monitoring - Postman monitoring lets you run a collection periodically to check for its performance and response. (Postman) (API Evangelist)
  • Testing - With Postman you can write and run tests for each request using JavaScript. (Postman) (API Evangelist)
  • Validation - You can validate API requests using pre-request scripts ensuring API requests are properly formed. (Postman)
  • Automation - Postman can automate many types of tests including unit tests, functional tests, integration tests, end-to-end tests, regression tests, and mock tests. (Postman)
  • Documentation - You can automatically generate documentation from collection, providing accurate up to date documentation for APIs. (Postman) (API Evangelist)
  • SDKs - Postman allows you to generate code snippets in a variety of programming languages from Postman Collections. (Postman) (API Evangelist)
  • CLI - You can integrate Postman into any application and CI/CD process using Newman CLI tooling. (Postman)
  • Scripts - You can define pre and post request scripts that will be executed against folders and individual requests within a collection. (Postman)
  • GraphQL - Postman supports GraphQL query requests, extending the reach of each individual collection and resulting request. (Postman) (API Evangelist)
  • Visualizations - Postman provides a programmable way to visually represent HTTP responses. (Postman) (API Evangelist)
  • Security - Postman as an organization and a platform addresses security in a variety of ways. (Postman) (API Evangelist)
  • Encryption - You can manage SSL certificates as part of Postman settings for use across API requests. (Postman) (API Evangelist)
  • Authentication - Postman supports all the common ways to authorize and authenticate with APIs as part of requests. (Postman) (API Evangelist)
  • Audit - You can audit activity across teams and collections within enterprise versions of the application. (Postman)
  • Commenting - Collaborate with your team members by allowing you to post comments on collections and requests. (Postman)
  • History - You can always view your history of activity around API requests. (Postman)
  • Integrations - Postman provides a variety of integrations with other API driven platforms for easy automation and orchestration. (Postman) (API Evangelist)
  • Backups - You can backup your collections to Git repositories, leverage GitHub, GitLab, and Bitbucket backups. (Postman) (API Evangelist)
  • Contracts - Postman brings together the right number of stops along the lifecycle to begin delivering in the area of API contracts.
  • Observability - Postman monitoring, testing, audit, and other stops along the lifecycle put observability into the process. (API Evangelist)
  • Governance - There are several areas of the API lifecycle coming together within the Postman ecosystem to enable governance. (API Evangelist)
  • Certification -  Postman is SOC 2 certified, and provides a variety of other certifications to help ensure platform reliability. (Postman) (API Evangelist)

I am sure there will be other dots I connect between what Postman delivers and my API research, but this gives me a good checklist to be thinking about when it comes to the overlap in my world(s). I’m going to be bringing more of my storytelling into sync with their blue print use cases methodology, but no doubt I will also be influencing how we evolve these API lifecycle blue prints to match what I’ve been seeing over the last nine years, but more importantly, the realities on the ground within the Postman ecosystem. This is why I am doing all of this work. I want to use the resulting common vocabulary to describe what is actually happening on the ground at companies, institutions, organizations, and government agencies. I don’t want Postman or API Evangelist to be defining the API lifecycle, I want us to be responding to what we are seeing on the ground, and helping establish a common vocabulary for describing what we are seeing.

This list represents why I joined Postman. It is the most coherent snapshot of what I’ve been calling API lifecycle tooling and Postman has been calling an API development environment (ADP). It is the most coherent vision I’m seeing when it comes to delivering across multiple stops along the API lifecycle out of an API service provider. However, more importantly, Postman is a Swiss army knife of API lifecycle capabilities that can be implemented by developers in the trenches. My mission is to help map out how API providers and consumers are using Postman across their teams. I’m looking to help create API blueprints of the common patterns I’m seeing, and make it dead simple to apply only what developers desire and nothing more. Making the API lifecycle a buffet of things that COULD happen, but it is up to developer to decide how, when, and why they are putting Postman to work.