Teaching an AI assistant to forget a deleted Stripe customer

Description and use

A Cognee connector built a knowledge graph from Stripe billing data where deleted customers vanished from documents and the graph, renamed customers showed up under their new names, and later runs cost one request when nothing changed.

Problem

An AI assistant keeps telling people about a deleted Stripe customer, including what the customer pays and which invoice is open, even though nothing crashed and the data no longer exists in Stripe.

Outcome

A Cognee connector built a knowledge graph from Stripe billing data where deleted customers vanished from documents and the graph, renamed customers showed up under their new names, and later runs cost one request when nothing changed.

Workflow

• Build a Cognee connector that reads customers, subscriptions, invoices, charges, products and disputes from Stripe
• Store each object as a short document with allowed fields only, never raw card numbers or payment methods
• Connect related objects through shared nodes such as customer:cus_..., subscription:sub_..., product:prod_...
• Use Stripe events for later runs instead of date filters so old invoices are not missed
• Refresh charge disputed flags when dispute events only name the dispute
• Test against a fake Stripe with 62 tests first, then against a real free Stripe test account with a read-only key

Evidence

A customer asks to be deleted. Someone clicks delete in Stripe. A week later your AI assistant is still happily telling people what that customer pays and which invoice is open. It sounds completely sure. It is completely wrong.

Source

Billing data is a good test for a connector. Nothing in it stands alone. A charge belongs to an invoice, an invoice to a subscription, a subscription to a customer. If a connector loses those links, the assistant loses the story.

Source

Every object becomes a short document. Related objects stay connected. A customer, its subscription, the invoice, the charge and the dispute can all be reached from each other.

Source

Later runs read only what changed. Anything you delete in Stripe is forgotten.

Source

My plan was to treat Stripe rows as a relational table and let Cognee build the links from foreign keys. Then I checked. The staging tables dlt writes to SQLite have no foreign keys at all, even when you declare them. So the links would never appear.

Source

The fix was simpler. Every document lists the things it belongs to: customer:cus_..., subscription:sub_..., product:prod_.... Cognee stores those as shared nodes. Two documents that share a node are connected.

Source

Stripe's list calls can only filter by creation date. That sounds fine until someone pays an old invoice. The invoice was created last month, so a date filter never sees it again.

Source

So later runs read Stripe's events instead. One request asks what happened since last time. Then only the objects named in those events are fetched again.

Source

First I tested against a fake Stripe. 62 tests, no network. But a fake only proves what you thought to fake.

Source

Then I synced again without changing anything. One request. Nothing written.

Source

Then I renamed a customer and deleted another straight from the Stripe dashboard. The next sync made three requests, wrote one object and forgot one. The deleted customer vanished from the documents and from the graph. The renamed one showed up under its new name.

Source

My first real run printed every charge without a link to its invoice.

Source

In the