Postman AI Engineer Now Answers API Questions From the Context Graph
Quick Reads
- Postman’s AI Engineer queries the Context Graph using plain-language prompts.
- It can identify API ownership, duplicate services, spec drift, and orphaned collections.
- The tool works inside Agent Mode, Slack, the CLI, and integrations like Claude and GitHub.
- Teams can map consumers of any endpoint before making changes.
- Connecting source code repos makes the graph significantly more powerful.
Postman has expanded what its AI Engineer can do. It can now query the Postman Context Graph to answer organisational questions about APIs, without any Slack archaeology or manual code review.
The Postman Context Graph is a live index of everything Postman knows about your APIs and how they connect. It maps APIs, specs, collections, environments, workspaces, monitors, mock servers, backend repos, frontend repos, route handlers, and call sites in source code. Edges between those nodes represent relationships, which collection calls which endpoint, which repo implements which route, and which service calls which downstream API.
When a developer asks the AI Engineer a question, it queries that graph first before generating any response. That approach grounds answers in real data rather than inference. The graph tells the agent what exists, who owns it, and how it connects. The agent then turns that into a readable answer. Developers can reach the AI Engineer through Agent Mode inside the Postman workbench, via Slack, through the Postman CLI, the Postman API, or integrations like Claude and GitHub.
The Postman Context Graph AI Engineer covers a wide range of practical use cases. Finding API ownership is one of the most common. A simple prompt asking who owns a specific endpoint returns the owning team, a workspace link, and the repo that contains the route handler. If two workspaces claim the same endpoint, the tool flags both, which is useful information on its own.
Before changing any API, teams can ask the AI Engineer to list every consumer of a given endpoint. The output includes backend call sites, frontend call sites, Postman Collections, mock servers, and monitors, grouped by owning team. That list tells engineers immediately whether a field rename is a one-team fix or a five-team coordination effort. Postman covered a full example of this in their managing downstream dependencies post.
Discovering duplication is another strength. Instead of searching by name, developers can describe what they want to build. The graph checks OpenAPI descriptions, schema shapes, and request/response payloads across collections. That cross-referencing approach surfaces existing services that a name-based search would miss entirely.
Spec drift is also addressable through the Postman Context Graph AI Engineer. Teams can ask the tool to compare OpenAPI specs against actual route handlers in connected repos, returning a list of endpoints where the spec and code disagree. For example, a prompt might return results like “POST /refunds: spec says amount is a string, code accepts a number.” That kind of finding previously required reading every route by hand.
Additionally, orphaned collections, those whose requests target endpoints that no longer exist, can surface in a single prompt. Postman’s own team ran the query and cleared out a dozen stale collections in an afternoon. One had a monitor that was passing because it checked for a status that wasn’t 500, against an endpoint deleted eleven months earlier.
Consistency audits are also possible. Teams can ask the AI Engineer to flag endpoints using inconsistent field naming conventions, non-standard pagination, or irregular error response shapes across all services, and receive a per-team report. Similarly, security posture queries can surface every endpoint that lacks authentication or that accepts API keys in the query string. Query-string API keys are a known bad practice because they appear in logs and referrer headers.
Beyond the conversational interface, Postman also provides a visual Context Graph view inside the workbench. Developers can select any node and see its neighbourhood, specs, collections, repos, and monitors, as direct edges. The view is useful for verifying the AI Engineer’s answers and for exploratory investigation without a specific question in mind.
Postman recommends connecting source code repos via Native Git to make the graph more detailed. Without repo connections, the graph still works. But with them, it can surface call sites in source code that no collection or spec would reveal.
The Postman Context Graph AI Engineer, as Postman describes it, turns what used to be days of digging into a few minutes of prompting. For API-heavy teams managing dozens of services, that shift in how they get answers about their own systems is a significant one.
