API stands for application programming interface. APIs are the little pieces of code that make it possible for digital devices, software applications, and data servers to talk with each other, and they’re the essential backbone of so many services we now rely on.

Links:

• View Blueprint
• View Blog Post

Every company you think of when it comes to the online digital has APIs, with some of the most notable companies like Amazon, Facebook, Twitter, Google, Microsoft and others leading this digital expansion. Demonstrating how APIs have moved from a tech sector solution to a mainstream business solution that is touching almost every business sector today.

Links:

• View Blueprint

APIs have been behind every shift in the technological landscape during last twenty years. Commerce and payments — APIs. The social revolution introduced by Facebook and Twitter — APIs. Cloud computing — APIs. Mobile — APIs. Internet-connected devices — APIs. Machine learning — APIs. It is all APIs. If you are looking to be the one who defines the future of how business is conducted, you’ll need to be API-aware. You should care about APIs because it will play a role in defining almost every aspect of how you get business done in the next decade.

Links:

• View Blueprint
• View Blog Post

API requests are the fuel for the digital economy, reading and writing data, content, and media online across every business sector. HTTP API requests have become the common building block of web, mobile, and device applications, and understanding the technical details of individual API requests are essential to how you conduct business online today.

Links:

• View Blueprint

API-first is the prioritization of APIs over any single application or integration, developing, delivering, and reusing of API resources and capabilities beyond their uses. Establishing a better-planned foundation, that is more observable, secure, and governed, which then translates into more reliable and successful applications and integrations serving business purposes.

Links:

• View Blueprint

Discoverable, accessible, and always up-to-date API documentation is the number one paint point for API consumers, and ensuring that it is present for all APIs is fundamental to allowing team members, stakeholders, and consumers to understand what an API does, and how it can be put to work, making it a growing problem as the number of APIs continues to expand.

Links:

• View Blueprint

This is a blueprint for how to manually create a collection for an existing API, transferring details of each request from documentation to a collection, applying authentication, then continuing to explore and troubleshoot until you have a complete and documented collection for an API.

Links:

• View Blueprint

Like Repository have done for code over the last decade, API workspaces have become the essential way for not just organizing API artifacts, but also the operations needed around them to move them forward. Providing teams with a way for organizing everything you need to produce and consume APIs within a single business domain or project into a discoverable and collaborative workspace.

Links:

• View Blueprint

APIs are used to deliver resources and digital capabilities across multiple types of applications, providing what is needed to power many different web, mobile, and device applications, as well as system-to-system integration and automation. How the enterprise sees applications and integrations evolves once they begin shifting towards an API-first way of looking at operations, demonstrating how APIs are behind every digital application we depend on today.

Links:

• View Blueprint

OpenAPI is an open-source specification for describing the surface area of HTTP APIs, providing a machine-readable format for describing the details of the request and responses, establishing a contract that can be used to generate documentation, mock servers, testing, security, code generation, and other essential elements of operating APIs across operations.

Links:

• View Blueprint

Every API needs to have a complete reference collection available for consumers. Providing an always up-to-date reference of every detail of an API, what it does, and how developers can put it to use. Ensuring there is a detailed record that can be used for the documentation but then also producing other types of onboarding, capability, workflow, and other types of collections that will be needed.

Links:

• View Blueprint

A blueprint for helping jumpstart a mapping of the internal API landscape, allowing an organization to begin getting a handle on what is happening across operations. Beginning by profiling a specific group or domain, but then expanding it across operations once a portion of the landscape has been mapped and understood.

Links:

• View Blueprint

API discovery is about being able to find and see your API resources and capabilities whenever you need them, whether it is before you begin developing a new API, developing a web, mobile, or device application, and properly route traffic and deliver reliable applications and integrations. Ensuring you know where all your digital resources and capabilities are, so they can be secured and put to work as needed.

Links:

• View Blueprint

These blueprints provide an overview of API testing, outlining the moving parts of a test collection, and how scripting provides the ability to test and automate quality for each API. Providing a very universal and flexible approach to API testing that can be used across teams to ensure that there is 100% test coverage present across API operations.

Links:

• View Blueprint

This is a blueprint to standardize how workspaces are setup.

Links:

• View Blueprint

This blueprint illustrates what we consider to be the base of the API lifecycle, providing a starting point for additional lifecycle variations elsewhere on this site. Depending on your priorities and your entry point, you may need to expand or remove from this base lifecycle to match your desired situation.

Links:

• View Blueprint

This provides a blueprint for beginning the API lifecycle by designing a new API using an OpenAPI, showing one possible lifecycle from end to end. Approaching the API lifecycle in a design-first way, while ensuring all the other essential areas of the API lifecycle are present.

Links:

• View Blueprint

This is a blueprint for entering a standardized API lifecycle using a WSDL for an existing web service, acknowledging that SOAP still has its place in many enterprise Environment, but a common API lifecycle including documentation, testing, and other elements is still needed.

Links:

• View Blueprint

Test automation is essential for delivering reliable and consistent APIs at scale across the enterprise. This is a blueprint for walking through the base of how test automation can work as part of a well-defined API lifecycle, helping teams standardize how they approach testing APIs.

Links:

• View Blueprint

A blueprint for approaching the governance of APIs beginning with each individual API by individual developers, setting API governance into motion at the lowest level by a single or group of developers, acknowledging that governance will only get you so far at this level, but in many organizations, it might sense to start at this level.

Links:

• View Blueprint

Assuring quality across teams when it comes to the delivery, operation, and evolution of APIs is top of mind for any enterprise organization. Realizing quality across many different teams and the APIs they develop takes a significant amount of planning and execution to ensure that there are contract, integration, performance, security, and other types of tests in place across 100% of APIs in operation.

Links:

• View Blueprint

The security for APIs means security behind the applications and integrations that depend on them, making API security a top priority for enterprise organizations today. Security is much more than encryption and requiring keys for APIs, and there are a number of proven approaches to making sure APIs are consistently secure no matter what team is producing or consuming them, using machine-readable collections.

Links:

• View Blueprint

You just can't move forward an enterprise organization in a digital world without an API strategy. Establishing a formal, living, and evolving way of defining what your goals are with developing, operating, and evolving the API infrastructure behind the applications and integrations we depend on, and moving forward with a common strategy for how this all works across teams.

Links:

• View Blueprint

Kicking off API governance efforts by starting with versioning across APIs. Adopting a specific pattern to version all APIs, then work to govern that it is applied during the design, development, and delivery of APIs. Starting simple with API governance, establish a pattern and process, then expand API governance efforts once you have your legs under you.

Links:

• View Blueprint

When it comes to reaching a community of API consumers it takes just the right performance that informs and adds value to their world but also potentially entertains them as well. Going well beyond just marketing content and information, and providing informative, compelling, and hands-on products are essential to reaching and standing out within developer communities.

Links:

• View Blueprint

Documenting the members of a team behind APIs, and making their workspaces, APIs, collections, and other work publicly available is a potential way to bring more attention to the projects, and other work going on. Providing a more public approach to the API lifecycle that works to bring more attention to APIs, and increase the number of consumers who are putting it to work.

Links:

• View Blueprint

Very few enterprise organizations have visibility into the digital infrastructure that has emerged over the last 25 years of operating on the web. APIs have become the fundamental building block behind the web, mobile, cloud, device, and other technological evolution of the last couple of decades, and the enterprise organizations who have visibility into what APIs exist are the ones who are able to define what comes next.

Links:

• View Blueprint

Providing collections that are dedicated to onboarding new users with an API, helping reduce the cognitive load with understanding what is possible across an API, and presenting them with only the most common API paths they will need to get started with an API, reducing the time it takes from discovery to making their first API call as a new consumer.

Links:

• View Blueprint

Leveraging a common platform workspace blueprint to define, develop, manage, observe and govern each API, providing the consistency needed to properly govern each individual API at scale across operations.

Links:

• View Blueprint

This API lifecycle blueprint focuses on defining common business workflows, then automating around these well-defined scenarios. Defining collections across multiple APIs, including authentication, scripting, data, Environment, then automating using monitors and pipelines.

Links:

• View Blueprint

Bringing a new API to life in a design-first way using a Postman collection to prototype the API, then an OpenAPI contract to help guide the API throughout the rest of its lifecycle--establishing a working design of an API before you define the contract for how it will work.

Links:

• View Blueprint

Make API workspaces public, provide the ability to engage with 3rd party consumers in the entire API lifecycle, making APIs, mock servers, documentation, testing, monitoring, and automation accessible to everyone, making APIs discoverable to public consumers, and increasing the possibilities for engagement through watching, forking, and feedback loops.

Links:

• View Blueprint

There are numerous web, industry, and enterprise standards to be considered as we produce and consume APIs each day. Investing in standards for the design, authentication, and other moving parts of our API operations helps reduce friction throughout the API lifecycle, making our APIs as interoperable and intuitive as possible, saving time and money down the road.

Links:

• View Blueprint

API builders are excited about public workspaces because it opens up an entirely new way to collaborate with folks beyond their immediate team. Some want users to learn about and use their API. Others want to stress test and gather user feedback to improve their API. Some are community organizers creating resource centers for data-driven initiatives.

Links:

• View Blueprint
• View Blog Post

Prioritizing the designing of an API using OpenAPI or AsyncAPI before any code is written, or application and integration are developed. Designing the technical details of the API using a machine-readable contract, mocking the API, documenting, and iterating upon the API with stakeholders, and potential consumers--establishing a contract for the API before it is developed and deployed into production.

This is a blueprint for pushing this API lifecycle blueprint to also work for new GraphQL APIs, identifying the steps needed to define and stand up a new GraphQL API, but then apply a consistent well-defined lifecycle to how the API is moved forward and supported in production.

Links:

• View Blueprint

Team productivity is the desire of any enterprise organization, and APIs provide a new way to find team productivity, but also quantify and make it something that is repeatable over time. APIs provide a modular and incremental way to iterate and move forward APIs behind applications and integrations, with the highest level of quality and perpetual forward motion possible.

Links:

• View Blueprint

Postman public workspaces are quickly becoming an essential part of every public API. API producers want to increase adoption of their APIs and enable a faster time to first call (TTFC). A bazillion teams have created their first public workspace, and almost everyone has the same question--What is the best way to link my public workspace to my developer docs? You could simply drop a link to the public workspace in your developer docs, but clever producers want to know the best way to do it. In this article, let’s walk through examples of public APIs that have created a good experience for developers browsing docs to make their first API calls in Postman.

Links:

• View Blueprint
• View Blog Post

Many teams use an API specification, such as OpenAPI, to describe the long-term relationship between an API producer and potential API consumers. They can then use the OpenAPI to generate user documentation in the form of a collection. And then keep their collection and specification up to date as their API grows.

Links:

• View Blueprint
• View Blog Post

A capability collection is a small single-use collection designed to accomplish a specific task, and represent a single capability of an API producer and the organization behind it. Providing a single well-documented API request that accomplishes a specific business objective, helping reduce the cognitive load when it comes to putting an API to work.

Links:

• View Blueprint

API observability involves being able to tap the existing outputs of our operations to understand the current state of the enterprise system across all teams. Being able to perpetually monitor, but also be able to see the health, history, and activity across APIs, but also the operations surrounding those APIs, allows us to observe things at a micro or macro level.

Links:

• View Blueprint

A design review establishes a period in which an API designer or developer can submit an API for review by a formal design reviewer, as well as architects from a centralized API governance group, evaluating the API for compliance against an organization's governance design guidelines.

Links:

• View Blueprint

This blueprint introduces how APIs behind mobile applications can be reverse-engineered and defined as a collection so that documentation, testing, and other common areas of the API lifecycle can be applied to help stabilize the APIs we depend on behind our applications.

Links:

• View Blueprint

This blueprint introduces how APIs behind web applications can be reverse-engineered and defined as a collection so that documentation, testing, and other common areas of the API lifecycle can be applied to help stabilize the APIs we depend on behind our applications.

Links:

• View Blueprint

The regulation of APIs in the banking, healthcare and other industries has emerged over the last decade, and other API-centered regulation like GDPR, CCPA, and other rules targeting technology platform has already begun shaping how we do business on the web and our ubiquitous mobile devices, making regulation a top priority for the enterprise in the next decade.

Links:

• View Blueprint

Time to first call (TTFC) can be the most important API metric, but it’s not the only one. So why is it more important than other metrics, like later-stage usage or performance? As an API publisher, you API journey may look a little different. But the majority of developers “get it” and “buy in” once they have a chance to interact with an API on their own terms. Legitimately streamlining TTFC results in a larger market potential of better-educated users for the later stages of your developer journey.

Links:

• View Blueprint
• View Blog Post

A public workspace provides an unprecedented opportunity to increase the exposure of your public API by making it available to 18M developers via the Postman API network. Providing a public space where consumers can watch, comment, and fork on your API artifacts, documentation, and even tests, mock servers, and monitors.

Links:

• View Blueprint
• View Blog Post

This is a blueprint for entering the API lifecycle by generating an OpenAPI using code annotations, taking a code-first approach to bringing each API to life, while still ensuring that there is a contract to help guide the API across a more standardized API lifecycle.

Links:

• View Blueprint

This is a blueprint to try and define a new event-driven API using AsyncAPI, pushing the boundaries of this API lifecycle blueprint to include multiple protocols, patterns, and ensuring that there can be a well-defined API lifecycle across a diverse set of approaches to delivering APIs.

Links:

• View Blueprint

A blueprint for approaching the governance of APIs from the top-down, establishing a higher-level strategy for defining what governance is and then helping spread guidance across teams that helps enable them to deliver more consistent APIs across a more consistent API lifecycle no matter what type of API they are delivering.

Links:

• View Blueprint