Skip to main content
When you turn Synap on for an existing app, you usually have months of conversation logs sitting in a database. Pump them in via batch ingestion so the agent starts day one with the same context your users already remember about themselves.
Why mode="long-range" for backfill Historical conversations are the highest-value extraction target you’ll ever have: they’re the one-shot chance to build a rich entity graph and detailed preferences for every user. long-range runs the full extraction pipeline (entity resolution, preference detection, emotion analysis, relationship mapping). It’s slower per document, but speed doesn’t matter for an offline backfill. fast mode would skip most of this: fine for runtime chat ingestion, wrong for backfill. Why document_created_at Synap uses document_created_at as the ground-truth timestamp for temporal reasoning, recency ranking, and aging. Don’t skip it: without it, every memory looks like it happened today, and recency-weighted retrieval breaks. Pass the original timestamp from your database. Why batch and not one-by-one batch_create accepts up to 100 documents per call, and the cloud queues them on a backfill-friendly path that doesn’t slow real-time ingestion. One-by-one would 30x your wall-clock time and burn rate limits. Idempotency If you re-run the backfill (because you found a bug, or because you’re bringing online a second region), pass a stable document_id derived from your DB row:
Synap deduplicates on document_id; duplicates surface as per-document failures in the batch_create response (results[].status / results[].error_message). Inspect the response and skip rows that already exist:
How long it takes Backfill throughput is gated by per-Instance limits: measure on a sample slice of your corpus before extrapolating; the numbers vary by document size and mode. Talk to support if you have multi-million-turn backfills and want a higher throughput allocation for the window.

Going further