Providing early access to your APIs is nothing new. It is something that all API providers should do whether they are publishing their APIs publicly or keeping them private for internal or partner use. However, I feel that the concept of API workspaces introduced by Postman provides you with an opportunity to segment off your APIs using different collections and make them available to an invite only audience. Realizing the concept of API workspaces allows you to easily create a working area dedicated to providing trusted users have access to early versions of your latest APIs. Leveraging the Postman platform as a conduit for engaging with your developers, and getting feedback on the designs and functionality of your APIs before they ever are generally released to the public.
Think of Postman workspaces as a separate namespace where as you are already developing your APIs, but now you can just turn on access to collections containing all the technical details of your API, including variables and authentication in an environment—allowing beta users to make calls to each API, and play around with the new functionality. All you will have to do is produce one or more Postman collections for your new beta APsIs, create a new workspace, and share your collections to the workspace. You can also publish API documentation for your collections if you want, or you can just begin with one or more Postman collections that provide everything developers will need to get up and running. Establishing special access to your APIs, without all the overhead of having to manage your beta program—you just rely on the functionality that Postman already delivers.
You might even consider publishing your early API collections and include a mock API if you don’t have the API fully baked yet. Moving forward the timeline when you can get an API into your beta users hands, and begin getting early feedback on what is going on. This can be done with internal users, your partners, or your most passionate users from your public API community. Before users get access to the canary workspace you can make sure they are in agreement with your terms of service, and other guidelines governing the beta releases of your APIs, ensuring nothing you are developing ends up on the open web. Further reducing the feedback loop when it comes to whether or not your APIs will be meeting the needs of your customers.
Once you have your canary program setup using Postman workspaces and collections, you ca also solicit feedback on the APIs directly within the Postman interface, leverage the comments feature to establish a feedback loop with your beta users. Putting all the existing features of Postman to work when it comes to building the foundation of your beta program and the feedback loop that comes with it. Demonstrating why it is fruitful to go API first, because it can shorten the cycles of your feedback loop and significantly reduces costs associated with each iteration of each version of your API. The longer you wait, the more your API designs is baked into code on both the server and client side, making beta programs more about efficiency and cost saving than it is about just giving developers an early look at what is coming down the pipes.
I’ll work on some real world prototypes of how this can be done. I’ll create some prototype canary workspaces with some APIs I’m developing, and work through the workflow as part of some stories here on the blog. I know that having an early beta or canary user program is something that many API teams I’m working with aspire to, but few have the budgets and resources to actually make happen. So actually having an easy and free (or low cost) way to implement with just a handful of users, using tooling that teams are already using is pretty attractive. It is one of those little changes you can make with your API program that will have a big impact on how you design and deliver your APIs, but also something that will dramatically help with your bottom line when it comes to the lifetime cost of delivering your API infrastructure.
