The Quickest Way to Partner with Postman Is Through the Network

One of the areas I am working on defining at Postman is how we partner with API providers, and API service providers. We are doing a lot of partnering right now, but we do not have a formal program for how we engage with our partners. Over the last couple of months I have been working to identify who all of our partners are, and define the common ways we partner with these various companies, non-profit organizations, institutions, and government agencies. I have a lot of people reaching out about partnering, and there are a lot of interesting APIs, services, and tooling providers I am looking to partner with, so we will need to get a little more formal about things if we are going to take things to the next level. One of the most obvious ways I can encourage folks to partner with Postman is to publish a collection for their API to the Postman public API network. Once Postman formalizes its partner strategy, this will become the lowest tier of partnership for the platform and community, providing a self-service way to engage with us (pssst! you don't have to wait).

If you aren’t familiar, the Postman network is a public directory of APIs. To join all you have to do is click n the dropdown menu for each of your API collections, and choose to publish as docs.

 As part of the process you are given the option to publish as part of the Postman API network—making your collection available on the web, and within the Postman desktop client. There are a bunch of settings as part of publishing documentation using Postman, and the collection discovery portion of the settings will allow you to control how things are published (or not).

Once you hit publish the documentation and run in Postman button for your collection will show up under your user or team page, which is something you can repeat over and over for different API, building up an entire suite of different collections--you don't just have to have one.

You can choose to publish it to the API network, which will require a review of the collection by Postman staff, or you can choose to add as a template, which requires less scrutiny. If a collection is the official reference documentation for your API then I recommend adding it to the network. If it is a more single use, workflow, tutorial, or other more utility type of collection, then I recommend adding it as a template. I also recommend spending a little time thinking about your user profile a bit, or if you are publishing as part of a team, I recommend spending some time in your team settings to make sure your page looks good from the outside.

You can have multiple collections published to the network or as templates, and these will all be accessible from your user or team page. So it makes sense to put a little thought into whether these collections represent your work as an individual, or as part of your team. If it reflects your team, then you planted the seeds for a (network) partnership with Postman. Once you have your APIs available in the network, and they meet some basic quality criteria, there is an opportunity for further discussion around a variety of partner activities. While the levels of partnership and types of activities are still being defined, I am always happy to talk about the best possible way to leverage the Postman network, and other storytelling opportunities that exist--feel free to ping me.

On the Postman platform the collection is the most meaningful unit of value. Representing your entire API operations, all the way down to individual API capabilities your organization possesses. A collection added to the Postman API network becomes the focal point of blog posts, webinars, Twitch live streams, case studies, workshops, educational curriculum, and other activities that occur regularly within our ecosystem. I am keen on getting as many API reference collections as I can into the Postman API network, so if just added one, feel free to Tweet a link to the page to me. I am also looking for more innovative collections such as on-boarding, deployment, management, and other types of what I’d consider to be API lifecycle collections. I’ve seen some pretty interesting incarnations from customers, and I’m very interested in expanding my awareness of what is going on. Drop me a line.