Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Build Status Coverage Status alt text

A library to bridge Swagger API specifications and the Mountebank Response Stubbing Tool (via interface provided by Mountebank-Helper). Pass in your API's Swagger spec file and get a full-blown mocked out version of your API to test against.


npm install swaggerbank


const SwaggerBank = require('swaggerbank');
const api = new SwaggerBank.API('./demoApi.yaml');

.then( () => {

To see this in action right now:

git clone   
cd SwaggerBank    
npm install   
node demo/full.demo.js  # from the root of the project. 

Now navigate to localhost:3000/v1/areas to see a mocked route in action! This mocked API is based on the demoApi.yaml Swagger Spec. Explore the spec and play around with the mocked responses. Whenever you're ready, swap in your own spec!

Mocked Property Generation

SwaggerBank allows you to set how you want your mocked API to behave. You have three choices (configurable through setting PROP_GEN) Try these out with the node demo/full.demo.js example above.


PROP_GEN=random: randomly generated data (that adheres to the defined schema) will be used as the mocked response. For example, if you have a property with type: string and format: uuid, then a random valid uuid will be generated for that property when it gets returned as part of a mocked response. To set custom format types for strings and ints, add them to config/options.js


PROP_GEN=static: static data pulled from config/options.js (that adheres to the defined schema) will be used as the mocked response. See repo for how config/options.js should be configured


PROP_GEN=example: The example specified in your spec under that response will be directly used as the mocked response. Important For this feature to work, ALL of your routes must have an example section

Another feature that is coming soon is the ability to hardcode a particular value for a given property name. Ex: If in your spec there is a property called remoteIp that appears in several responses which you know will always have the same value whenever the real server gets hit, then you can set the hardcoded value for this property. This will allow for setting up a mocked API that more closely reflects what the real API will do

Incomplete Features / Bugs / TODOS

See Known Issues


A library to bridge Swagger API specifications and the Mountebank Test-Double tool






No releases published


No packages published