Adding a New Service with the Context Graph and Claude Code

Adding a new service to an existing app is never just about the new service. You have to find the right endpoints and understand their schemas, build a collection around them, write tests that check the integration, and keep those tests running in CI and after the thing ships. None of that is hard on its own.

What’s hard is the part you can’t see from your own repository: an endpoint or schema change that quietly breaks a collection or test suite owned by a different service, sitting in a different repository, that nothing in your editor knows about.

I spent some time with Claude Code and the Postman plugin to see how much of that workflow could run as one connected flow instead of five disconnected ones. The short answer: most of it, through the Postman Context Graph.

What the Context Graph gives an agent

The Postman Context Graph is a live index of the services, endpoints, schemas, consumers, owners, deployments, environments, telemetry, and runtime call relationships you have access to. It resolves entities across those systems and builds the relationships between them, so an agent can ask something like “what depends on the billing service” and get a real answer instead of a guess built from whatever files happen to be open.

That distinction matters more than it sounds. Postman’s research on AI coding agents points to a failure mode showing up across frontier models. Agents degrade on long-context retrieval well before the context window fills up, and accuracy on information buried in the middle of a long prompt can drop by 30% or more. Dumping an entire monorepo into a prompt and hoping the model finds the right schema is not a context strategy. A graph that already knows which services exist and how they connect is.

Claude Code reaches the Context Graph through the Postman plugin for Claude Code, using the api-discovery skill. That’s one of around a dozen skills the plugin ships with, covering the rest of the API lifecycle too: building collections, writing tests, mocking, monitoring, and wiring up CI. This walkthrough touches most of them.

Adding a service with the Context Graph

I pointed this at a healthcare gateway app my team runs, myhealthcare.dev. It’s an app that mirrors the backend of a hospital, and it has different services for patients, doctors, medications, pharmacies, etc.

Using plan mode with Claude, I started to brainstorm this new service. I wanted to create a case management service that would open a case for a patient, and have lots of dependencies, including their doctor/provider, medications, insurance, etc. But how do I create that service and make sure all of the downstream dependencies do not break in the process? With the context graph.

The first thing Claude did before it started writing any code was use the api-discovery skill to ask the Context Graph what the downstream dependencies are for patients-service and providers-service, since those were foundational for this update. Once the Context Graph responded, Claude started to execute the plan: create the service, a new schema, a collection, tests, and then update the downstream dependencies.

Turn the API context into a collection

Once the schema existed, Claude turned the plan into a collection following the collection schema v3 format, using the collection-schema-v3 skill to keep the file structure consistent with the rest of the workspace. Then, using the api-testing skill, Claude wrote test scripts that check whether the new service behaves the way its contract says it should, not just whether the happy path returns something that looks plausible:

pm.test("Case opens with a 201", () => {
    pm.response.to.have.status(201);
});

pm.test("Case links the fields that matter", () => {
    const body = pm.response.json();
    pm.expect(body).to.have.property("id");
    pm.expect(body.patient_id).to.eql(pm.variables.get("patient_id"));
    pm.expect(body.provider_id).to.eql(pm.variables.get("provider_id"));
    pm.expect(body.referral_id).to.be.a("string");
    pm.expect(body.prior_auth_id).to.be.a("string");
    pm.expect(body.care_plan_id).to.be.a("string");
});

Running the collection pulled real test credentials through Postman Vault Integrations rather than a .env file sitting in the repository, which is the detail I’d most want a teammate to copy. Postman resolved the secret reference at run time, and the credential itself never touched a file Claude could read or commit.

Close the loop after deployment

Adding the service and writing tests covers the before-merge half of the problem. The other half is what happens after deployment, when either this service or one of the eleven others it talks to changes without anyone updating the other side. I asked Claude to handle both in one prompt: set up a monitor so the tests keep running after deployment, and add the same tests to the CI pipeline.

Claude worked through the rest in sequence. First, it generated a mock server from the collection and ran the test suite against it to confirm the contract held before touching anything live. It used the api-mocking skill to do this, then it used the ci-integration skill to wire the collection into a GitHub Actions Workflow.

Then it created a scheduled monitor against the same collection using the api-monitoring skill, so the contract check keeps running in production on a fixed interval instead of only at merge time. It also pushed the local workspace entities (collections, environments, specifications, and mocks) up to the shared workspace so the rest of the team could see them. Claude closed by opening a pull request with the frontend change, the schema migration, the new collection, the CI workflow update, and the monitor configuration together.

Where this leaves you

The fastest part of this whole walkthrough wasn’t writing the collection or the tests. It was the few seconds it took Claude to ask the Context Graph what patients-service and providers-service actually depend on, instead of me opening both repositories and tracing it by hand. Figuring out every place a dependency lives, checking that it’s still accurate, and hoping you didn’t miss one tucked away in a repo you don’t have open, that’s normally the part of adding a new, highly connected service that eats an afternoon. Here, it took one question.

That accuracy matters more than it sounds like it should. Postman’s own research on AI coding agents found that agents lose accuracy the more they have to hold in context at once, and dependency information scattered across a dozen repositories is exactly the kind of thing that gets lost, guessed at, or quietly skipped. The Context Graph sidesteps that problem: Claude didn’t have to reconstruct the dependency map from whatever files happened to be open. It asked a direct question through the api-discovery skill and got a direct, correct answer.

Everything after that followed from having the right map up front. Once Claude knew which services actually mattered, the Postman plugin for Claude Code carried the same information through the rest of the agentic SDLC in one pass: building the collection with the collection-schema-v3 skill, writing tests with api-testing, mocking the service with api-mocking, wiring CI with ci-integration, and setting up a monitor with api-monitoring. None of that meant switching tools, re-explaining the service, or re-checking the dependency list by hand at each step.

That’s the real speed and accuracy gain. Writing any one of those pieces, the collection, a test script, a monitor, doesn’t get much faster on its own. What’s faster is not having to rediscover the same dependency map five separate times and risk a slightly different, slightly wrong answer at each one. See the Postman Context Graph overview for more on how it builds that map, and how downstream dependencies get managed across an API lifecycle once you have one.

If you want to try this against your own repository, install the Postman plugin for Claude Code and ask it to map the dependencies for something you’re about to change. Push your own collections and specifications to your workspace first. The graph can only tell Claude about the dependencies it can see.

Resources

• Postman Context Graph overview
• Why AI coding agents need context graphs
• Managing downstream dependencies with the AI Engineer
• Postman plugin for Claude Code
• Postman plugin skills on GitHub
• Collections schema v3 reference
• Mock servers in Postman
• Monitor health and performance of your APIs
• Postman Vault Integrations