How do you version-control your mock responses so every change is clear?

Discussions
, , ,
1

Once a mock server starts helping more than one person, pushing it to Git makes life a lot easier. Small, well-scoped commits mean cleaner reviews, clearer history, and fewer “why did this break?” moments.

Haven’t built a mock server yet?
Spin one up with the earlier Club activity “Have you tried Mockoon to capture and mock real API responses?”. Then come back here and put it under version control.

Your task

  1. Push your current Mockoon server to GitHub.
    Commit the single JSON file that Mockoon generates by default (e.g. my-mock.json). This is your baseline commit.

  2. Switch route bodies from inline JSON to file-based responses.

  • In Mockoon, open a route → Response panel.
  • Change Body type to File and point it to a new .json file (create one in your project folder).
  • Repeat for a few routes—group by success/error or by feature (your call).
    Mockoon docs on data files → https://mockoon.com/docs/latest/data-files/
  1. Commit and push the refactor.
    You should now have:
  • Smaller route definitions inside the main mock file
  • Separate response files in your repo

  1. Compare the two commits in GitHub.
    Notice how the second commit is easier to read—only the paths changed, and each response lives in its own file.

  2. Share in the thread

  • What parts of your mock did you move into separate files, and why?
  • How did this change the clarity of your commit history?
  • Where could a file-based approach help collaboration or debugging in your own projects?