cd /news/ai-agents/i-connected-contentful-to-cognee-imp… · home › topics › ai-agents › article
[ARTICLE · art-147700] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

I connected Contentful to Cognee. Importing content was the easy part.

A developer built a Contentful connector for Cognee that imports published content into the AI memory system and keeps it synchronized, including handling deletions that timestamp-based syncing misses. The connector uses Contentful's native Sync API to capture DeletedEntry and DeletedAsset events, converting them into dlt hard-delete markers so Cognee can purge obsolete documents along with their graph and vector data. It also imports content models separately for field context, tracks per-source sync state via a source_id, and refuses to save a checkpoint unless every pagination page is processed, with a local verification report recording 94 passing tests.

by read4 min views4 publishedOct 8, 2026

Built for the WeMakeDevs × Cognee Mergetober 2026.

Imagine running an online store where hundreds of products are managed in Contentful.

You want an AI assistant that can answer questions about those products using Cognee's memory.

Getting the content into Cognee is one problem. Keeping that memory correct when someone edits or deletes a product is another.

Say a product's warranty changes from two years to one. Or the product gets discontinued entirely.

If Cognee still remembers the old information, your assistant could confidently give customers the wrong answer.

That was the problem behind Cognee issue #4787.

I built a Contentful connector that imports published content into Cognee, keeps it synchronized, and removes outdated information when the original content disappears.

The connector lives in cognee-community/packages/connector/contentful/.

It does five things:

Content models are especially useful here.

Suppose an entry has a field called batteryLife with the value 12.

Twelve what? Hours? Days?

The content model provides the field's structure and description. Without that context, an AI system has less information to interpret the value correctly.

So the connector imports content models separately instead of just dumping entry values into documents.

One synchronization run. Entries and assets use the Sync API, while content models are fetched separately.

The obvious approach to synchronization is simple.

Fetch everything once, then use sys.updatedAt to find recently edited entries.

That works for updates.

But what about deletions?

A deleted entry won't appear in the normal listing anymore. A timestamp filter alone can't reliably tell Cognee which information it should forget.

That's why I used Contentful's native Sync API.

The first run imports the available content and saves a checkpoint. Later runs use that checkpoint to retrieve changes.

More importantly, Contentful also returns deletion events like DeletedEntry and DeletedAsset.

The connector turns those events into dlt hard-delete markers, allowing Cognee to clean up obsolete documents and their associated graph and vector data.

There's another detail I didn't want to get wrong: pagination.

If Contentful returns five pages and page three fails, the connector must not save the final checkpoint.

Otherwise, the next synchronization could skip changes it never processed.

So it follows every page before accepting the terminal sync token. If the response is incomplete, the run fails instead of silently losing information.

Here's another situation.

Suppose one integration imports English product descriptions, while another imports articles in multiple languages.

Changing the first integration shouldn't touch the second.

I added a source_id to give each logical source its own synchronization state.

Changing filters under the same source ID triggers a selection refresh. The connector removes documents that no longer belong to that selection while preserving other sources.

Credentials are also kept separate from source identity.

Rotating an API token shouldn't mean importing the entire collection as a new source.

A successful API request doesn't mean the whole synchronization succeeded.

Think about this sequence:

Now what?

If the connector only trusts the latest API response, that earlier failed work could remain unfinished.

The implementation relies on Cognee's retained dlt staging so a later run can reconcile existing records again, even when the provider returns an empty delta.

I also covered individual cleanup failures that Cognee logs without raising an exception.

That's the distinction that matters here: successfully a change isn't the same as successfully updating AI memory.

I wanted to test more than whether the connector could parse some JSON.

The important questions were:

The October 8 local verification report recorded 94 passing tests.

Tests Coverage
87 Contentful provider behavior, synchronization, and dlt
7 Real local Cognee ingestion, storage, deletion, and recovery

The same 94 tests passed on Python 3.11, 3.12, and 3.13, plus another Python 3.12 run with the newest permitted dependencies.

Eight relevant upstream Cognee regression tests also passed, along with Ruff checks and package builds.

Local test evidence. Contentful responses and model operations were mocked; SQLite, Ladybug, and LanceDB storage paths were exercised for real.

That distinction is important.

These tests provide evidence of local correctness, including deletion from relational, graph, and vector storage. They don't yet prove authenticated Contentful lifecycle behavior.

The implementation is available in my Contentful connector branch.

From the connector directory:

uv sync --locked

Configure your Contentful space and Delivery token:

export CONTENTFUL_SPACE_ID="your-space-id"
export CONTENTFUL_DELIVERY_TOKEN="your-token"
export CONTENTFUL_ENVIRONMENT_ID="master"
export LLM_API_KEY="your-model-key"

Then run:

uv run python examples/example.py

The example synchronizes published content into Cognee and runs a search query.

You can select specific content types and languages, or disable asset ingestion. Subsequent runs synchronize changes for the same source.

For example, a product-catalog application could import descriptions, search for products matching a customer's requirements, and refresh its memory after catalog edits.

That's an illustrative use case. A live Contentful-to-Cognee demonstration is still needed to establish real-provider behavior.

A few limitations worth mentioning:

An invalid synchronization checkpoint also requires deliberate recovery rather than an automatic destructive reset.

Importing data once is straightforward.

Keeping it correct when the source changes, an entry disappears, or processing fails halfway through is the harder problem.

The useful lesson from this connector is that synchronization needs to account for both sides: what the source says changed, and what the destination actually finished processing.

Otherwise, everything can appear to work while the AI is still remembering yesterday's information.

Code and references

Built as part of WeMakeDevs × Cognee Mergetober 2026.

── more in #ai-agents 4 stories · sorted by recency
── more on @contentful 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/i-connected-contentf…] indexed:0 read:4min 2026-10-08 · —