I have seen developers work in Postman without properly securing their credentials, often leaving API keys exposed in shared environments or logging sensitive data in the console. For example, some developers unknowingly expose credentials when they make their workspaces public, allowing anyone to access sensitive API keys and tokens that are not properly stored.

In this post, I want to share some tips on how you can protect your data and API in Postman.

General Tips for Securing Your APIs in Postman

When working with APIs in Postman, taking proactive security measures is essential to prevent data leaks and unauthorized access. Implementing best practices ensures your credentials, tokens, and sensitive data remain protected.

1) The secret scanner is your friend

The Postman secret scanner is every developer’s knight. It constantly scans your public workspaces and documentation for any exposed secrets. It checks your variables and environments, schemas, etc for exposed secrets and notifies all Team and Workspace admins via emails and in-app notifications.

Admins are given a link to view all exposed secrets in a dashboard and an option to immediately replace them with a placeholder using a single button click. This helps mitigate security risks faster.

If you do not replace exposed secrets in a timeframe specified in the email, the secret scanner will automatically replace this data with a placeholder for you. For example, authorization secrets can be replaced with {{vault:authorization-secret}}, or <AUTHORIZATION_SECRET>.

Pro tip 1: Whenever you want to show an example of some sensitive data, always use placeholder data before making your Workspace public. Maintain a private fork of your collection that you can continue to work in even after making your base collection public.

There’s a lot more you can do with the secret scanner in Postman. You can mark alerts as ‘false positives’, ‘won’t fix’, etc.

Pro tip 2: Don’t ever ignore the secret scanner. While there may be false positives, always check to ensure you’re not exposing anything and staying safe.

Learn more about the secret scanner here

2) Avoid secret keys in test scripts, headers, params, etc

When working with test scripts, depending on your workflow, some developers often prefer to make HTTP calls from pre-request scripts. Some HTTP calls require auth credentials, and these auth credentials can be easily exposed if you’re logging data to the console, passing data to a template for visualization, etc.

If you need to use sensitive data in your pm scripts, always first store them in a vault, environment, or collection variable, then programmatically access the data from storage.

In some cases, Postman actively checks for any sensitive data in your scripts and truncates them before logging in to avoid being exposed.

You should also be very careful when adding request headers, query/path parameters, etc. These are places where we’ve observed a lot of secrets being exposed. Our variable helpers make it easy to store data in the places in the vault or collection/environment variables. Simply highlight the value, and you will see a pop-up that helps you store the data more securely.

Here’s a list of places to take note of when making a workspace public:

• Request header
• Collection/Environment/Global Variables
• Query and Path Parameters
• Authorization helpers (API Key, Basic, OAuth, etc)
• Pre-request and Post-response scripts
• Request body
• URL bar
• Postman Console

3) Keep your credentials local with Postman Vault

Some users worry about storing their credentials in Postman environments and variables because it could potentially sync with Postman cloud depending on how it is stored. While the Postman cloud is safe and secure, we always encourage everyone to store their API secrets in the Postman Vault.

Postman Vault is a local encrypted storage that only you can access. Data stored in the Postman vault are not synced with the Postman cloud and can only be accessed using a vault key. Your vault key can be stored in your system’s password manager or securely elsewhere.

You can limit vault secrets to specific API domains, and link them to external password managers like Hashicorp, Azure Vault, 1Password, etc if you intend to share credentials with your team. Vault credentials can be programmatically accessed in Postman scripts similar to how you would access environments and collection variables.

Pro tip: When working with authorization helpers in Postman. Always use the Postman Vault.

Learn more about Postman Vaults

4) Help your API consumers stay secure with Guided Auths

Guided Auth helps you onboard consumers to your public APIs faster and more efficiently. When you set up Guided Auths for your public APIs in Postman, your API consumers get a step-by-step guide on how they can make their first successful API call as soon as they start typing your domain name in the URL bar.

They can easily set up different kinds of authentication(OAuth 2.0, Client Credentials, PKCE, etc) depending on how your guided auth is configured.

Learn how to set up Guided Auths here

Once you have guided auths set up, you can help your API consumers stay secure by choosing to store their credentials after a guided authentication step in Postman Vault. Vault secrets added using Guided Auth are inside double curly braces ({{ }}). The prefix vault: is appended to the vault secret’s name, and a suffix is automatically appended with the authentication type.

{{vault:postman-api-key:value}}

5) Current Values vs Initial Values

When using variables in Postman, it’s important to understand the difference between Initial Values and Current Values.

• Initial Values are synced to the Postman cloud. If you share your collections, your variables become visible to your team and anyone who has access to that workspace.
• Current Values are only stored locally on your machine and are not shared with others. This makes them ideal for storing sensitive API keys, tokens, or credentials.

Pro tip: Always ensure that sensitive data is stored as a Current Value to prevent accidental exposure. Use Initial Values to show examples of what the variable value could look like.

6) Authorization helpers are there to help

Postman provides authorization helpers that let you handle authentication securely without manually adding tokens or credentials in your request headers.

• Instead of manually copying access tokens, use the OAuth 2.0 helper to automatically fetch and refresh tokens.
• When using API keys, configure them in the authorization tab rather than adding them directly to request URLs.

7) Stop ignoring the warnings!

Postman does a great job at providing several warnings at different places when it suspects that something may be wrong. This warning can come as a UI popup, a push notification, an email, or status indicators on the UI depending on what it is you are trying to do. Always make sure you pay attention to these warnings and never ignore them.

It never hurts to double-check to be sure you are not exposing any sensitive information.

Remember, your data will only be public if you make them public.

Pro Tip: When creating a new Workspace, always start with a Private or Team Workspace. Once you’re done making changes, review your work and then make it public. Ensure you always check thoroughly before changing a Workspace visibility to “Public”.

7) Enforce the Principle of Lease Privilege(POLP)

Workspaces and Teams in Postman have Role-Based Access Control(RBAC) integrated in them. We encourage teams collaborating in Postman to always give access and certain privileges to only those who need them. In a Postman Team, only individuals with super admin and community manager roles are allowed to manage all public elements. Therefore, we encourage you to only assign these roles to necessary people and have a standard review process in place for when Workspaces are being published to the public.

Learn more about managing public elements in Postman here

Final Thoughts

Securing your APIs is crucial, and Postman provides various tools to help you keep your secrets safe. By leveraging features like Postman Vault, the Secret Scanner, Guided Auth, and Authorization Helpers, you can significantly reduce the risk of exposing sensitive data.

Make sure you implement these best practices and regularly audit your Postman workspaces to ensure that your API security remains strong.

Got questions? Found any of this helpful? Let me know in the comments!

Happy coding and stay secure!
Cheers!

Originally published on the Postman Community on March 4, 2025

Stop Exposing Secrets! Secure Your APIs in Postman Like a Pro was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Part 1 of this series, we learned about the WebSocket protocol and how to set up our own WebSocket server in Node.js. Next, let’s explore how to use a public WebSocket API to access smart devices around a connected home.

REST and WebSockets for a connected home

When it comes to transmitting data in a connected home environment, both REST and WebSockets are commonly used protocols, but they have different characteristics and use cases.

REST follows a request-response pattern, where a client sends a request to a server, and the server responds with the requested data. This is useful for accessing and controlling smart devices and services, and works well for scenarios where data updates are not required in real-time. For example, you could use a REST API to turn on a smart light.

On the other hand, WebSockets enables bidirectional communication between a client and server, enabling real-time data transmission. This is useful for applications that require continuous data updates, such as real-time monitoring of sensor data and displaying live dashboards. For example, you could use a WebSocket API to continuously monitor the temperature in a room over a persistent connection.

In the next section, let’s take a look at a popular home automation platform that provides both REST and WebSocket APIs.

Home Assistant for home automation

Home Assistant is a popular open-source home automation platform that lets you control and monitor smart devices from different brands using a unified interface. Instead of using separate applications to control the kitchen lights, thermostat, and other connected devices all manufactured by different producers, you can manage almost everything from a single Home Assistant web dashboard running on a Raspberry Pi or other dedicated server within your local network.

Home Assistant is ideal for DIY smart-home tinkerers because it supports a wide range of integrations and protocols, allowing you to customize automation scenarios based on events, schedules, and sensor readings.

Next, let’s take a look at Home Assistant’s WebSocket API.

Home Assistant WebSocket API

In addition to a REST API, Home Assistant also contains a WebSocket API to stream information. To learn how to authenticate the WebSockets connection and send saved messages to the Home Assistant server, follow along with this step-by-step tutorial, watch the video, and reference the sample collection.

Using a long-lived token, you can use Postman to establish a connection with our Home Assistant server running locally, and then send and receive messages using the WebSocket API.

You can also configure your own Saved Messages to create your own customized themes and sequences.

Home Assistant also provides a REST API. Explore Home Assistant’s WebSocket and REST APIs side-by-side in Postman to better understand the differences between the two protocols.

Additional resources

You can work in Postman using different API patterns and protocols. Check out these Postman resources to learn more about WebSockets:

• Guide to Postman WebSockets collection
• Using WebSocket requests docs
• WebSocket requests video

Browse the Program smart lights public workspace for APIs from other providers, such as Philips Hue and Elgato, to automatically control smart lights in your home or office. And let us know in the comments below what kind of projects you want to learn about, and what you’re doing with WebSockets.

Powering home automation with WebSocket APIs was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s review other reasons to use cloud APIs.

Reasons to use cloud APIs

In addition to providing a management console and SDKs, most cloud providers also have REST APIs that enable programmatic access to cloud services for more flexibility, automation, and extensibility. Here are some of the benefits of cloud APIs:

• Automation and integration: Automate tedious tasks and integrate cloud functionality with your own applications and systems.
• Customization and control: Take advantage of cloud capabilities to suit your specific requirements and build custom workflows or applications
• Multi-cloud and hybrid environments: If you have a mix of on-premises and cloud resources from multiple providers, you can create unified interfaces for managing and interacting with your infrastructure
• Third-party integrations: Leverage cloud services within your existing software ecosystem of tools and frameworks.

In the next section, let’s look at a popular cloud provider.

Get started with Google Cloud Platform APIs

Google Cloud Platform (GCP) is a suite of cloud computing services provided by Google to build, deploy, and scale applications and services on Google’s infrastructure. There are a wide range of services, including compute, storage, networking, machine learning, and more.

Fork the example collection to your own workspace and follow this step-by-step tutorial to get started with Compute Engine, Cloud Storage, Resource Manager, and setting up OAuth 2.0 in Postman.

Use this Run in Postman button to fork the collection:

What you’ll learn

• How to enable Google Cloud APIs
• How to authenticate to Google Cloud APIs
• How to set up cloud instances and storage
• How to troubleshoot unexpected API behavior
• How to grant access to cloud resources
• How to automate API workflows for Google Cloud Platform in Postman

If you are using Google Cloud APIs for the first time, you can follow the steps in this guide to call the APIs using requests sent through the Postman client. You can also use those requests to experiment with an API before you develop your own applications and integrations.

Find this collection, and others like it, under New > Collection in Postman. Under the Overview tab, browse More templates.

Additional resources

• Get started with this step-by-step tutorial: Get Started with Google Cloud APIs quickstart
• Walk through the sample collection: Google onboarding collection
• Review API reference for other services, such as the Google Maps Platform collection

If you’re managing a multi-cloud environment, also check out the AWS onboarding collection (Azure coming soon). And let us know in the comments below how you’re using infrastructure APIs to manage your own systems.

Get started using Google Cloud APIs to manage cloud infrastructure was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nowadays, everyone is examining how to increase efficiencies and cut costs to improve their bottom line. Although it may seem counterintuitive, engineering managers can help increase efficiencies by investing in tools for their engineering group that can help increase the team’s velocity and therefore increase efficiencies and the bottom line.

Think about GitHub or any other modern CI solution that you are currently using; for the price you pay per developer and the pricing for the CI workloads, the ROI is huge. Can you imagine what you would have done without it? How much effort and resources would you have to exert to create a CI system by yourself?

So why not invest in other tools that can increase development velocity?

There are so many modern tools and services that can assist with that. Here’s just a small sample:

• AI tools for coding (such as Tabnine and Codium)
• Services for tracking performance (such as LinearB, Acumen, Faros.ai)
• Services for optimizing CI (Redefine.dev)
• API development platforms (Postman)
• Tools for internal code documentation (Swimm)
• Tools for easing local development and on-demand environments (Velocity, Raftt, MetalBear, env0)

This seems obvious for many engineering leaders, but we often neglect this when setting our priorities and only prioritize it when complaints start pouring in from all directions (executive team, Dev team, product team, etc.)

Engineering leaders should adopt a more proactive approach to integrating velocity-increasing development tools.

So how should you adopt such a proactive approach?

Here’s a simple framework:

(1) First, negotiate with the executive team a reasonable budget (upfront) for such tools, depending on the size of your group (say, $1000 a month for a group of ten engineers).

(2) Then you must ensure you have a good way to measure the effects of such tools on your Dev team (e.g., DORA metrics or any other velocity-related KPIs).

(3) Next, choose the tool you estimate would bring the highest ROI for your team within a quarter. (more bang for the buck)

(4) Check the effects of the tool after it has been adopted by the team for at least one quarter (sometimes it takes a few weeks to have an effect) by looking at the metrics and quantifying the metrics into $$$.

There would generally be 2 indications that the tool is effective:

1. Quantifying the new metrics into $$$ would prove the ROI. (you are spending $$ on the tool, but by doing so, the company is saving $$$ since development velocity has increased)
2. The team expresses dissatisfaction when you tell the team that you intend to pull out the tool — that indicates that they love it because it probably saves them time. 🙂(and they will very likely be able to roughly quantify it as well)

(5) Finally, check if there’s a budget left for evaluating an additional tool. If so, repeat steps (3) to (5).

Here’s a simplified example of how to evaluate the efficacy of a new tool:

You have a team of 10 engineers. The hourly cost of an engineer is about $65/hour. The team identified that they are spending a lot of time spinning up their local development environment — it takes about 8 minutes to compile and spin the env up, and the developers do that at least 5 times a day. A new tool claims to improve the compile time and spin-up time. It costs $20/month per developer and an additional fixed cost of $300/month — total spending of $500/month. You decide to give it a try, and you see that the tool managed to bring the time down from 8 minutes to 4 minutes — it doesn’t seem to be too much, but let’s do the math: that’s 20 minutes a day per developer, meaning 200 minutes a day for the entire team, or about 4000 minutes a month (assuming 20 work days a month), which is about 66 hours — that’s quite a lot!

The monthly cost of the tool => $500/month

Monthly savings in work hours => 66.66 hours x $65 = $4333

The ROI is pretty clear — the saved $3933 is translated into other work the team will do. In other words, the team would get more done.

If you do not see the ROI after a single quarter, pull the tool out and use the budget to try something else.

It’s that simple. Allocate a budget, integrate, assess whether to adopt or drop, and repeat.

Finally, make sure you track and record the KPIs over time, before and after the tool’s integration. At some point, someone (from the executive team) will ask why you are paying for the tool. You need the be able to present the KPIs before and after the tool’s integration to remind everyone why the tool is in use.

So head out to seek such tools and help your team move through the gears. 🚀

That’s all for now. Thank you for reading!

Found this article insightful? Show your love by adding some applause, and follow me for more articles about team building, software engineering, and technology.

Boost Your Engineering Team’s Velocity with Smart Tool Investments was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

In programming, “hacking” has historically meant making something do what it wasn’t originally intended to do, like using a whistle from a cereal box prize to play the tone into a pay phone to get free long distance calls. Today, it also refers to finding an inelegant solution to a problem. The word has gotten a bad rap, since it typically implies a nefarious or criminal activity. But many companies offer public APIs, empowering developers to stitch together their own customized solutions, even if the workarounds are a bit of a “hack.”

For example, if the user interface doesn’t accommodate a specific use case, and you can’t control which features get released and when, it’s time to get resourceful. APIs are an opportunity to create a workaround that suits you.

Alternative solutions for reusable tests and scripts

Postman users have asked if it’s possible to reuse tests and scripts. There isn’t a button or section in Postman that says, “Store your own reusable scripts here,” but there are many ways to accomplish this.

Some alternative solutions that might work for your particular circumstances are:

• Creating collection-level or folder-level scripts to run with every request within the collection or folder.
• Storing scripts in a global variable to use within the workspace.
• Storing scripts in an environment variable to use alongside different collections.
• Setting utility functions using any scope of Postman variables at the beginning of the collection, which can then be used throughout the collection.
• Accessing your local file system for scripts saved on your machine.
• Storing scripts within reusable components in an OpenAPI definition.

In this article, we’ll explore the last option in more detail.

Storing scripts within reusable components in OpenAPI

OpenAPI is the most popular API definition format that’s driving the API-first trend. Reusable components in OpenAPI are a powerful feature in designing and documenting an API. We won’t explore this capability now, but if you’re interested in learning more about it, check out an example of re-using an error schema.

In this article, we rely on reusable components to store our scripts and tests, and then use the Postman API to retrieve them when they’re needed.

Create the script

Let’s save our script within a custom component in our API definition.

1. Create an API definition: In Postman, select APIs in the sidebar, and then select +. Enter a name for your new API, and continue without a repository. Create a new API definition for your API, and author the definition from scratch. Configure the definition as OpenAPI 3.0, YAML format, and check the option to Use a boilerplate (predefined template).
2. Create custom components: Within the generated file called index.yaml, scroll down to the section called components. Create a custom component under components that begins with an x- prefix. Add the name of your script, test, or any other data you want to store. Add a description that is the code you want to store as text for each component. See rows 38 to 49 in this example. Optionally, add a type or other metadata that is used to remind readers and yourself about this code.

Reference the script

Let’s retrieve the custom script and execute it in a request script.

Step 1: Enable YAML parsing: Store the source code for this YAML parser for JavaScript in a global variable called yaml-js. In other words, copy and paste this code into the global variables editor:

Then, under the Tests tab of the request, import yaml-js so that it can be used within the script:

Step 2: Retrieve the API definition: Use pm.sendRequest() to retrieve our API definition using the Postman API created in the previous steps. The example in the screenshot below shows the apiId and postman-api-key stored as collection variables.

Step 3: Use the reusable components: Once we retrieve the reusable components from the API definition, we can use a function like to evaluate JavaScript code represented as a string. Note: there is a big security risk in using eval(), so make sure you know what code you are running.

Try it out in Postman

1. Fork the collection: Fork the example collection from above to your own workspace by clicking the “Run in Postman” button.
2. Create an API definition: Create a new boilerplate API definition in your own workspace, and make sure to include the code from Rows 38 to 49 as seen in this example.
3. Define variables: Add the ID for the API from the previous step and your Postman API key as collection variables. Store the source code for this YAML parser in a global variable called yaml-js.
4. Confirm scripts work as expected: Send the call Using a script to see the components in action.
5. Update the API to customize your functions, or add new ones.Customize your own components:

Assessing the workaround for your use case

What part of this solution works well?

• You can organize a custom group of scripts using an x- prefix in the OpenAPI definition, such as for functions, tests, and other scripts.
• The OpenAPI definition is in Postman already, so you can add, edit, and run the new code in Postman without switching context.
• You can share these reusable components with team members in a team workspace.

What part of this solution does not work well?

• This is not the intended purpose for reusable components in an OpenAPI definition.
• The reusable components are not written in a text editor, so syntax highlighting and formatting of JavaScript is missing. It’s easier to copy and paste code into the API definition.
• eval() poses a major security risk and the user can run malicious code or code with unintended consequences.

Does this satisfy your particular use case? If not, this was not the only way to solve this problem. For example, the YAML parser was saved as a global variable available within a workspace, but we could have also made a call to a CDN to retrieve the source code for the library. We also used the Postman API to retrieve an API definition containing our reusable components, but we could have accessed our local file system for saved scripts instead.

Feel free to explore some of the other alternatives listed above. And let us know some of your favorite hacks that you use in Postman in the comments below.

Technical review by Ian Douglas

Originally published at https://blog.postman.com on February 9, 2023.

Create Reusable Tests and Scripts with OpenAPI Reusable Components was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

The WebSocket protocol provides a way to exchange data between a client and server over a persistent connection. The data can be passed in both directions with low latency and overhead, and without breaking the connection. This means the server can independently send data to the client without the client having to request it, and vice versa.

WebSockets are great for building real-time functionality into web applications, such as games and chat apps, or for communicating financial trading data or IoT sensor data. More and more people are exploring WebSocket APIs in Postman. According to Postman’s 2022 State of the API report, WebSockets are used by 26% of respondents.

In this tutorial, let’s create a WebSocket server, and use Postman to send and receive messages across the WebSocket connection.

Pre-requisites

To follow along with this tutorial, you’ll need the following:

• Node.js installed on your machine
• A text editor like VSCode installed on your machine

Create the Node.js server

In your terminal, make a new directory called websockets with the following command:

mkdir websockets

Then, navigate into the new directory:

cd websockets

Next, install , a WebSockets library for Node.js:

npm install ws

Installing the WebSockets library like this also initializes your Node.js project and creates a package where your project files are stored. Open the websockets directory using your preferred text editor, like VSCode. You should see the project files scaffolded as below:

Look inside the package.json file to see the ws dependency. Add the "type": "module" to the package.json so we can load an ES module in the next step. Your package.json should look like the following:

{
  "type": "module",
  "dependencies": {
    "ws": "^8.12.0"
  }
}

In the root directory, create a file called index.js and paste the following code from the ws documentation for a “Simple server.” This code initializes the WebSockets server. Upon establishing a connection between the client and this server (once running), the server will send the message “something” to the client:

import { WebSocketServer } from 'ws';

const wss = new WebSocketServer({ port: 8080 });

wss.on('connection', function connection(ws) {
  ws.on('message', function message(data) {
    console.log('received: %s', data);
  });

  ws.send('something');
});

It’s now time to run our server locally from the command line:

node index.js

Send and receive WebSocket messages

In Postman, select New > WebSocket Request to open a new tab. Enter the WebSocket server URL. A WebSocket URL begins with ws:// or wss:// and our server is running on localhost:8080. Click Connect.

Once Postman establishes the connection to your local server, the Messages pane will display a list of messages for the WebSocket connection, including incoming, outgoing, and network messages. You can further inspect the connection details by clicking on “Connected to ws://localhost:8080”.

The connection we established between the Postman client and local server is bidirectional, which means that in addition to receiving messages, we can also send them. Under the Message tab, write your own message and click Send.

If you have good reflexes, you may have seen your outgoing message in the Messages pane. If not, filter for the message using the controls or search bar in the Messages pane.

Verify the outgoing message was received by your local server:

Send system information

Let’s update our WebSockets server to send something a little more interesting, like our computer’s information, using the systeminformation node package. Terminate the running server ( Ctrl + C) and install the package from the command line:

npm install systeminformation

Next, import the package by adding the following code to the top of index.js:

import si from "systeminformation";

Add the following code immediately after our WebSocket connection sends the string “something”. Every 1,000 milliseconds, we will send a message about the current load on our CPU.

 setInterval(async () => {
    const cpuTemp = JSON.stringify(await si.currentLoad());
    ws.send(cpuTemp);
  }, 1000);

Save your changes, and restart the local server from the command line:

node index.js

Return to Postman and Connect to the local server. This time, we receive information about our CPU every second!

Click on a message to expand the message details and further inspect the data sent from our local server.

The messages will keep coming until you terminate the connection. Use Postman to Disconnect from the server.

Now that we have a functioning WebSocket server, we can do more things.

• Slow down the messages coming from the local server. Try updating 1000 milliseconds to 3000 milliseconds to see what happens.
• Instead of sending all the data, try sending only the average load. You may want to inspect the messages in Postman to parse the data properly.

We can write more code to customize our local application. Upon receiving a message from the client, we can do more than logging the message to the console. We can also retrieve data from other sources and perform calculations before sending our messages to the client.

Additional resources

To follow along with this tutorial, watch the video and reference the documentation at Postman Quickstarts:

Check out these Postman resources to learn more about WebSockets:

• Guide to Postman WebSockets collection
• Using WebSocket requests docs
• WebSocket requests video

In the next post, we will explore how to use our WebSockets server with Internet of Things (IoT) devices and do neat stuff around the home. Let us know in the comments below what kind of projects you want to learn more about, and what you’re doing with WebSockets.

Technical review by Ian Douglas.

Originally published at https://blog.postman.com on February 1, 2023.

Set Up a WebSockets Server in Node.js was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re one of the 20 million people who use Postman, then you’ve worked with Postman Collections in one way or another. Collections are a great way to organize API requests, and they allow developers to easily create, share, and collaborate on different APIs. Collections can be used for almost any API workflow, whether it’s mocking, monitoring, testing, or documenting an API. But how are collections able to do so much? Let’s take a closer look at what collections really are.

Note: The terms “collection” and “collection format” are both used in this article. They mean the same thing, but what makes them seem different is the context in which we use them. For instance, we use the word “collection” when working within Postman, but we use the phrase “collection format” when discussing exported collections.

What is the collection format?

The collection format is an open-source JSON format that lets us organize API requests and work seamlessly across the API lifecycle. Collections provide machine- and human-readable representations of APIs that are portable, shareable, and executable. You can also define different parameters and aspects of your API. This is similar to what you can do with other API definition formats, such as OpenAPI and RAML, except that the collection format lets you create workflows for your APIs and work across its lifecycle. It can be helpful to think of a collection as an API engine-one that helps you drive an API across its entire lifecycle.

Most of the time, we don’t need to think about how collections work unless we need to do a low-level task. For instance, if you’ve ever exported a collection from within Postman, you will notice that the exported JSON file contains all the information about your collection. Importing this file back into Postman helps you pick up where you left off with your requests, documentation, environments, variables, mocks, request headers, tests, and pre-request scripts.

The collection structure is shown below:

A very basic collection in JSON will look like this:

{
  "information": {
    "name": "My Collection",
    "description": "This is a demo collection.",
    "schema": "https://schema.postman.com/collection/json/v2.1.0/draft-07/collection.json"
   },
  "item": []
}

At the top level, collections have two main properties: “information” and “item.” The “information” property contains the general metadata about the collection, such as its name, description, and schema. An “item” is the basic building block of a collection. It allows you to specify a request, its corresponding response, and related metadata. An item can be an object or an array of different items. When it is an array, it contains some additional metadata and is called an “item-group.” You can think of an “item-group” as a folder of items that optionally has its own name, description, and events.

{
  "id": "an-item-example",
  "name": "First Folder",
  "description": "This is an ItemGroup(folder) that contains two items",
  "item": [
    {
      "id": "1",
      "name": "Item A",
      "request": "https://postman-echo.com/get"
    },
    {
      "id": "2",
      "name": "Item B",
      "request": "https://postman-echo.com/headers"
    }
  ]
}

In the snippet above, the “request” property of the item has a URL as its value. However, the value of an item’s “request” property is much more than just a URL; it is an object that can be used to represent other parts of an API request, such as the request headers, body, and anything else that is needed to successfully make an API request. The snippet below shows the basic structure of a request:

{
  "description": "This is a sample POST request",
  "url": "https://postman-echo.com/post",
  "method": "POST",
  "header": [
    {
      "key": "Content-Type",
      "value": "Application/JSON"
    },
    {
      "key": "host",
      "value": "postman-echo.com"
    }
  ],
  "body": {
    "mode": "urlencoded",
    "urlencoded": [
      {
        "key": "some-variable",
        "value": "Something awesome!"
      }
    ]
  }
}

We’ve covered a basic example of what a request looks like in JSON, but there’s a lot more that can be represented with collections, such as API responses, tests, and documentation.

Why are collections useful?

Collections have a lot of use cases that vary depending on the environment in which they are run and the needs of the person running them. Here are some of the reasons why Postman Collections have become essential to so many developers:

An API contract is a formal business agreement between producers and consumers of an API. It is a shared understanding of what an API is expected to provide. Collections are the foundation of every API contract in Postman, as their simplicity, readability, and ease-of-use makes them well-suited to serve this purpose.

If you’ve ever used the API-first approach, you will understand that the ability to easily work across the lifecycle of an API is very crucial to the quality of the APIs you build. Collections give you this ability and provide a unique interface for you to easily represent different stages of your API.

Collections are highly portable

Collections have an intuitive structure and an extremely portable format that can be shared and used in different environments without losing functionality. Part of the reason collections are so portable is that everything in a collection is divided into subunits that can be reused elsewhere in the collection.

Collections work across different specs

With the help of tooling, collections are very interoperable. You can convert a collection to an OpenAPI definition and vice versa. In Postman’s API Builder, you can import your API definitions in a variety of formats, such as OpenAPI and GraphQL, and use them to generate collections for different purposes, including mocking, documentation, and testing.

How can you run collections?

The interoperability and portability of collections, which we discussed above, allows them to be run in any environment with a variety of tools. For instance, collections can be run:

On the command line, using Newman or the Postman CLI

Newman is a command-line interface (CLI) tool that allows you to run collections in a command-line environment. You can use it to run tests and integrate it with your CI/CD pipelines. Newman can also be run as a JavaScript library.

Alternatively, you can use the Postman CLI, which enables you to run your collections, perform governance and security checks, and easily test your APIs from the command line. It syncs with your Postman account and uploads your run reports back to Postman, allowing you to do all your automation testing and pipeline runs in one place.

In your code, using the Postman Runtime

The Postman Runtime is an open source NodeJS library used internally at Postman that allows developers to work seamlessly with collections. It is much more low level than Newman; in fact, Newman was built on top of it. The Postman Runtime allows you to run collections while giving you the ability to specify parameters for timeout, strict SSL, host lookups, agents, proxies, certificate lists, and more. The Postman Runtime is also used by the Collection Runner in Postman to run your collections.

With the Postman API and webhooks

You can use the Postman API to create a webhook that lets you initiate a collection run by sending a request to it. This is particularly useful if you have some automation running and you want to trigger a collection run in response to a specific event.

Collections can do much more than most people think; there is so much that can be built and achieved with the format. The schema is completely open source and can be found on GitHub.

Originally published at https://blog.postman.com on September 29, 2022.

Postman Essentials: Exploring the Collection Format was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are building a SaaS product, you most likely also provide an API for your product.

At some point, you will probably consider whether you should also provide your customers with an SDK for the API.

In this article, I will list the advantages of supporting SDKs and the challenges of developing them.

Advantages

The most prominent argument for building SDKs is that SDKs deliver a better developer experience. A better developer experience means higher adoption and usage of the API the company is offering, which means increased usage of the product, which in turn contributes to growth.

The reasons that SDKs offer a better developer experience are:

• Without an SDK, the developers would have to develop by themselves the functions for calling the API. Such a task is perceived as lacking challenge and mundane by developers, and they would prefer to avoid it (although creating a high-quality SDK has its challenges). In addition, the SDK would have to be maintained to be up to date with the latest API changes and additions, and that’s something that clients would prefer to avoid.
• In many APIs, a single API call will not accomplish the operation that the developer intends to program — in some cases, more than one API call is required to perform an operation. For example, authentication token renewal — SDKs that are built correctly will be able to abstract this operation, and the token renewal could be done seamlessly, whereas if an SDK would not have been available, then the developer would have to develop a mechanism that can identify when the token has expired and trigger a renewal call before continuing to make the wanted API call.
• SDKs usually come with documentation that includes examples of how to make certain operations, and developers love examples on which they can rely. They say “a picture is worth a thousand words”; for developers, a single code example is worth a thousand words.

The more your customers use your product’s API for integration with their product, the more likely their satisfaction will increase if you provide them with an SDK, which will lead to more growth.

Challenges

If your product comes with an API and you are thinking about starting to develop an SDK for your customers, then there are some challenges that you must be aware of.

1. Initial creation and ramp-up time — For each of the languages that you plan to provide an SDK, keep in mind that you will have to build a CI/CD pipeline end-to-end, just as with any service or library that you are maintaining — that will take some time to build and get right: generating or writing the code, triggering tests, updating the documentation for each language and releasing the SDK.
2. Ongoing maintenance and development — Maintaining SDKs will require more effort than you may imagine. As you release your SDKs and customer adoption of the SDK increases, customers will start reporting issues and bugs which you will have to handle. In addition, you will need to update the SDKs with every API change or enhancement. That’s quite a lot of effort. Just to give you some perspective, mid-sized startups (~100 employees) may have a team of 3–5 developers to maintain the SDKs. In Fortune 500 companies, you might find a group of 10–20 engineers dedicated to SDK development and maintenance. Therefore, you should regard the SDK as another product in the line of products that you are offering and allocate resources accordingly.
3. Release management — Release management of SDKs is challenging. Assume you provide SDKs to your customers in 5 different languages. Given a new update to the API, ask yourself how do you time and control the release of a new change for all these SDKs? How do you know that all SDKs are ready for release and of high quality?
   End of life is also challenging because you cannot force clients to switch SDKs, and convincing them to upgrade their SDK version is also challenging. So given that you support 5 SDKs and you have released 10 changes to the SDKs (following 10 API updates) then you in fact need to track 50 different versions of your SDKs. Tracking the SDK version used by each client is also challenging once you get to tens of customers or upwards (each one is using a different SDK version for a different language).
   As you may understand, this may get really complicated, and you will sooner or later find yourself appointing or taking on the role of a release manager.

Should you build it?

If your product is an API-driven product, meaning the provided API is at the core of your product offering, a.k.a. API-first product (such as Stripe, Twilio, etc.), then the answer is a definite “Yes!”. As a company building an API-first product, your customers expect you to provide an SDK.

There are other cases where you might not be building an API-first product but you should consider providing an SDK. Such cases are when your product might need a minimal API integration with the customer’s application, such as in their web client, in order to operate correctly, but they are required to perform a series of API operations for the integration. In such cases, not providing an SDK that wraps that series of calls will result in customers spending time with your technical support team, or engineering team, to complete the integration properly. This would lead to customer dissatisfaction and a lot of effort for your support team and your customers.

An SDK will immensely increase the integration experience and preserve your company’s reputation.

Otherwise, do not go for an SDK unless you feel that it is a deal enabler, meaning a prospect will buy your product (preferably writing a big check) if it comes with an SDK for the language of their choice. But keep in mind that once you provide support for one customer, other customers or prospects may follow suit and also ask for an SDK for their language of choice.

Some companies choose to create an open source SDK and release it with a disclaimer saying that the SDK is maintained by the community, but this should be thoroughly considered because not doing any maintenance or neglecting the open source may somewhat affect your reputation as a company.

Finally, keep in mind that in some cases, you can delegate the creation of the SDK to the client by providing a complete and well-structured OpenAPI schema. By doing so, clients can use open source SDK generators such as OpenaAPI-generator to create an SDK for their own use.

Summary

Building an SDK will increase customer satisfaction by providing a better developer experience, and help product adoption.

Providing SDKs has become a standard for companies building API-first products.

Building and maintaining SDKs requires considerable effort, and any company which does not build API-first products should thoroughly assess the cost-effectiveness of building and supporting SDKs.

Feel free to share any tips or tools you have learned from building SDKs in the past in the comments.

Thank you for taking the time to read this article. I hope you found it helpful. If so, show your love and add some claps.

Follow me for more articles about team building, software engineering, technology, and technology-enabled business opportunities.

To Build (an SDK), or not to Build — that is the question! was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

Identity and Access Management system deals with “who” should get “what” level of access to an object (entity) or a function. The subsystem that defines “who” is called Authentication (Identity), while the subsystem that defines “what” level of access is called Authorization (Access).

Building an IAM system can get very complex quickly. No wonder “Broken Authentication” and “Broken Authorization” are listed in OWASP Top Ten WebApp Security risks and OWASP Top Ten API Security risks. Security risks in IAM system arises due to flawed or missed logic, or due to gap in the implementation and design due to it’s complexity.

This article explains the evolution of the Authorization component of an IAM system with the growth of the software. Let us consider a content management system (such as Medium) for example while we build it up. Here,

• Let V1 be the visitor (unauthenticated) user, and M1 … M3 be the member (authenticated) users.
• Let B1 … B5 be the Blog entities
• Let Read (R), Write (W) and Clap (C) be the actions that can be performed on the entities

The notation:

{u, v} can {a, b} on {m, n}

Implies, a nested Cartesian product:

{Set of users} can (perform) {Set of actions} on {Set of Entities}

u can a on m, u can a on n, u can b on m, u can b on n, v can a on m, v can a on n, v can b on m, v can b on n

Unprotected systems

Let us begin from zero. A system in which anyone has access to anything. There is no authentication nor authorization in place. A system with such characteristics defines the starting point for IAM. IAM does not exist or does nothing in such a system.

The CMS in this state has all the blogs readable, writable and clap-able by any visitor and/or member.

{V1, M1, M2, M3} can {R, W, C} on {B1, B2, B3, B4, B5}

All-or-Nothing

In such systems, there are two access levels for entities: public and private. Certain entities may be tagged public which implies that this entity can be acted upon by any user. While, certain entities can be tagged private which implies that this entity can be acted only upon by a specific user. To identify a specific user authentication is required.

Let, blog B1 be a private blog to M1, B2 be a private blog to M2 while the rest be public. Then,

{V1, M1, M2, M3} can {R, W, C} on {B3, B4, B5}, or
{M1} can {R, W, C} on {B1}, or
{M2} can {R, W, C} on {B2}

Controlled Sharing

This is where IAM starts to become complex. To enable collaboration and feedback, restricting access levels for entities to only public and private may not be valuable. To better understand the build up of controlled sharing let us break it down into the multiple sub-phases.

Controlled Sharing: All-or-Nothing

Customers of CMS complain that private blogs are too restrictive. They want to be able to share the blog(s) only to a certain specific set of users for collaboration.

In such systems, there are three access levels for entities: public, shared and private. Public and private continue to hold the definitions from All-or-Nothing system. A shared entity is an entity that can be acted upon only by a specific set of users.

Let B1 be a private blog to M1, B2 be a private blog to M2, B3 be a shared blog to M2 and M3, while the rest be public. Then,

{V1, M1, M2, M3} can {R, W, C} on {B4, B5}, or
{M1} can {R, W, C} on {B1}, or
{M2} can {R, W, C} on {B2, B3}, or
{M3} can {R, W, C} on {B3}

Nested Controlled Sharing

Customers now complain of shared blogs being too open to the authorized set of users. They want to be able to restrict the set of actions a specific subset of the authorized users can perform. For example, “while I have full access to the blog, I want my peer(s) to only read it and not be able to edit it.”

In such systems, there again exists three levels of access: public, private and shared, with private and public continuing to hold it’s definition from All-or-Nothing system. The shared access level, which used to deal with only one parameter i.e Entity, now deals with two parameters i.e. Action and Entity. Side Note: The (Action, Entity) tuple is called a permission.

Let B1 be a private blog to M1, B2 be a private blog to M2, B3 be a shared blog to M2 and M3, with M2 having the ability to perform only R, and C actions, while M3 be able to perform R, W and C actions on it. Meanwhile, let the rest of the entities be public. Then,

{V1, M1, M2, M3} can {R, W, C} on {B4, B5}, or
{M1} can {R, W, C} on {B2}, or
{M2} can {R, W, C} on {B2}, or
{M2} can {R, C} on {B3}, or
{M3} can {R, W, C} on {B3}

Dynamic Nested Controlled Sharing

All this while we have been looking at static rules to define authorization. It would be unmanageable and cumbersome to contact the service provider to edit the authorization rules with new entities, new users and new requirements (changing users/entities).

This introduces a new action, Grant (G), on actions that can be performed on an entity. For example, Grant Read (GR) is defined as the ability to grant read access to the entity in reference to any other user.

Consider the same scenario as mentioned in the Nested Controlled Sharing case. The new set of authorization rules would then be,

{V1, M1, M2, M3} can {R, W, C, GR, GW, GC} on {B4, B5}, or
{M1} can {R, W, C, GR, GW, GC} on {B2}, or
{M2} can {R, W, C, GR, GW, GC} on {B2}, or
{M2} can {R, C} on {B3}, or
{M3} can {R, W, C, GR, GW, GC} on {B3}

Conclusion on Controlled Sharing

At this point, it is worth mentioning about different Access Control schemes.

• Discretionary Access Control (DAC): The owner (creator) of the entity possess grant permissions (Recall, permission is (Action, Entity) tuple).
  For example, in the CMS system with {V1, M1, M2, M3} users, {R, W, C} actions and {} blogs, when M1 creates a blog B1, the authorization rules are:

{V1, M1, M2, M3} can {R, W, C, GR, GW, GC} on {}, or
{M1} can {R, W, C, GR, GW, GC} on {B1}

• Mandatory Access Control (MAC): A specific administrator has access to grant permissions.
  For example, in the CMS system with {V1, M1, M2, M3} users, {R, W, C} actions and {} blogs, and M1 being the administrator, when M2 creates a blog B1, the authorization rules are:

{V1, M1, M2, M3} can {R, W, C, GR, GW, GC} on {}, or
{M1} can {GR, GW, GC} on {B1}
{M2} can {R, W, C} on {B1}

• Role-Based Access Control (RBAC): A complex access control scheme that includes Role as an Entity, in addition to blog. The actions on the Role are: assume (A) (For simplicity) (Other actions on the role includes read, write, update, delete etc.). Similar to any other actions, assume action can also be granted (GA). In this scheme, a user/role cannot act independently on entities. A user can independently only assume a role. A user on assuming a role can act on an entity, including another role.
  For example, in the CMS system with {V1, M1, M2, M3} users, {R, W, C} actions on blogs and {A} actions on roles, {} blogs and {R1, R2} roles.
  Let R1 be a role that can perform anything to any role, while R2 be a role that can perform anything on any blog. Let R1 be assumable only by M1, R2 be assumable by any authenticated user, M2 assumes R2 and creates a blog B1.

{R1} can {GA} on {R1, R2}
{R2} can {R, W, C, GR, GW, GC} on {B1}, or
---
{V1} can {R, W, C, A} on {}, or
{M1, M2, M3} can {R, W, C} on {}, or
{M1, M2, M3} can {A} on {R2}, or
{M1} can {A} on {R1}

User-programmed controlled sharing

So far we have been looking at permissions to those entities that are stored. Consider the case when the CMS wants to display the total number of blogs that exists in their system be it public, shared or private to any visitor/member. Further, it wants to display the total number of public, private and shared blogs individually. Though a visitor (unauthenticated) user is not allowed to access the private and shared blogs, he/she should be able to see the above statistics. Moreover, these statistics may or may not be stored. It may be calculated on demand. Access control to such “actions” on such “entities” are categorized into User-programmed controlled sharing.

Side note: Hence there exists two different security risks in OWASP top ten, namely: Broken “object” level authorization and broken “function” level authorization.

Attribute Based Access Control (ABAC) is an access control scheme that involves user-programmed controlled sharing. Consider the case when access to a specific object is given only during a certain time period, say between 9 am to 5 pm IST. And/Or, access to a specific object is given only when the user is located in a specific area, say in a circle with center at (37.7858846, -122.4074781) coordinates and radius 250 m.

Conclusion

Designing an access control system highly depends on the customer’s needs. Most mature products have dynamic nested controlled sharing capabilities while there are certain features that uses User-programmed controlled sharing. However, critical systems such as military, government, healthcare and finance technology software do have advanced access control systems implemented and enforced. One such advanced access control is “Separation of duty”: A single user cannot individually execute a critical action.

The complexity in designing an access control system is present in identifying:

• The access control scheme (DAC, MAC, RBAC, ABAC, hybrid or custom?)
• The entities and the granularity to which it needs to be access controlled
• The actions that can be performed on the entity
• The storage schema for the identified entities, actions, and users
• Sequence flow to perform authorization rule check, and
• Other system design choices

Reference

J. H. Saltzer and M. D. Schroeder, “The protection of information in computer systems,” in Proceedings of the IEEE, vol. 63, no. 9, pp. 1278–1308, Sept. 1975, doi: 10.1109/PROC.1975.9939.

How complex can Authorization get? was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jamstack originally referenced a web architecture composed of JAM: JavaScript, APIs, and Markup. Websites could be delivered statically, such as serving HTML from static hosting, while providing dynamic content and an interactive experience through JavaScript and APIs.

“A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup”

— Mathias Biilmann (CEO & Co-founder of Netlify)

This type of architecture decouples the frontend from the backend. So instead of running on a backend web server, a Jamstack site typically deploys to a content delivery network (CDN) so web content can be delivered quickly from edge servers that are close to the end users and API endpoints can be hosted on serverless architecture.

Over the last few years, Jamstack has grown beyond just sites to serve static content, and has led to colorful debate about what constitutes Jamstack and even opinions about its capitalization. Regardless of your criteria, these static web apps are becoming very popular among hobbyists and global enterprises alike. And their growth is further driven by the booming API economy that can offer any variety of third-party services and turnkey solutions.

For developers who are new to Jamstack, let’s walk through a simplified example in Postman to see how each part of the JAM works.

4 steps to build a Jamstack application in Postman

The modular and decoupled nature of Jamstack architecture means there are a bunch of tools available to help you with each part of the implementation. For example, most Jamstack applications are developed using JavaScript web frameworks like Next.js and Gatsby. And then they’re deployed using services like Vercel and Netlify and hosted on a content delivery network (CDN).

Let’s build and host a simplified Jamstack application in Postman, using code samples from the Postman documentation for the visualizer. And then we will take a closer look at the JAM.

1: Create a collection

In Postman, create a new collection named Jamstack. Then add a GET request to the collection named API call with the request URL {{url}}/data.

2: Add an example response

Select the overflow menu (…) of the request to add an example response (e.g.) called Example data. This example response is what will be returned from our mock server. Under the Body tab of the example response (on the bottom), select the JSON data type from the dropdown menu. Then add the following placeholder JSON.

[

  {

    "name": "Alice",

    "email": "alice@example.com"

  },

  {

    "name": "Jack",

    "email": "jack@example.com"

  }

]

If you’re copying from the Postman documentation, make sure to remove the commented row beginning with // and preceding , character so that the JSON is valid.

Under the Headers tab of the example response (still on the bottom), add a header with a key Content-type and value application/json. Lastly, add a response status code of 200 OK.

3. Add a mock server

Select the overflow menu (…) of the collection Jamstack to add a new mock server called Mock data to the collection. Once Postman finishes creating the mock server, select the new environment created by Postman also called Mock data. Hover on {{url}} in the request URL to see the value being read from the actively-selected environment.

4. Visualize the data

Select the request API call, and send the request to see the example data returning from the mock server. To update the data returned from the mock server, you can edit the example response body (e.g.). We will continue using code samples from the Postman documentation for the visualizer. Under the Tests tab, add the following code for an HTML table represented as a template string.

var template = `

  <table bgcolor="#FFFFFF">

    <tr>

      <th>Name</th>

      <th>Email</th>

    </tr>

    {{#each response}}

      <tr>

        <td>{{name}}</td>

        <td>{{email}}</td>

      </tr>

    {{/each}}

  </table>

`;

And then add the following code to pass the response data to render in the template string and instantiate the visualization.

// Set visualizer

pm.visualizer.set(template, {

  // Pass the response body parsed as JSON as `data`

  response: pm.response.json()

});

Save your changes. And then send the call, and toggle over to the Visualize tab of the response to see our table.

If you want to skip ahead to the finished product, fork this example collection and environment to your own workspace.

In the next section, let’s dissect the JAM in this example, and think about ways to enhance each component.

A closer look at the JAM

JavaScript

The visualization is instantiated using the pm.visualizer.set() function invoked in a test script. The Postman sandbox provides access to other JavaScript functions and libraries that can be used in pre-request or test scripts. Furthermore, external CDN libraries can be imported using a function like pm.sendRequest() among other ways of using external libraries.

APIs

We stored our data using a mock server hosted on Postman cloud, accessing the data with a call to our mock API. This allows us to quickly edit the data and “deploy” our updates by saving our changes to Postman. If we find a third-party service we like, or create our own custom API, we can swap out the API to call. In fact, we can call as many APIs as we wish, synthesize the data and perform calculations to create our own custom services.

Markup

We visualized an HTML template string that can be styled with CSS. You can also use Handlebars templating language to generate HTML. If you don’t feel like writing your own Markup, search for other visualizations created by other members of the Postman community. And once again, external CDN libraries can be imported, this time using script tags within the template string.

Extend this to production-level applications

We did it! It is possible to develop, deploy, and host a complete Jamstack application in Postman. But this was a simplified example. At some point, you may choose to swap out your mock data with a third-party service or your own API hosted on serverless architecture. Or you may decide not to visualize the HTML in Postman, but in a web browser instead. There are a bunch of tools, technologies, and workflows to support your Jamstack applications.

The Jamstack architecture lets you get creative with your implementation. JavaScript and APIs allow you to pull data dynamically with interactivity limited only by your imagination. And the thriving API economy means your options for this dynamic behavior are growing fast.

If you want to see more examples of Jamstack applications in Postman, browse other examples created by members of the Postman community.

Watch and learn

How to build a Jamstack application in Postman was originally published in Better Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.