September 2026 Summaries

Postman has launched a Codex plugin that integrates Postman agent skills into OpenAI Codex sessions, enabling developers to discover, test, mock, and evaluate APIs through natural-language requests rather than manually using CLI commands. The plugin can be installed either project-wide through the Postman CLI, which stores skill files in a repository and links it to a Postman workspace, or directly from the Codex plugin marketplace, which also connects an authenticated MCP server. Its API-discovery capability searches internal Postman workspaces and dependency context before suggesting public APIs through Orbit, while its context graph can identify potential downstream effects of API schema changes, though results should be verified because the graph updates nightly. The API-mocking skill can generate local mock backends from collections or OpenAPI specifications, create configurable scenarios such as empty data or server failures, add reusable test collections and environment configuration, and run the resulting test suite. An additional AI-readiness skill assesses whether an API provides enough error-handling information for agents to recover from failures.

Traditional secrets management has progressed from hard-coded credentials to environment variables, centralized vaults, and local credential helpers, but each approach still gives the calling application the plaintext secret at runtime. The passage argues that this model becomes riskier with AI agents, which can dynamically select tools, processes, and endpoints, making it difficult to predict where inherited credentials may be used or exposed. It proposes replacing distributed secrets with credential references that are resolved by a secure proxy within an organization’s network, allowing the proxy to inject credentials while callers never receive them. This access-oriented approach supports cryptographically bound identities, operation-level permissions, per-consumer revocation, and detailed attribution across people, CI pipelines, and agents. Postman Passport is presented as an implementation of this model, integrating with existing secret stores to keep credentials within private networks while granting scoped, revocable API access.

Agentic development expands credential risk by allowing tools and subprocesses to make runtime-selected network calls using secrets inherited from environment variables, keychains, configuration files, and credential helpers, making static secret inventories incomplete. In a three-week experiment using Postman Passport, the author observed 22 distinct credentials across 33 requests to 18 hosts despite identifying only four entries in a project’s .env file, illustrating the difference between where secrets are stored and where they travel. Key findings included credentials embedded in URL query parameters, which are more likely to persist in logs and histories; a single API key shared by separate programs, preventing selective revocation; credentialed requests with no identifiable client; and agents sending tokens to third-party Model Context Protocol servers, creating delegation and token-replay concerns. The account argues for replacing copied, reusable secrets with granular, holder-bound access references mediated by a secure proxy, while recommending runtime traffic inspection, per-consumer credentials, regular MCP audits, and process-level attribution where needed. It also reports that using a Context Graph API reduced agent search-related tool calls, tokens, latency, and costs, suggesting that better retrieval can reduce unnecessary subprocesses and credential-bearing network activity, though it does not eliminate essential authenticated calls.

JevPong is a Pong game that demonstrates Jev, TypeSafe’s System One AI model, by letting players compete against an agent that makes rapid, structured decisions about paddle movement, return style, shot placement, and boost usage. Rather than producing language or long explanations, Jev evaluates the game state through typed Choice, Score, and yes-or-no probability questions, returning actions with probabilities and confidence levels. Players can select Easy, Medium, or Hard difficulty and inspect Jev’s choices, latency, confidence, and fallbacks through a Decision Monitor while racing to seven points. The game maintains responsiveness by running browser physics separately from Jev’s decision requests and discarding late, low-confidence, or outdated responses when necessary. Its backend uses Postman Fabric Gateway to securely route requests to Jev, centralize credential management, and provide shared monitoring, analytics, auditing, and tracing, illustrating an architecture that other applications could reuse.

Postman’s Context Graph API is presented as a private, authenticated knowledge graph designed to give coding agents organization-wide operational context beyond a single repository, including APIs, services, schemas, deployments, runtime calls, telemetry, external systems, and ownership information. By connecting existing data sources through Postman, organizations can create a graph that refreshes nightly and can be queried asynchronously through a single `/asks` endpoint to identify likely dependencies and potential blast radius before code changes are made. In a controlled benchmark spanning 468 repositories, three models, and infrastructure-related questions, Postman reports that graph-assisted agents used fewer tokens, made fewer tool calls, reduced costs, and improved accuracy in most prompt-model comparisons, particularly for runtime dependencies that cannot reliably be found through code search alone. The company emphasizes that graph results are intended as leads that agents must still verify in source code, acknowledges that its index may not precisely match the tested code version, and argues that missing operational evidence—not necessarily model capability—is a major cause of cross-service failures. Postman says the API works with existing models and development environments, uses typed nodes and sourced relationships to reconcile code, specifications, and production signals, and will also become available through the Model Context Protocol.

An internal release-readiness tool prompted a comparison of three ways for AI agents and automation to access the GitHub API: typed SDKs, command-line interfaces, and MCP servers. The author concludes that each fits a different caller: SDKs such as Octokit suit scheduled production jobs because type checking and build-time failures improve reliability, GitHub’s gh CLI suits interactive agent sessions because it supports ad hoc commands and compact JSON output without preloading tools, and MCP is best for broad, exploratory, multi-user access because it provides discoverable structured tools and per-user authorization. MCP’s main drawback is potentially substantial context-window consumption from tool definitions, though scoping toolsets, using read-only mode, and emerging deferred tool loading can reduce this cost. Rather than treating the options as competitors, the piece recommends generating all three interfaces from a single OpenAPI specification to avoid maintenance drift, using tools such as Fern for SDK and CLI generation and Postman’s MCP Generator for an MCP server, while emphasizing structured CLI output, read-only permissions, and careful measurement of MCP token overhead.

Postman Monitors now support gRPC and GraphQL requests in beta, allowing teams to schedule existing collection requests with their configured authentication, variables, and test scripts rather than relying on separate synthetic-monitoring tools or custom cron jobs. Supported capabilities include unary and server-streaming gRPC calls, plus GraphQL queries and mutations over HTTP, with validation using familiar Postman scripting objects such as pm.response; GraphQL checks should inspect response errors and data rather than HTTP status alone, since GraphQL can return errors alongside a 200 response. Server-streaming requests can be tested per message or after completion, although the beta currently limits client-streaming and bidirectional calls to one client message and does not yet support GraphQL subscriptions. Users can configure monitor frequency, regions, environments, and notifications, while the guidance recommends dedicated secret-based monitor environments and narrowly focused collections for clearer incident diagnosis. Postman is seeking beta feedback through its GitHub support repository, particularly on streaming patterns, subscription use cases, and desired assertion helpers, with multi-message streaming, subscriptions, and richer stream testing planned for future releases.

API gateways have long managed API traffic through routing, authentication, rate limits, transformations, and observability, but AI agents introduce a different challenge because they dynamically choose models, tools, actions, and workflows while pursuing high-level goals. LLM gateways address model-specific concerns such as provider routing, token costs, prompt security, and reliability, while MCP gateways centralize access to Model Context Protocol tools, credentials, permissions, discovery, and auditing. An agent gateway is presented as a broader control and enforcement layer spanning models, APIs, MCP tools, memory, other agents, and human approval processes, governing an entire stateful agent execution rather than isolated requests. Its proposed functions include identity propagation, least-privilege access controls, policy enforcement, sensitive-data redaction, budget and execution limits, loop detection, workflow-level tracing, and approval requirements for risky actions. The discussion argues that these capabilities are necessary because agents can take consequential actions, operate across delegated and multi-step workflows, encounter prompt-injection and tool-output risks, and create observability and cost-management challenges that conventional gateways cannot fully address. Postman describes its planned Fabric Gateway as a unified platform intended to combine API governance, model routing, MCP management, and agent-level policy controls for production agentic systems.

Loop engineering is presented as an approach to AI coding in which agents repeatedly generate code, run it against a real system, evaluate the result through a reliable pass/fail oracle, and revise until the oracle confirms correctness or an iteration limit is reached. Using an Open-Meteo forecast client as an example, the text shows how code can compile and return valid data while still violating an unstated requirement, such as returning Celsius rather than Fahrenheit. It proposes keeping a version-controlled Postman collection as an inaccessible oracle that tests live API responses, while a restricted subagent runs the collection and returns failure messages to the coding agent without exposing the test source. This separation is intended to prevent agents from merely tailoring code to visible assertions and instead lets concrete API behavior guide corrections. The discussion emphasizes that tools such as Postman or Claude Code are interchangeable components of a broader pattern whose effectiveness depends on explicit machine-verifiable requirements, defined iteration budgets, capability boundaries, and logged feedback, while acknowledging that subjective or untestable goals still require human judgment.

Salesforce custom fields can silently alter API payload requirements, causing lead-creation requests to fail with `REQUIRED_FIELD_MISSING` errors and frontend applications to encounter unfamiliar response fields when teams are not notified of schema changes. The described approach uses Postman AI Engineer to inspect a failing request, response, collection, environment variables, and OpenAPI specification, identify a newly required Salesforce field, and generate a coordinated pull request updating frontend code, Postman requests, specifications, and drift-detection tests. Postman Agent Automations can then run on new repository pull requests to compare collection changes with downstream frontend artifacts, add required fields, remove obsolete usages, or update validation and types while leaving changes available for review. Important considerations include Salesforce field-level security, which may still prevent writes after a field is added; compile-time errors from regenerated required types; choosing an appropriate Postman agent for private networks; and separating automations by artifact type for clearer, faster results. The pattern can also be applied to other services with live schemas that change without explicit versioning, such as HubSpot custom properties and internal APIs.

Orbit by Postman is presented as a tool for discovering and integrating APIs based on plain-language tasks rather than provider names, returning callable endpoints, capability evaluations, and integration guidance through search and integrate functions or an MCP connection for AI agents. In a healthcare scheduling example, the author uses Orbit to find Nylas endpoints for checking clinician calendar availability, creating appointment events, and emailing patients after bookings, then receives a taskBrief covering fit, authentication, base URL, request steps, response details, and implementation cautions. The brief highlights operational details such as epoch-second timestamps, nullable calendar fields, pagination for conflict checks, separate mutations, and idempotency keys for safe email retries, reducing reliance on documentation searches and trial-and-error failures. The resulting implementation places calendar synchronization in a separate Kafka consumer so external API outages do not interrupt appointment booking, while the author advises using specific outcome-oriented search terms, reviewing endpoint evaluation notes for unsupported functionality, and consulting integration gotchas before writing client code.

Three-way API drift can arise when an OpenAPI specification, the Postman Collections that represent actual client behavior, and a running server’s observed responses each differ in ways that pairwise checks may not fully reveal. The described Postman AI Engineer and Context Graph approach treats specifications, collection requests and assertions, monitored live traffic, environments, ownership, governance rules, and historical versions as connected, timestamped artifacts, enabling endpoint-level comparisons that identify whether the spec, client collection, server, or multiple sources are misaligned. Examples include response types changing from integers to strings, undocumented enum values such as “refunded,” differing status-code expectations, obsolete error formats, and inconsistent authentication methods. The workflow uses a published spec, a collection that exercises the API, and recent monitor data or collection runs, then supports follow-up questions about which source should be trusted, affected downstream consumers, and potential specification patches. The account recommends incorporating these checks into pull-request review while recognizing that observed drift may sometimes reflect intentional feature flags or stale traffic rather than defects.