EasyPost spoke at the Postman User Conference (POSTCON) last week, and while they shared a number of very interesting stories, one that really stuck with me was about how they create Postman Collections for use by their non-technical sales teams. They put some of the common API driven tasks that a sales person would need to execute in the course of their daily work into each collection, and provided environments so that they didn’t have to mess around with authentication. Making for a pretty compelling tale of non-developers putting APIs to work, which is kind of the holy grail of API consumption—empowering average business users to realize the potential of APIs.
I am going to be creating several proof of concepts to see if I can create Postman Collections that are valuable enough, and simple enough to be executed by a non-technical user. The Postman interface can be a little busy at times because it is so feature rich, but I don’t think it is out of the question for a business user to be able to get in there and execute on some pre-configured templates and collections. We’ll see. I think it depends on the quality of the collection, and the fearlessness of the would-be user. I think with the right amount of attention while crafting, naming, and organizing the API collection, as wel as a dedicated effort to abstracting away the complexity of any of the underlying APIs, making it one click to get some value from some common, or even specialized APIs, we can make APIs much more accessible to a business audience.
Postman provides a unique opportunity to make existing APIs more commonplace--reaching beyond just developers. I think we just have to work harder at defining collections, environments, and the scripts that help automate potential API engagements. We’ll have to make sure we select useful API paths, pre-populate them with relevant values, and properly name and organize useful API capabilities, and then I believe we can start empowering average business users with features they will value. Postman lets you define workspaces with a variety of pre-defined API collections that are complete with environments, making for a pretty compelling API on-boarding solution for both developers and non-developers. Establishing a common executable format for accomplishing common tasks different teams will encounter in the course of their daily work.
I have a lot to learn when it comes to properly crafting Postman Collections. I’ve got the basics, but when it comes to sufficiently rounding off the sharp edges that will create friction for potential users, I have a lot of practicing ahead of me. I’m going to conjure up a handful of potential roles for tailoring Postman Collections and Workspaces for, going beyond sales teams, and targeting marketing, journalism, and a handful of others to see if I can’t craft some useful API collections. If nothing else I’ll get more practice when it comes to creating Postman API Collections, and gather more intelligence from the poor non-technical folks I’ll be using as test subjects when it comes to this experiment. I was inspired by the EasyPost team, and want to see if I can push the boundary of the types of users who are putting Postman to work, and expand the landscape when it comes to who consumes APIs.
