You are fast sir! I'm sorry if I may have come across as negative in my post. That was definitely not the intention.
That does seem like a lot of progress. I love the fact that it's built dynamically instead of manually.
I had noticed that the API key had moved to these temporary headers. Basically the collection variables are an alternative to setting up an environment, correct?
How about the documentation for the body though? In the example I gave of the createOrganizationNetworks endpoint, the bulk of the interesting payload is in there rather, than in the params. Questions I have are for example, what name/value pairs can be put in, which ones are obligatory, which ones are optional, what's the syntax of the value? The specific issue we had in the other topic was that the postman collection didn't mention the copyFromNetworkId anywhere.
The collection variables allow us to set a standard convention for the parameter names. We've been working to normalize our global name space, so that instead of "id" we use "organizationId" for example. You can use your personal environment, which will pass any matching variables through to the collection. You may have to update a few variables, but this should rarely change in the future, unless we had to clean up a conflict.
Regarding the POST body schema... Yeah, I noticed that. Postman doesn't really have a place to to auto-generate the body model. The OAS spec has the information, and our official API Docs show this data as well. I'll look into parsing this info and shoving it in the description.
(FYI: snippet of OAS spec, which shows example and schema data)