# Mocking Dependencies for Local Development

Every service you own eventually grows a tail of other services it talks to. A gateway that started out calling one payment processor picks up a CRM integration, then a calendar sync, then a compliance check, and a year later nobody can run it on their laptop without either a VPN into staging or a pile of commented-out API calls. We lose so much time to this. The usual version of the story: you clone a service, run it, and it immediately throws on a call to some third-party API you don't have credentials for. You go hunting through the codebase for every place that service reaches out. You stub out what you can find, miss one, and spend the rest of the day chasing a stack trace that only shows up two services downstream from the one you're working on. The annoying part isn't mocking one dependency. It's finding all of them, including the ones that don't live in the repo you're looking at. In this walkthrough, I'm setting up an existing gateway service for local development using [Claude Code](https://claude.com/claude-code) and the [Postman plugin](https://learning.postman.com/docs/reference/developer-resources/claude-code-plugin). The plugin ships with a set of [skills on GitHub](https://github.com/postmanlabs/postman-plugin/tree/main/skills) that cover exactly this kind of work: one to find what a service depends on, one to mock those dependencies, and one to check that the mocks hold up.

## Find out what a service calls

 I'd already wired up a handful of third-party integrations on this gateway: [Nylas](https://developer.nylas.com/) for calendar sync, DocuSign, PayPal, Notion, and a text-filtering service called Pergomalum. Here's the prompt I gave Claude: > Set up local Postman mocks for this service. I want to test the gateway without hitting any of those real external services.

 Before Claude touched anything, it used the api-discovery skill to check the Context Graph for every integration the gateway calls, along with the endpoints and schemas each one exposes. That's worth noting: this isn't a grep across the codebase for API client imports. The [Context Graph](https://blog.postman.com/introducing-the-context-graph-api-one-map-of-your-api-ecosystem/) already knows which services exist and how they connect, so Claude got a real dependency list back instead of a guess built from whatever files happened to be open. ## Mock each dependency without standing up a server

 With the dependency list in hand, Claude moved on to the api-mocking skill, one integration at a time: Pergomalum, then DocuSign, then PayPal, then Notion, then Nylas. The api-mocking skill can push a mock to Postman's cloud for a durable URL, but for local work it uses [Postman Local Mock Servers](https://learning.postman.com/docs/design-apis/mock-apis/local-mock-servers) instead, a Git-backed mock that lives right next to your collections in the repo. Each one gets a folder under `postman/mocks/`, with a config file and a JavaScript handler per scenario: ```
# postman/mocks/pergomalum/config.yaml
name: pergomalum-mock
port: 4511
defaultScenario: happy-path
scenarios:
  - name: happy-path
    file: happy-path.js
  - name: rate-limited
    file: rate-limited.js

```

 ```
// postman/mocks/pergomalum/happy-path.js
// @endpoint POST /v1/filter
function handleRequest(request) {
  return {
    status: 200,
    body: {
      flagged: false,
      categories: [],
      checked_at: new Date().toISOString(),
    },
  };
}

```

 Because the mock is files in the repo, it travels with the code. Commit the `postman/mocks/` folder and the next person who clones the gateway gets the same mocks, on the same ports, without rebuilding anything. ## Wire the gateway to point at the mocks

 A mock running on `localhost` doesn't help until something calls it. Claude's next step was updating the gateway's environment configuration so each integration's base URL pointed at its local mock port instead of the real API: ```
PERGOMALUM_API_URL=http://localhost:4511
DOCUSIGN_API_URL=http://localhost:4512
PAYPAL_API_URL=http://localhost:4513
NOTION_API_URL=http://localhost:4514
NYLAS_API_URL=http://localhost:4515

```

 This is the same override pattern Postman's own write-up on [swapping external dependencies for local mocks](https://blog.postman.com/swapping-external-dependencies-with-local-mocks-servers/) describes: point the environment variable your service already reads for that integration at `localhost`, and nothing in the gateway's code has to change at all. ## Verify the mocks behave like the real thing

 A mock that starts without error isn't the same as a mock that behaves correctly. Once all five were running on their expected ports, Claude used the api-testing skill's ad-hoc request capability to check each one directly. That included the less obvious cases: PATCH status transitions, and 404, 422, and 401 overrides for the failure paths. Postman's mock servers support exactly this kind of [status-code and scenario override](https://learning.postman.com/docs/design-apis/simulate-conditions), which is what makes it possible to test how the gateway handles a Notion 401 or a PayPal 422 without waiting for one to happen for real. ## What the Context Graph catches that a repo can't

 All five mocks passed verification, but Claude flagged two more dependencies the first pass hadn't covered: `calendar-sync-service`, which calls Nylas directly, and `demographic-service`, which calls Pergomalum directly. Neither was covered by the mocks built so far, because those mocks matched the gateway's own call patterns, not the patterns these two other services use. What matters isn't that there were two more dependencies. It's that `calendar-sync-service` doesn't exist in this local checkout at all. It lives in another repository I hadn't cloned. The only reason Claude knew it was there, and knew it called Nylas, was the Context Graph. A local search or a dependency scanner limited to the current filesystem would have missed it completely. Claude wired both: `demographic-service` reads the existing Pergomalum mock, and `calendar-sync-service` gets pointed at the existing Nylas mock too, with scenario files extended to cover each service's specific call patterns. That brought the total to seven local mocks covering the full chain, not five. ## Turn the wiring into pull requests

 Mocks that only exist on one laptop aren't worth much. Since the dependency wiring touched code in more than one repository, Claude opened two pull requests: one in the healthcare-demographics repo, one in the healthcare-infra repo. Each contained the environment variable overrides and the committed `postman/mocks/` folder for that service. Anyone pulling those branches gets the exact same local setup, on the same ports, without rerunning any of this discovery work themselves. ## Where this leaves you

 None of the individual pieces here are new. [Mock servers](https://blog.postman.com/using-mock-servers-throughout-the-api-lifecycle/) have let developers build against an unbuilt or unreliable API for a long time. What's different is that Claude didn't have to be told where every dependency lived. The Context Graph found that, including the one dependency sitting in a repo nobody had checked out. The plugin's skills took it from "here's what calls what" to a running local environment, without me carrying that information between steps by hand. Worth saying plainly: this gets you a working local environment, not a green light to ship. You still need to test against the real services before anything goes out the door. What it does buy you is an afternoon back. It's the one you'd otherwise spend hunting for every place a service reaches outside itself, before you can even start on the change you actually wanted to make. If you want to try this yourself, [install the Postman plugin](https://learning.postman.com/docs/reference/developer-resources/claude-code-plugin) for Claude Code and ask it to set up local mocks for a service you own. Read more about how [Postman works as a local development environment](https://blog.postman.com/postman-as-a-local-development-environment/) first if you haven't used Local Mocks before. ## Resources

- [Postman Local Mock Servers documentation](https://learning.postman.com/docs/design-apis/mock-apis/local-mock-servers)
- [Swapping external dependencies for Local Mock Servers](https://blog.postman.com/swapping-external-dependencies-with-local-mocks-servers/)
- [How to mock APIs locally during development](https://blog.postman.com/how-to-mock-apis-locally-during-development/)
- [Postman as a local development environment](https://blog.postman.com/postman-as-a-local-development-environment/)
- [Using mock servers throughout the API lifecycle](https://blog.postman.com/using-mock-servers-throughout-the-api-lifecycle/)
- [Create and run simulations in Postman](https://learning.postman.com/docs/design-apis/simulate-conditions)
- [Postman Context Graph overview](https://blog.postman.com/introducing-the-context-graph-api-one-map-of-your-api-ecosystem/)
- [Postman plugin for Claude Code](https://learning.postman.com/docs/reference/developer-resources/claude-code-plugin)
- [Postman plugin skills on GitHub](https://github.com/postmanlabs/postman-plugin/tree/main/skills)