DEV Community: Darshan Rajput

cognee

Darshan Rajput — Sat, 31 Oct 2026 05:02:09 +0000

I Built a QuickBooks Connector for an AI Knowledge Graph — Here’s What I Learned

Darshan Rajput — Wed, 21 Oct 2026 04:53:34 +0000

What if you could ask AI questions about invoices, unpaid bills, and financial records instead of searching through them manually?

That’s the idea behind my latest open-source contribution to Cognee Community: a QuickBooks Online data connector.

🔗 Pull Request: https://github.com/topoteretes/cognee-community/pull/402

📌 Issue: https://github.com/topoteretes/cognee/issues/4802

🧠 What does it do?

QuickBooks stores useful business information, but AI systems need a way to ingest and understand that data.

I worked on a connector that brings QuickBooks financial records into Cognee's AI memory workflow.

The connector supports:

📄 Ingesting invoices, vendor bills, and credit memos.
🔐 OAuth 2.0 authentication and token refresh.
🔄 Incremental sync to retrieve new and updated records.
🗑️ Deletion detection to help remove outdated information.
🛡️ Retry handling and safeguards against accidental deletion.
🧪 Automated tests and offline pipeline verification using DuckDB.

⚙️ How does it work?

The basic workflow is:

QuickBooks → Python Connector → DLT → Cognee → Knowledge Graph

The connector retrieves financial records, formats them into readable Markdown documents, and sends them through Cognee's ingestion workflow.

For example, instead of working with raw invoice JSON, the system can process information such as customer names, invoice totals, payment status, and line items.

This makes the information more useful for downstream AI search and knowledge extraction.

🔍 The biggest challenge: keeping data in sync

Fetching records is only one part of building a reliable connector.

What happens when an invoice changes? What if someone deletes a record? And what if an API request fails and returns no data?

I worked on incremental synchronization using Metadata.LastUpdatedTime, deletion detection through QuickBooks Change Data Capture (CDC), and a fallback reconciliation mechanism.

I also added a safety check to prevent an empty synchronization sweep from accidentally marking previously known records for deletion.

The submitted test suite documents 12 passing tests, covering data formatting, synchronization, deletion handling, and retry behavior.

💡 What I learned

This contribution taught me that building a data connector is about much more than calling an API.

You need to think about data consistency, authentication, synchronization state, failure handling, and testing edge cases.

Working on these details gave me practical experience with Python, REST APIs, DLT, data pipelines, testing, and AI knowledge graphs.

🙌 Explore the project

My pull request: https://github.com/topoteretes/cognee-community/pull/402
Original issue: https://github.com/topoteretes/cognee/issues/4802
Cognee: https://github.com/topoteretes/cognee
Cognee Community: https://github.com/topoteretes/cognee-community

Thanks to the Cognee maintainers and community for creating opportunities to learn and contribute to open-source AI infrastructure.

The pull request is currently open for review, and I welcome feedback from other developers.

💬 Let's discuss!

##I Built a Brex Connector for Cognee: Bringing Business Expense Data Into AI Memory 🚀

Darshan Rajput — Mon, 19 Oct 2026 13:53:42 +0000

I Built a Brex Connector for Cognee: Bringing Business Expense Data Into AI Memory 🚀

What I learned building an open-source data connector during MergeTober by WeMakeDevs.

What if you could ask an AI assistant about business expenses instead of manually searching through transaction records, notes, and budgets?

That question captures the idea behind my recent open-source contribution to Cognee Community.

During MergeTober by WeMakeDevs, I worked on building a Brex data-source connector for Cognee. The work involved much more than fetching data from an API. I also had to think about how the data should be organized, how future syncs should work, and how to protect existing data when something goes wrong.

Here is what I built, how it works, and what I learned.

🌍 My entry into MergeTober

Open source can feel intimidating when you're starting out. You might wonder which project to choose, how to understand an unfamiliar codebase, or what maintainers expect from a contribution.

MergeTober gave me an opportunity to work on a real integration issue rather than build another standalone demo.

My workflow was straightforward:

Find an open issue that matches a real project need.
Understand the requirements and existing architecture.
Implement the feature and submit a pull request.
Document the work so other developers can understand it.

I chose a connector issue because I wanted hands-on experience with APIs, data engineering, and AI infrastructure.

🧠 Why connectors matter for AI

Consider a company that stores information across different tools. Expense records live in a financial platform, project updates live elsewhere, and important context is buried in notes.

Even a capable AI system cannot use information it cannot access.

Cognee is an open-source project focused on turning data into structured AI memory. Data connectors help bring information from external systems into that workflow.

That led me to a practical question:

How can we make business expense information available to an AI knowledge system in a useful, structured, and maintainable way?

My contribution was an attempt to solve that problem for Brex.

🔌 What I built: the Brex connector

Brex provides business expense and budget management capabilities. My connector brings selected Brex data into Cognee's ingestion workflow.

You can explore the implementation here:

The connector supports three data resources:

Resource	Information collected
Expenses	Amounts, merchants, categories, statuses, and dates
Memos	Expense notes and business justifications
Budgets	Budget limits, spending, and budget relationships

The interesting part is that these resources don't all need to be represented in the same way.

Expense memos can become readable documents for contextual knowledge extraction, while expenses and budgets can remain structured records for organized data processing.

This gives downstream workflows access to both business context and structured information.

⚙️ How the connector works

Here is the simplified architecture:

       Brex Platform API
                |
                v
       Authentication
       + Pagination
                |
                v
       Fetch Expenses,
       Memos and Budgets
                |
                v
       Transform the Data
          /          \
         v            v
   Document Mode   Structured Mode
         \            /
          v          v
          DLT Ingestion
                |
                v
          Cognee Workflow
                |
                v
        AI Knowledge Retrieval

Let's break down the engineering decisions behind it.

1. Authentication and API requests

The connector uses Bearer token authentication to access the Brex Platform API.

It also handles paginated responses, so the integration can retrieve records across multiple API pages rather than stopping at the first batch.

API integrations must account for failure cases, too. The implementation includes handling for authentication errors, permission errors, and rate limits.

2. Turning raw data into useful information

Raw API responses aren't always the best representation for an AI knowledge pipeline.

For example, consider an expense containing a merchant, amount, department, budget, and a note explaining why the purchase was necessary.

The connector can transform that context into a readable document card while preserving expenses and budgets as structured records.

This separation makes the data easier to consume in different downstream workflows.

3. Incremental synchronization

Fetching every record during every run can be inefficient as datasets grow.

The connector uses Brex's posted_at_start filter and stores synchronization state through DLT's resource-state mechanism to track the latest processed timestamp.

Subsequent runs can then use that timestamp to retrieve relevant new or updated expense records.

The important lesson: reliable integrations need to remember where the previous synchronization ended.

4. Handling deletions safely

One of the more interesting challenges was deletion reconciliation.

Suppose a record disappears from the source. Eventually, the destination should stop treating that record as current.

However, imagine the API temporarily fails while the connector is checking which records still exist. Treating an incomplete response as a complete snapshot could incorrectly mark valid records as deleted.

The implementation therefore includes a guardrail: if reconciliation encounters API or network errors, deletion-marker generation is aborted rather than proceeding with potentially incomplete information.

This is an important distinction between simply syncing data and building a connector that considers data integrity.

💻 What does using it look like?

The pull request includes a usage example following Cognee's API.

After installing and configuring the connector and providing the required Brex API credentials, the basic ingestion pattern looks like this:

import asyncio
import os
import cognee

from cognee_community_connector_brex import brex_source


async def main():
    source = brex_source(
        token=os.environ["BREX_API_TOKEN"],
        include=["expenses", "memos", "budgets"],
    )

    await cognee.remember(
        source,
        dataset_name="brex_spend",
        primary_key="id",
        write_disposition="merge",
        max_rows_per_table=0,
    )


if __name__ == "__main__":
    asyncio.run(main())

This example illustrates how the connector is configured and passed to Cognee's ingestion API. A complete setup also requires installing the relevant dependencies, configuring valid credentials with appropriate permissions, and checking the compatibility of the project's installed versions.

Once the data is ingested, it can be used in a Cognee search workflow according to the configured pipeline and supported query types.

For the full implementation and query example, see the pull request.

🧪 Testing is part of the feature

A connector should not be considered reliable just because it works with one successful API response.

The pull request includes offline unit tests for important paths, including:

Authentication and API error handling.
Pagination and data transformation.
Incremental synchronization state.
Deletion-marker generation and failure guardrails.

The PR also documents an end-to-end DLT pipeline run using DuckDB.

These tests matter because connectors operate at a boundary between systems. A mistake can affect not only the data being fetched but also what downstream applications believe is current.

I came away with a stronger appreciation for testing failure scenarios—not just the happy path.

📚 What I learned from this contribution

This project taught me several practical lessons.

Understand the existing architecture before coding. Following established connector patterns makes a contribution easier to review and maintain.

Think about synchronization from day one. Initial ingestion is only one part of the problem. Updates, deletion handling, and persistent state matter just as much.

Protect data when dependencies fail. A partial API response should not automatically be treated as the complete truth.

Treat documentation as part of the implementation. Clear setup instructions and realistic examples help other developers use a feature without first having to understand every line of code.

Most importantly, I learned that a meaningful open-source contribution often involves making many small engineering decisions correctly.

🙏 Thank you, Kunal Kushwaha, Cognee, and WeMakeDevs!

A big thank you to Kunal Kushwaha and the WeMakeDevs team for encouraging developers to build in public, learn by contributing, and participate in open-source initiatives like MergeTober.

Thank you to the Cognee team and community for maintaining the project and creating opportunities to work on real integration challenges.

I am also grateful to the maintainers and community members who helped with the issue assignment and contribution process.

Open source is about more than individual pull requests. It is about a community where developers can learn from one another and gradually help improve the tools everyone uses.

🔗 Explore the project

If you're interested in AI memory, data engineering, or contributing to open source, these resources are a good starting point:

My pull request: Brex spend data-source connector
Original issue: Add a Brex data-source connector
Cognee: Explore the main repository
MergeTober: Learn about the initiative

🚀 Your turn: build something useful

You don't need to start with a groundbreaking idea to contribute to open source.

Pick a real problem. Read the existing code. Ask questions when you need to. Test your implementation. Document what you learn.

That is how small contributions become useful improvements to real software.

My MergeTober journey is another step in that direction, and I'm looking forward to learning and contributing more.

Have you built an API integration or contributed to an AI open-source project? Share your experience in the comments. I'd love to learn what challenges you encountered.

##I Built SetuBrain: An AI Company Brain That Knows When NOT to Answer

Darshan Rajput — Sun, 18 Oct 2026 16:44:06 +0000

What if an AI agent could detect outdated policies, trace answers to evidence, identify conflicting instructions, and admit when it doesn't know the answer?

That's the problem I explored while building SetuBrain for the FalkorDB Graph Hackathon 2026.

Inspired by Y Combinator's Company Brain Request for Startups, SetuBrain aims to bridge scattered company knowledge and reliable AI execution.

🌐 Live Demo | 💻 GitHub Repository | 🎥 Watch the Project Video

🧩 The Problem with Traditional RAG

Company knowledge is scattered across PDFs, internal wikis, Slack conversations, policies, and approval records.

A typical Retrieval-Augmented Generation (RAG) system retrieves relevant text, but what happens when:

An old policy conflicts with a new one?
An answer requires connecting multiple departments and approvals?
Two documents contain contradictory instructions?
No approved procedure exists?

Retrieving information isn't the same as verifying it.

🧠 Why FalkorDB?

SetuBrain uses FalkorDB as its graph data layer to represent company knowledge as connected entities rather than isolated text chunks.

For example:

Department → Procedure → Application → Policy → Approver

Using Cypher queries, the system can traverse relationships, identify superseded policies, detect conflicts, and trace decisions to supporting evidence.

The goal is to make graph relationships part of the reasoning process—not just a visualization.

⚙️ How SetuBrain Works

1. Graph-powered knowledge: Represents departments, procedures, applications, policies, contacts, decisions, and evidence as connected nodes.

2. Policy verification: Uses graph traversal and supersession relationships to identify authoritative policies.

3. Conflict detection: Flags contradictory policies and supports human review before an uncertain instruction is treated as authoritative.

4. Human-in-the-loop learning: Escalates missing knowledge to subject-matter experts and incorporates approved updates into the graph.

5. Agent integration through MCP: Exposes graph-backed tools through a Model Context Protocol endpoint so compatible AI clients can access SetuBrain's capabilities.

6. Reusable agent skills: Compiles verified graph information into structured SKILL.md specifications.

7. Multi-tenant architecture: Separates tenant knowledge contexts using graph selection, with access controls required to enforce isolation securely.

📊 Testing the Approach

In SetuBrain's documented 15-question enterprise benchmark, the results were:

Approach	Correct answers	Accuracy
Flat vector RAG baseline	4/15	26.7%
SetuBrain graph approach	15/15	100%

These results apply to this specific test set, not every RAG or graph-based system. The benchmark explores multi-hop reasoning, outdated policies, contradictions, missing knowledge, and evidence provenance.

The key takeaway: vector retrieval and graph traversal solve different problems and can complement each other.

🛠️ Tech Stack

Next.js & TypeScript — Application and interface
FalkorDB & Cypher — Graph storage and relationship traversal
MCP — Integration with compatible AI agents
Three.js — Interactive 3D knowledge graph visualization
AI agent workflows — Conflict review, expert escalation, and skill generation

🔗 Explore SetuBrain

💭 My Biggest Takeaway

Building SetuBrain reinforced one important principle:

A reliable AI system should know what is approved, what is outdated, what conflicts, and when human judgment is needed.

The future of enterprise AI isn't just about generating better answers. It's about building systems that can verify their knowledge and handle uncertainty responsibly.

💬 Question for developers: Would you trust a graph-powered AI agent to manage company knowledge? What would you build differently?

Explore the repository, share your feedback, and let's build more reliable AI systems together!

AI #GraphRAG #FalkorDB #OpenSource

I made my contribution to open source with Mergetober!

Darshan Rajput — Wed, 14 Oct 2026 15:50:11 +0000

## Integrating Clay Enterprise with Cognee Using dlt

For Mergetober, I worked on building a connector that brings Clay Enterprise data into Cognee using dlt's REST API source.

The main goal was to make it easier to bring structured data from Clay tables into Cognee. I worked on configuring the API endpoint, request parameters, and pagination so the connector could fetch data from the API.

Pagination was an important part of the implementation because the API can return data across multiple pages. The connector needs to handle those pages to retrieve the available records properly. I also worked on preparing the data so it could be used in Cognee's ingestion workflow.

I tested the implementation with unit tests and a real Clay Enterprise workspace. Working on this connector gave me a chance to contribute to an open-source project and explore how data integrations can connect external sources with AI applications.

You can check out my contribution here: Clay Enterprise connector for Cognee — PR #313.

Acknowledgments

A big thank you to WeMakeDevs for organizing Mergetober and giving developers a chance to contribute to open source. Thanks to the Cognee team for building the project and making this contribution possible. I'd also like to thank Kunal Kushwaha for encouraging and supporting the developer community.

I'm glad I got the opportunity to contribute to Cognee through Mergetober. It was a great way to get involved in open source and work on a practical integration.

🚀 Building an AI memory integration cognee! I’m contributing to the open-source Cognee ecosystem by working on a Salesforce connector that aims to bring CRM data closer to AI-powered knowledge workflows. 🔹 Salesforce data ingestion

Darshan Rajput — Tue, 13 Oct 2026 04:57:26 +0000

Darshan Rajput

Oct 13

Inside My MergeTober Contribution: Integrating Salesforce with Cognee

#opensource #ai #salesforce #cognee

3 min read

Inside My MergeTober Contribution: Integrating Salesforce with Cognee

Darshan Rajput — Tue, 13 Oct 2026 04:53:29 +0000

Introduction

AI agents are only as useful as the information they can access. But business knowledge often lives in separate tools, such as CRM platforms, documents, and communication systems.

That is why I participated in MergeTober, contributing to the open-source Cognee ecosystem by working on a Salesforce connector.

Cognee provides a memory layer for AI agents, helping turn data into connected knowledge that can be retrieved by downstream applications. My contribution aims to make Salesforce CRM data available to those workflows.

Why Connect Salesforce with Cognee?

Salesforce contains valuable business information, including customer accounts, sales opportunities, support cases, and Chatter conversations.

Connecting this data to Cognee could help developers build AI applications that retrieve relevant business context instead of relying only on isolated records.

The goal of my connector is to support:

Authentication: OAuth 2.0 with a Salesforce Connected App.
Data ingestion: Accounts, Opportunities, Cases, and Chatter records.
Incremental synchronization: SOQL queries using LastModifiedDate.
Deletion handling: Detect deleted source records and support downstream cleanup.
Testing and documentation: Unit tests, setup instructions, and a runnable example.

How It Could Work in the Real World

Imagine a sales team using a CRM knowledge assistant.

A representative asks:

“What open opportunities are associated with this customer, and are there any related support cases?”

A configured application could retrieve relevant Salesforce records through the connector, process the information with Cognee, and use the resulting knowledge as context for an answer.

This is an illustrative use case, not a claim that I have tested a complete assistant against a live Salesforce organization.

Incremental synchronization could help keep the information current, while deletion handling could help prevent outdated source records from remaining in the knowledge system.

Testing My Contribution

I tested the connector locally using mocked Salesforce responses and verified that 9 out of 9 mocked unit tests passed.

These results validate the behavior covered by those tests. They do not independently establish that authentication, synchronization, and knowledge retrieval have all been verified against a live Salesforce environment.

My pull request is currently open and awaiting review.

View my Salesforce connector PR on GitHub

Why MergeTober Matters

I appreciate MergeTober's focus on building integrations that solve real problems. Code demonstrates what we build, while a practical blog post helps other developers understand why it matters and how they might use it.

Contributing to open source is an opportunity to learn, collaborate, and create tools that others can build upon.

A special thank you to Kunal Kushwaha, Founder of WeMakeDevs, for creating opportunities that encourage developers to contribute to meaningful open-source projects.

Thank you also to the Cognee team and community for building an open-source memory layer for AI agents and supporting its growing integration ecosystem.

Learn more about Cognee at cognee.ai.

Conclusion

My MergeTober contribution explores how Salesforce CRM data can become part of AI knowledge workflows through authentication, structured ingestion, incremental synchronization, and deletion handling.

With my local mocked tests passing and the pull request awaiting review, I look forward to continuing to improve the contribution through feedback and validation.

I'm excited to contribute to open source and explore how connected business knowledge can make AI applications more useful.

DEV Community: Darshan Rajput

cognee

I Built a QuickBooks Connector for an AI Knowledge Graph — Here’s What I Learned

🧠 What does it do?

⚙️ How does it work?

🔍 The biggest challenge: keeping data in sync

💡 What I learned

🙌 Explore the project

💬 Let's discuss!

##I Built a Brex Connector for Cognee: Bringing Business Expense Data Into AI Memory 🚀

I Built a Brex Connector for Cognee: Bringing Business Expense Data Into AI Memory 🚀

🌍 My entry into MergeTober

🧠 Why connectors matter for AI

🔌 What I built: the Brex connector

⚙️ How the connector works

1. Authentication and API requests

2. Turning raw data into useful information

3. Incremental synchronization

4. Handling deletions safely

💻 What does using it look like?

🧪 Testing is part of the feature

📚 What I learned from this contribution

🙏 Thank you, Kunal Kushwaha, Cognee, and WeMakeDevs!

🔗 Explore the project

🚀 Your turn: build something useful

##I Built SetuBrain: An AI Company Brain That Knows When NOT to Answer

🧩 The Problem with Traditional RAG

🧠 Why FalkorDB?

⚙️ How SetuBrain Works

📊 Testing the Approach

🛠️ Tech Stack

🔗 Explore SetuBrain

💭 My Biggest Takeaway

AI #GraphRAG #FalkorDB #OpenSource

I made my contribution to open source with Mergetober!

Acknowledgments

🚀 **Building an AI memory integration cognee!** I’m contributing to the open-source Cognee ecosystem by working on a Salesforce connector that aims to bring CRM data closer to AI-powered knowledge workflows. 🔹 Salesforce data ingestion

Inside My MergeTober Contribution: Integrating Salesforce with Cognee

Inside My MergeTober Contribution: Integrating Salesforce with Cognee

Introduction

Why Connect Salesforce with Cognee?

How It Could Work in the Real World

Testing My Contribution

Why MergeTober Matters

Conclusion

🚀 Building an AI memory integration cognee! I’m contributing to the open-source Cognee ecosystem by working on a Salesforce connector that aims to bring CRM data closer to AI-powered knowledge workflows. 🔹 Salesforce data ingestion