{"slug": "querying-the-postman-context-graph-with-the-ai-engineer", "title": "Querying the Postman Context Graph with the AI Engineer", "summary": "Postman's AI Engineer can now query the Postman Context Graph to answer organizational questions about API ownership, consumers, and duplication using natural language, according to a blog post by the company. The Context Graph indexes APIs, specs, collections, repos, and their relationships, grounding AI answers in real data. The post provides example prompts for finding owners, listing consumers, and detecting duplicate services, and notes that the AI Engineer is accessible from Agent Tasks, Slack, and soon the Postman CLI and API.", "body_md": "# Querying the Postman Context Graph with the AI Engineer\n\nMost of the questions I have about our APIs aren’t really code questions. They’re org questions. Who owns `/customers`\n\n? Do we already have an API that does user preferences, or should I build a new one? Which of these seventeen payment services is the one the mobile team actually uses?\n\nThose questions used to require Slack archaeology. You’d ping someone from three months ago, wait, get forwarded twice, and eventually land on the person who knows. Half the time you gave up and built the duplicate service anyway.\n\nThe [Postman Context Graph](https://blog.postman.com/managing-downstream-dependencies-with-the-ai-engineer/) is the answer to those questions once your APIs, specs, collections, and connected repos are in Postman. And the fastest way to interrogate it is by asking the [Postman AI Engineer](https://blog.postman.com/introducing-the-ai-engineer/) natural-language questions. In this post I’ll show you the prompts I actually use, what comes back, and what I’ve discovered about our own systems that I didn’t know before.\n\n## What you’re actually querying\n\nThe Context Graph is a live index of everything Postman knows about your APIs and how they connect. Nodes are APIs, specifications, [Postman Collections](https://learning.postman.com/docs/collections/collections-overview/), environments, workspaces, monitors, mock servers, backend repos, frontend repos, route handlers, and call sites in source code. Edges are the relationships between them: which collection calls which endpoint, which repo implements which route, which workspace owns which API, which service calls which downstream API.\n\nWhen you ask the AI Engineer a question about your ecosystem, it’s [querying that graph first](https://blog.postman.com/api-specification-drift-why-context-beats-code-alone/) before it writes anything. That’s what makes the answers grounded instead of hallucinated. The graph tells the agent what exists, who owns it, and how it’s connected. The agent turns that into an answer.\n\nYou can reach the AI Engineer from a few surfaces: from Agent Tasks inside the Postman workbench, from Slack, and (as it rolls out) from the [Postman CLI](https://learning.postman.com/docs/postman-cli/postman-cli-overview/), the Postman API, and integrations like [Claude](https://www.anthropic.com/claude) or GitHub. All of them hit the same graph.\n\n## The prompts I actually use\n\nI’ve grouped them by the question I’m trying to answer. Copy any of these into Agent Mode against a workspace you own and see what comes back.\n\n### Finding ownership\n\nNothing kills momentum faster than not knowing who to ping when an endpoint returns a 500 at 4pm. This is the prompt I lean on most:\n\n```\nWho owns the API that serves GET /customers/:id?\nReturn the team, the workspace, and the repo that implements the route handler.\n```\n\nYou get back the owning team, a link to the workspace, and the repo that contains the handler. If ownership is ambiguous (as in, two workspaces claim the same endpoint), the AI Engineer says so and lists both, which is itself useful information.\n\n### Finding consumers before you change something\n\nThis is the classic use case. Before you rename a field or deprecate a parameter, ask:\n\n```\nList every consumer of GET /customers/:id.\nInclude backend call sites, frontend call sites, Postman Collections,\nmock servers, and monitors. Group by owning team.\n```\n\nThe output is a real map of who’s on the hook if you make a change. I covered a full-run example of this in the [multi-repo changes post](https://blog.postman.com/managing-downstream-dependencies-with-the-ai-engineer/). What matters here is that even without doing the change, the answer alone tells you whether the field rename is a one-team conversation or a five-team coordination.\n\n### Discovering duplication\n\nEvery large org has this problem. Someone builds a service that already exists because they couldn’t find the existing one. Ask:\n\n```\nDo we have any existing API that manages user notification preferences?\nShow me endpoints, spec files, and collections that look like a match,\neven if they're named differently.\n```\n\nThe graph does more than a name match. It looks at OpenAPI descriptions, schema shapes, and the request/response payloads in collections. I’ve found duplicate services this way twice, both times by describing what I wanted to build rather than what I thought it might be called.\n\n### Finding drift between spec and implementation\n\nSpecs drift. A team ships a new required field and forgets to update the [OpenAPI specification](https://spec.openapis.org/oas/latest.html). Ask:\n\n```\nFor every API in the payments-workspace, compare the OpenAPI spec\nto the actual route handlers in the connected repo.\nList any endpoints where the spec and code disagree, with a short reason.\n```\n\nYou get a list like `POST /refunds: spec says amount is a string, code accepts a number`\n\n. This is the kind of finding that used to require reading every route by hand.\n\n### Finding orphaned collections and monitors\n\nCollections have a way of accumulating. Someone writes tests for an endpoint that gets deleted, and the collection lives on, running against nothing. Ask:\n\n```\nFind every Postman Collection in this workspace whose requests target\nendpoints that no longer exist in any API spec or route handler.\n```\n\nI ran this on my own workspace and cleared out a dozen collections in an afternoon. One of them had a passing monitor. Passing tests against an endpoint that hasn’t existed in eighteen months. That’s the sort of thing you want to know.\n\n### Auditing consistency across services\n\nLarger orgs care about consistency. Are we using camelCase everywhere? Do all endpoints paginate the same way? Ask:\n\n```\nReview the APIs in this workspace for design consistency.\nFlag any endpoints that use snake_case fields, non-standard pagination\npatterns, or inconsistent error response shapes. Give me a per-team report.\n```\n\nThe response is usually longer than you’d expect. It’s also the kind of report that’s hard to get any other way, because it requires looking at every endpoint across every service at once.\n\n### Auth and security posture\n\nYou can ask the graph what’s exposed and how:\n\n```\nList every endpoint across all APIs in this workspace that doesn't require\nauthentication, or that accepts API keys in the query string.\n```\n\nThe AI Engineer walks the specs, the collections, and the route handlers to find endpoints matching either condition. Query-string API keys are a [known bad pattern](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication) because they end up in logs and referrer headers. Finding them all in one query beats a codebase-wide grep.\n\n## What the Context Graph view looks like\n\nAlongside the AI Engineer, there’s a Context Graph view in the Postman workbench that renders the graph directly. You can pick a node (an API, a collection, a repo) and see its neighborhood: the specs that define it, the collections that call it, the repos that implement it, the monitors that guard it.\n\nI use the view for two things:\n\n**Sanity-checking the AI Engineer’s answers.** If the agent says four repos consume an endpoint, I can open the endpoint’s node in the graph view and see the four repos as edges. If a fifth one shows up in the view that the agent didn’t mention, that’s a bug I want to know about.**Serendipity.** When you’re clicking around the graph, you notice things. “Wait, why does the invoicing service call the auth API directly instead of going through the gateway?” That kind of question surfaces because the graph makes the connections visible.\n\nMost of the time I ask the AI Engineer a question and read the answer. The graph view is when I want to poke around without a specific question in mind.\n\n## Things I’ve discovered this way\n\nA few real findings from the last couple months. Yours will look different, but the pattern is similar:\n\n**Two teams shipping the same webhook signing logic** in different repos. Neither knew the other existed. The graph linked them because both implemented`POST /webhooks/verify`\n\n, and the AI Engineer surfaced the duplication when I asked “what do we have for webhook signature verification?”**A collection with a monitor** running twice an hour against an endpoint that had been deleted eleven months earlier. The monitor was passing because the endpoint returned a 404 and the assertion checked for “status is not 500.”**A frontend repo** that was still calling a v1 endpoint the backend team had assumed no one used. The team had migrated the “official” consumers a year ago and moved on. The graph found the old call site because it indexes the source code.**Three separate services that all validated email addresses** with slightly different regexes. Two of them accepted the third one’s test emails as invalid. This came out of a consistency audit prompt.\n\nNone of these are dramatic discoveries. They’re the kind of thing that would take days of digging without the graph and take about five minutes with it.\n\n## Tips from the trenches\n\n**Ask specific questions.** “Show me all the APIs” gets a long, unfocused list. “Show me all the APIs owned by the payments team that expose a webhook endpoint” gets a useful answer. The graph rewards specificity.\n\n**Ask the graph before you ask a person.** I’ve stopped writing Slack messages that start with “does anyone know who owns…”. Nine times out of ten the graph knows, and it doesn’t need to check its calendar.\n\n**Save the useful prompts.** I keep a running note of prompts that worked, so I can rerun them across workspaces. “Find orphaned collections” is a prompt I run monthly. “Compare spec to implementation” is one I run before every release.\n\n**Verify the surprising answers.** If the AI Engineer says something you don’t expect (a service you didn’t know called your API, an ownership that doesn’t match your mental model), open the graph view and check the edges yourself. Most of the time the agent is right and your mental model is stale. Occasionally the graph has a gap. Either way you learn something.\n\n**Connect your repos.** The graph gets much richer when it can see the backend and frontend code that actually calls your APIs, not just the collections. Set up [Native Git](https://learning.postman.com/docs/agent-mode/native-git/) on the workspaces you care about.\n\n## Try a few prompts today\n\nOpen [Postman Agent Mode](https://learning.postman.com/docs/use/agent-mode/overview) in a workspace with a few APIs and collections in it, and try these three in order. They build on each other:\n\n```\n1. List every API in this workspace and its owning team.\n2. For the top three most-called endpoints, list every consumer\n   grouped by owning team.\n3. Are any of those endpoints missing an OpenAPI spec, or drifting\n   from their spec? If so, describe the drift.\n```\n\nBy the third answer you’ll have a working map of what’s here, who uses what, and where the specs have quietly diverged from the code. That’s a solid two hours of investigation compressed into a few prompts.\n\n## Where this changes the work\n\nI used to spend a real chunk of every week piecing together things about our own systems by asking around. Some of that is a healthy part of team communication, and it isn’t going away. But the mechanical parts (who owns this, who calls this, is this a duplicate, is this drifting) shouldn’t require a person. Those are graph queries. Now they are.\n\nIf you want the fastest introduction, pick one thing you’ve been avoiding investigating and give the AI Engineer a specific prompt about it. The answer usually contains something you didn’t know.\n\n## Resources\n\n[Introducing the AI Engineer](https://blog.postman.com/introducing-the-ai-engineer/)on the Postman blog[Managing downstream dependencies with the AI Engineer](https://blog.postman.com/managing-downstream-dependencies-with-the-ai-engineer/)[Why context beats code alone for spec drift](https://blog.postman.com/api-specification-drift-why-context-beats-code-alone/)[Postman Agent Mode overview](https://learning.postman.com/docs/use/agent-mode/overview)in Postman Docs[Native Git](https://learning.postman.com/docs/agent-mode/native-git/)in Postman Docs[About Postman AI features](https://learning.postman.com/docs/getting-started/basics/about-ai)in Postman Docs[Postman Collections overview](https://learning.postman.com/docs/collections/collections-overview/)in Postman Docs[OpenAPI specification](https://spec.openapis.org/oas/latest.html)", "url": "https://wpnews.pro/news/querying-the-postman-context-graph-with-the-ai-engineer", "canonical_source": "https://blog.postman.com/querying-the-postman-context-graph-with-the-ai-engineer/", "published_at": "2026-08-11 16:00:00+00:00", "updated_at": "2026-08-11 16:13:00.328314+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Postman", "Postman AI Engineer", "Postman Context Graph", "Postman CLI", "Claude", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/querying-the-postman-context-graph-with-the-ai-engineer", "markdown": "https://wpnews.pro/news/querying-the-postman-context-graph-with-the-ai-engineer.md", "text": "https://wpnews.pro/news/querying-the-postman-context-graph-with-the-ai-engineer.txt", "jsonld": "https://wpnews.pro/news/querying-the-postman-context-graph-with-the-ai-engineer.jsonld"}}