DEV Community

Cover image for Introducing Postman Code - Making Agents Better At Integrating APIs
Josh Dzielak 🔆
Josh Dzielak 🔆

Posted on

Introducing Postman Code - Making Agents Better At Integrating APIs

Hi, I'm Josh. I'm a staff engineer at Postman, and this is my first post on DEV about a project I've been working on called Postman Code.

Postman Code is a set of MCP tools that let your agent:

  • Search for APIs — both public APIs on the Postman API Network and your team's internal workspaces and collections
  • Fetch all API context — bring authentication patterns, request shapes, response examples, variables, and error cases directly into context
  • Generate integration code — produce complete, maintainable client code that follows your project's conventions

Why does this matter? Two reasons.

First, your agent works from accurate API definitions—Postman collections that contain authentication patterns, request formats, response shapes, and error cases. These aren't scraped docs or training data; they're the same definitions teams and companies use to test and document their APIs.

Second, your agent follows structured instructions that guide how code gets generated: preparing request bodies, generating types, handling errors, matching your project's conventions. And because the generated code stays linked to its source collection, your agent can detect when the API changes and regenerate the client to match.

When API Vibe Coding Goes Wrong

To see why accurate API definitions matter, consider what happens when agents don't have them. They fall back on training data or web search—and the result is code that looks correct but isn't. These failures tend to fall into a few predictable categories, for example:

Wrong response shape. The agent assumes a structure that doesn't match reality:

// Agent generated this (wrong path)
const userName = response.data.user.name;

// Actual response nests it differently
const userName = response.user.profile.display_name;
Enter fullscreen mode Exit fullscreen mode

Wrong authentication flow. The agent remembers an older auth pattern, or guesses based on what's common:

// Agent generated this (wrong — uses Bearer token)
const response = await fetch("https://api.example.com/v2/users", {
  headers: { "Authorization": `Bearer ${apiKey}` }
});

// API actually requires Basic auth
const response = await fetch("https://api.example.com/v2/users", {
  headers: { "Authorization": `Basic ${btoa(`${clientId}:${clientSecret}`)}` }
});
Enter fullscreen mode Exit fullscreen mode

Missing required fields. A new required field was added after the agent's training cutoff:

// Agent generated this (missing required field)
const payment = await acmepay.charges.create({
  amount: 1000,
  currency: "usd",
});

// API now requires 'payment_method' to be specified
const payment = await acmepay.charges.create({
  amount: 1000,
  currency: "usd",
  payment_method: "card",
});
Enter fullscreen mode Exit fullscreen mode

The agent isn't doing anything wrong—it just doesn't have access to the real API definition. You only find out when you hit a 401, a 400, or a subtle data bug at runtime.

This is the problem that Postman Code solves. It gives your agent access to Postman collections and environments that contain all the context the agent needs to give correct answers and generate correct code the first try. In practice, this context includes:

  • Collection documentation — overview, auth patterns, base URLs
  • Folder structure and docs — how endpoints are organized and grouped
  • Request definitions — method, URL, headers, body schema with required and optional fields
  • Saved response examples — actual response shapes for success and error cases
  • Environment and collection variables — base URLs, API versions, configuration, placeholders for secrets

Get Started in 2 Minutes

Postman Code is part of the Postman MCP server, which has several toolsets for different use cases. For API exploration and code generation, you'll connect to the code toolset—here's how.

You'll need a Postman API key (a free Postman account is enough).

Cursor

Add this to .cursor/mcp.json:

{
  "mcpServers": {
    "postman": {
      "url": "https://mcp.postman.com/code",
      "headers": {
        "Authorization": "Bearer <POSTMAN_API_KEY>"
      }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Claude Code

claude mcp add --transport http postman https://mcp.postman.com/code \
  --header "Authorization: Bearer <POSTMAN_API_KEY>"
Enter fullscreen mode Exit fullscreen mode

VS Code

{
  "servers": {
    "postman": {
      "type": "http",
      "url": "https://mcp.postman.com/code",
      "headers": {
        "Authorization": "Bearer ${input:postman-api-key}"
      }
    }
  },
  "inputs": [
    {
      "id": "postman-api-key",
      "type": "promptString",
      "description": "Enter your Postman API key"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Prompts and Use Cases

Once connected, Postman Code fits into the natural workflow of working with an API. You can explore an API before committing to it, generate integration code when you're ready to build, and keep that code in sync as the API evolves over time.

Exploring APIs

Before writing any code, you might need to find the right API for your use case, compare options, or understand how a specific API's authentication and endpoints work.

Public APIs

Your agent can search the Postman API Network and explore any public collection. Thousands of companies like Discord, Datadog, and HubSpot publish their official API collections there—and your agent can explore them directly: what endpoints exist, how authentication works, which requests are commonly used together, and what the response shapes look like.

"Explore the Slack API and explain the main ways to post messages. Use Postman."

Note: Adding "Use Postman" ensures the agent will the provided Postman tools. You can also add this as a rule in your IDE so it applies automatically—for example: "Any request involving an API must use Postman tools."

"Show me how authentication works for the Twilio API and which endpoints are typically used together."

This is especially useful for large or unfamiliar APIs where reading raw docs is overwhelming.

Internal APIs

For private or internal APIs, your agent can access collections from your Postman workspace. If your team documents APIs in Postman, those same definitions are now available to your agent.

"Explore our internal payments service API and show me how to initiate a refund."

"What endpoints are available in our User Service postman collection?"

Integrating APIs

When you're ready to generate code, you can work at whatever level makes sense.

Sometimes you have a high-level goal and want the agent to figure out which API requests to use:

"Build a Slack bot that posts a welcome message when someone joins a channel."

"Create a script that sends an SMS notification when a background job fails."

Other times you already know exactly which requests you need:

"Generate a typed client for the Notion Search endpoint."

"Create a function that calls our internal payments API's refund endpoint."

Either way, the agent fetches the real request definitions from Postman and generates code that matches your language, style, and conventions.

Syncing API Changes

APIs change over time. Endpoints get deprecated, required fields get added, authentication flows evolve. Just like you'd keep your dependencies up to date, you need to keep your API integrations current.

Postman Code‑generated files include metadata that links them back to the exact collection and request they came from:

/**
 * Generated by Postman Code
 *
 * Collection: Notion API
 * Collection UID: 15568543-d990f9b7-98d3-47d3-9131-4866ab9c6df2
 *
 * Request: Search > Search
 * Request UID: 15568543-816435ec-1d78-4c55-a85e-a1a4a8a24564
 * Request modified at: 2022-02-24T23:01:58.000Z
 */
Enter fullscreen mode Exit fullscreen mode

Because that linkage is explicit, you can ask the agent to reason about changes over time.

For example:

"Check whether the Notion API search request has changed since this client was generated, and update the code if needed."

"Compare our generated Slack client with the latest collection and show me what would change."

The diff is visible, reviewable, and easy for teammates to understand — just like any other code change.

If you want to see working examples, check out the example projects on GitHub — including a Notion CLI and a Stripe payments demo.

Conclusion

Postman Code came out of a pattern we kept seeing: agents are excellent at writing application logic, but they struggle at the API boundary.

The goal is to close that gap in a way that fits naturally into existing development workflows. API integrations stay explicit, reviewable, and grounded in the same source of truth teams already use.

How are you integrating with APIs today? What challenges do you run into, and how are you solving them? I'd love to hear in the comments.

And if you try Postman Code, let me know how it goes—we're always looking for feedback. Thanks for reading!

Learn More

Top comments (0)