MANAGE & OPERATE
Context Graph API
Give your agents an authenticated, connected view of API and service relationships. Trace downstream impact, identify affected consumers, and catch breaking changes before you merge every line of code.
One graph, built from everywhere your APIs actually live
Connect what you already have
Your Postman workspaces, your GitHub repos, and your running services in New Relic. Connect once.
Every edge shows its work
Typed nodes, six typed edges, and evidence on each one: the commit it was seen at, and where the signal came from.
Answer impactful questions to accelerate your agentic SDLC
Blast radius, dependency chains, endpoint consumers, ownership.
How Context Graph works
Benchmarked: half the tokens, a third less waiting
Two runs over an estate of several hundred repositories. Same model, same questions, same tools, with and without the graph.
48%
fewer prompt tokens
Held for both Opus 4.7 and Sonnet 4.5.
36%
less time to an answer
Median wall-clock, Opus 4.7. Sonnet 4.5 fell 8%.
47%
lower cost per run
Fewer round trips, not a smaller context window.
September 2026 benchmarking, two models. Cost excludes the one-time graph build and ongoing re-ingestion.
Fewer tokens on every question we asked
Reduction in prompt tokens when the model queries the graph before it reads any code, Opus 4.7 over several hundred repositories. The savings come from fewer round trips: 45 tool calls per question instead of 70.
Chart will load when visible
See how the Context Graph helps with a multi-repo change
RESOURCES
Go deeper on Context Graph
Frequently asked questions
What is Postman Context Graph?
A continuously updated graph of your API estate. It ingests your Postman workspaces, code repositories, and runtime telemetry, then turns them into typed entities (APIs, endpoints, deployments, databases, teams) joined by typed relationships. Agents query that graph instead of reconstructing it from whatever files are open.
Which sources can Context Graph ingest?
Your Postman workspaces are the primary source: the specs, collections, and environments your teams already maintain. Beyond that, GitHub repositories scanned for OpenAPI, AsyncAPI, and service definitions, and New Relic for the deployments and telemetry a code scan cannot see.
How does the graph stay current?
Each source carries its own policy: a refresh interval, a webhook, or manual. Re-ingestion is incremental, so unchanged repositories are skipped and cost tracks your code churn rather than your estate size. Runtime connectors stream continuously.
What does Context Graph know about an API?
What it exposes, calls, and depends on at runtime. Which databases back it, which external services it talks to, which team owns it, where it is deployed, and what watches it. Every relationship carries its evidence, so you can tell a confirmed edge from an inferred one.
Can I use Context Graph through MCP?
An MCP server is on the way. Any MCP client you already run (your editor, your agent framework, your own harness) will be able to query the graph as a tool, without writing the HTTP request or handling the asynchronous polling yourself. The HTTP endpoint is available to early-access organizations now, and nothing you build against it is wasted when the MCP server ships.
When should I not use the graph?
When the answer is already in the files in front of you. Our benchmarking found that on a declared dependency, like who imports a module, go.mod answers outright: reading the repository scores 98% on its own and the graph adds nothing. It earns its keep on cross-boundary work.