postman-code-generators, turning a Postman request into a snippet in 30 languages

One request object in, one snippet out

The module converts a Postman SDK Request object into a code snippet of a chosen language. That is the entire contract, and it is a small surface with a large reach, because the Postman SDK Request is the same object shape the Postman app holds, so anything that can read a collection can be converted. The repository is the common one for all the generators Postman ships, which is why the code lives in a codegens/ directory with a shared lib/ and a shared test/ rather than as one package per language. The interesting design decision is the two-identifier model, because it separates two things people usually conflate. The language of a code generator is the programming language in which the code snippet is generated. The variant is the methodology or the underlying library used by that language to send the request. So JavaScript is one language with three variants, Fetch, jQuery and XHR, and NodeJs is one language with four, Axios, Native, Request and Unirest. That distinction is what lets a user ask for the same request in the same language through different libraries.

var codegen = require('postman-code-generators'),
    supportedCodegens = codegen.getLanguageList();
console.log(supportedCodegens);

The catalogue, and how a language becomes a set of variants

The supported generator table in the project documentation is the best overview of what the library covers. C appears with libcurl, and C# with HttpClient and RestSharp, and cURL with cURL. Dart has http, Go has Native, and there is a plain HTTP variant that emits raw HTTP. Java appears three times, with OkHttp, with Unirest and with HttpClient, and Kotlin with OkHttp. JavaScript has Fetch, jQuery and XHR. NodeJs has Axios, Native, Request and Unirest, Objective-C has NSURLSession, and OCaml has Cohttp. PHP has four, cURL, Guzzle, pecl_http and HTTP_Request2, and PowerShell has RestMethod. Python has http.client and Requests, R has httr and RCurl, Rust has Reqwest, Ruby has Net:HTTP, Shell has Httpie and wget, and Swift has URLSession. The getLanguageList function returns this in a structured form, with each language carrying a key, a label, a syntax mode and its list of variants, so a UI can build a two-level picker from one call.

| JavaScript | Fetch |
| JavaScript | jQuery |
| JavaScript | XHR |
| NodeJs | Axios |
| NodeJs | Native |
| NodeJs | Request |
| NodeJs | Unirest |

getOptions, and why every generator has its own settings

getOptions takes three parameters and returns a callback with an error and the supported options of that code generator: a language key from the language list, a variant key provided by that list, and the callback itself. The options are what you configure the generated snippet with, and the shape of an option is fixed across generators: a display name, a unique id, a data type, a default value and a user friendly description. The allowed data types are boolean, enum and positiveInteger, which tells you what a generator can meaningfully vary. The example given is the NodeJs Request generator, whose options include the indentation count as a positiveInteger defaulting to 2 and the indentation type as an enum of Tab or Space defaulting to Space. Because options are per generator, a caller has to ask before it configures, which is why the three-function design has getOptions as a separate step rather than a guess embedded in convert.

var codegen = require('postman-code-generators'),
    language = 'nodejs',
    variant = 'Request';

codegen.getOptions(language, variant, function (error, options) {
  if (error) {
    // handle error
  }
  console.log(options);
});

convert, and the options that change the output

convert takes five parameters and returns a callback with an error and the generated code snippet: the language key, the variant key, the request, the options, and the callback. The options object is where the snippet is configured, and unspecified attributes fall back to their defaults. The example builds a request with the Postman SDK, points it at a URL, and passes an options object with indentCount set to 3, indentType as Space, and two booleans, trimRequestBody and followRedirect. That last pair is the reason to use this library rather than hand-rolling a generator, because whether to trim the request body and whether to follow redirects are semantic choices about how the generated client will behave against your server, and they differ between libraries. Note that the same example passes the variant as a lowercase request, whereas the language list returns the variant key in a particular case, so the key has to come from the list rather than be guessed.

var codegen = require('postman-code-generators'),
    sdk = require('postman-collection'),
    request = new sdk.Request('https://www.google.com'),
    language = 'nodejs',
    variant = 'request',
    options = {
        indentCount: 3,
        indentType: 'Space',
        trimRequestBody: true,
        followRedirect: true
    };
codegen.convert(language, variant, request, options, function(error, snippet) {
    if (error) {
        //  handle error
    }
    //  handle snippet
});

Installing it, and the Node version question

Installation as a dependency is a single npm install, and a local copy comes from cloning the repository. The usage documentation states the prerequisite as NodeJS greater than or equal to version 8, with a link to the Node download page, and that is where most readers will stop. The package metadata is stricter, and the engines field requires Node 18 or newer, which is the number to plan against. The two statements are not in conflict so much as out of date relative to each other, and the metadata is what npm will act on. The runtime dependencies are a short list: async, detect-package-manager, lodash, postman-collection at version 5 or newer, and shelljs. The presence of detect-package-manager and shelljs in a library that emits code snippets is a sign of what the repository is really for, which is not only serving snippets but building and shipping them.

$ npm install postman-code-generators

The npm scripts, and what they reveal about the build

The scripts section explains the whole publishing pipeline, and it is the part of this repository that is different from a normal library. The postinstall script runs a deepinstall script, and there is a separate deepinstall script as well, which installs the dependencies of every individual code generator rather than just the top level ones. A boilerplate script generates the scaffolding for a new generator, and a cirequirements script appears to compute the CI requirements. A package script runs a packaging script, a zip script produces a zip, and a prepack script runs a pre-package step, so the publish flow is a chain of scripts rather than a single npm publish. The test script points at a shell script in the npm/ directory, and a test-lint script runs the linting separately. The development dependencies confirm the shape: browserify and watchify for bundling, mocha with istanbul and nyc for coverage, newman for running collections as tests, jsdoc for the API documentation, and a set of eslint plugins including one for jsdoc, one for lodash and one for security.

$ npm run deepinstall dev;

The version history, and what changed with it

The release history shows a project that has been through a few structural changes. v2.1.1 is from 2026-03-10, v2.1.0 from 2025-11-12, and v2.0.0 from 2025-03-10, so the 2.x line has been in place for about a year and a half with a minor release every few months. The last push to the repository was on 2026-09-18 and the default branch is develop, not main, which is the normal arrangement for a project where the released version is cut from a development branch. The package version in the metadata matches the latest release at 2.1.1. The licence is Apache-2.0, with the file at the root, and the repository also carries an ADDITIONAL_DEPENDENCIES.md document, which is the one file whose purpose is not obvious from its name and which is worth reading if you are contributing a generator with its own dependency tree, since the postinstall deep install step is what pulls those in.

codegens/
lib/
npm/
test/

Where this library stops

Two limits are worth naming. The first is that the generator table is fixed and the variants are per language, so a request shape that a particular library cannot express is simply not reachable through that combination, and the closest you get is another variant of the same language. The second is that the output is a starting point rather than a client. A generated snippet sends one request; it has no authentication lifecycle, no error handling policy, no retry behaviour and no configuration, and the trimRequestBody and followRedirect options show how much of the behaviour still has to be decided by you. For documentation, where the point is to show the shape of a call, that is exactly right. For a production SDK, the snippet is where your generator starts. The repository itself is honest about its role as a common home for the generators Postman ships, and the directory layout with a codegens/ folder, shared lib/ and a shared test/ is the shape you would expect from something maintained primarily to serve the Postman product.

Common repository for all code generators

Editorial conclusion

Adopt postman-code-generators if you generate API client snippets at scale, for instance in a documentation pipeline or a client SDK bootstrap, and skip it if you only need a snippet once, because the Postman app and its API can do that without a dependency. Verify three things before you build on it: that the language and variant you need is in the table, since the catalogue is fixed and the variants are per language rather than per request; that the options you care about are exposed for that particular generator, because the option set differs between them; and the Node version, since the package metadata now requires Node 18 or newer even though the usage documentation still says NodeJS 8 or above.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. postmanlabs/postman-code-generators on GitHub
4. README
5. Releases