Bridging API Workspaces and AI Memory: Building a Postman Connector for Cognee

A developer built the official Postman data-source connector for Cognee, an open-source memory layer for AI agents, during Mergetober 2026. The connector ingests Postman collections into Cognee as queryable knowledge graphs, rendering each endpoint into a discrete Markdown document with folder breadcrumbs and parameter tables, and uses dlt resource state to skip unchanged collections for incremental sync. It also handles upstream deletions by declaring write_disposition="replace" so removed collections fall out of staging and are orphaned from the graph.

Modern software teams manage hundreds of microservices and third-party APIs. Postman collections are the de facto living documentation for these services, housing endpoint routes, authorization requirements, request bodies, query parameters, and sample responses. However, AI agents and LLMs typically cannot access this institutional knowledge directly. Developers find themselves manually copying cURL commands and JSON payloads into ChatGPT prompts to ask: "What headers does our payment webhook require?" or "Which endpoint handles partial refunds?" In this article, we explore how we built the official Postman data-source connector for Cognee during Mergetober 2026. This connector automatically ingests Postman collections into Cognee, turning static API documentation into queryable AI knowledge graphs with incremental sync and upstream deletion handling. Cognee is an open-source memory layer for AI agents. Rather than dumping raw text into a stateless vector store, Cognee processes data through three distinct stages: cognee.add data : Stages documents or structured records. cognee.cognify : Parses content with an LLM to extract domain entities and relationships, constructing a persistent knowledge graph. cognee.search query : Queries the interconnected graph and vector indexes to retrieve precise contextual memory. To ingest external systems, Cognee relies on data-source connectors built on top of dlt data load tool sources. php Postman API v10 | v PostmanClient --- Rate-limit backoff and 429 Retry-After handling | v Sync Engine postman.py --- State cache checks collection updatedAt | +- Unchanged? --- Re-yield cached rows 0 detail network requests | +- Modified? --- Fetch collection schema and render documents | v Markdown Renderer renderer.py | Folder breadcrumbs, parameter tables, schemas v @dlt.resource postman documents | Tagged: DOCUMENT SOURCE ATTR = "postman" v cognee.add | v cognee.cognify | v Unified Knowledge Graph & Vector Memory Connecting Postman to Cognee requires solving three core architectural challenges: Postman collections are hierarchical trees: collections contain folders, folders contain subfolders, and items contain requests and responses. Ingesting this as raw JSON would cause Cognee's graph pipeline to mirror the JSON syntax rather than extracting meaningful API entities. Our markdown renderer renderer.py walks the tree up to 50 levels deep, transforming each endpoint into a discrete Markdown document: Orders Fulfillment Ship Package . POST /v1/orders/{id}/fulfill . Each request becomes an independent node in Cognee's graph, tagged with a deterministic composite ID f"{collection uid}:{item id}" . Hitting Postman's REST API on every sync cycle quickly exhausts rate limits. The connector tracks collection updatedAt metadata using dlt.current.resource state . On subsequent runs: updatedAt timestamp has not changed, the connector bypasses the detail API call entirely 0 API requests and re-yields document rows directly from the state cache. When an API collection is deleted or unshared in Postman, an AI agent should not continue answering questions based on obsolete endpoints. By declaring write disposition="replace" on the @dlt.resource and tagging DOCUMENT SOURCE ATTR = "postman" , the active snapshot only contains currently visible collections. Any removed collection falls out of staging, prompting Cognee's built-in orphan cleanup to purge outdated nodes and relations from the knowledge graph. Building for open-source production requires rigorous engineering discipline: client.py Retry-After headers on HTTP 429 rate limits. createdAt , content hash churn in Cognee. test postman.py You can run the connector out of the box in demonstration mode without a live Postman account: python import asyncio from cognee community connector postman import postman source async def main : Initialize the source falls back to sample Order API in demo mode source = postman source Cycle 1: Ingest documents documents = list source print f"Ingested {len documents } endpoint documents into Cognee staging." Inspect a document doc = documents 0 print f"ID: {doc 'id' }" print f"Title: {doc 'title' }" print doc "content" if name == " main ": asyncio.run main When connecting to live Postman workspaces, simply set your API key: export POSTMAN API KEY="your-postman-api-key" Then add and cognify in Cognee: python import cognee from cognee community connector postman import postman source async def ingest api docs : source = postman source await cognee.add source await cognee.cognify Query your API documentation results = await cognee.search "How do I authenticate refund requests?" print results Participating in Mergetober 2026 has been an incredible opportunity to expand Cognee's data ecosystem. By connecting Postman collections directly into Cognee's memory layer, developers can now build intelligent coding assistants, automated API auditors, and documentation agents that genuinely understand their services. Check out the code in the cognee-community repository https://github.com/topoteretes/cognee-community under packages/connector/postman/ Published for Mergetober 2026 by WeMakeDevs and Cognee