This is a design guide, not a runnable walkthrough. For a complete, runnable pipeline in six languages, follow the Build an End-to-End RAG Pipeline series — everything downstream of the adapter stage here is exactly what that series implements.
Do You Need a Custom Pipeline?
Before building anything, check whether Studio’s managed ingestion already covers your source. Gloo AI Studio provides an interface with four no-code connectors:- Web Scraping — point Gloo at a website or sitemap URL and it crawls and ingests the pages. The right path for public sites you don’t have API access to.
- Files — drag-and-drop upload across all supported formats.
- YouTube — ingest a channel or videos; Gloo handles transcription.
- Feeds — subscribe to RSS/content feeds without writing a poller.
producer_id schemes for programmatic updates and deletes, metadata attached at scale from your source system, incremental sync against a private CMS/API/database, or content that lives behind authentication.
Audio and video content (podcasts, sermon recordings, YouTube videos) is handled for you via the YouTube connector and audio/video file uploads. Those connectors transcribe content automatically so you don’t need to produce a transcript first.The preparation advice in this guide targets text content; if you already have text transcripts, they follow the same pattern as any other document.
The Pattern
Every ingestion integration, regardless of source, decomposes into the same five stages:/ingestion/v2/files with a producer_id. Because producer_id makes uploads idempotent, re-running the whole pipeline is safe: existing items are detected instead of duplicated.
Edit Metadata — attach metadata (title, summary, author, tags, canonical URL) via PATCH /engine/v2/item. You can target the item by producer_id, so this stage needs no state from the upload stage.
Verify — ingestion is asynchronous: the upload response means queued, not searchable. Poll GET /engine/v2/items/{item_id} until status reaches COMPLETED (you may see intermediate states such as CHUNKING along the way).
The key property: everything to the right of the adapter is identical for every source. Write the normalize → upload → edit metadata → verify stages once; when a new content source appears, you write only a new adapter.
Pre-Ingestion Preparation
These are the decisions to make up front — each is cheap to decide before launch and expensive to retrofit after.Detect the content type early
Classify each item — article, transcript, report, Q&A, devotional — as it comes out of the adapter, before normalization. The type drives everything downstream: how you clean the text, whether the item has natural boundaries worth preserving, and what metadata makes it findable. Most source systems already know the type (a CMS post type, a database column, a file extension); carry it through rather than inferring it later.Normalize to clean text
Gloo accepts a wide range of formats and detects each automatically: Markdown, plain text, rich text, reStructuredText, ORG, HTML, PDF, Word, PowerPoint, EPUB, CSV, TSV, Excel, JSON, XML — plus audio (aac, flac, m4a, mp3, ogg, wav) and video (avi, flv, mov, mp4, webm, wmv), which Gloo transcribes for you. When you control the conversion, prefer Markdown: it preserves heading structure (which helps chunking find natural boundaries) while staying free of layout noise.
| Source format | Guidance |
|---|---|
| HTML (CMS pages, web content) | Convert to Markdown. Strip navigation, headers/footers, cookie banners, comment sections — keep only the content a reader would consider the article. Preserve headings. |
| Extract text and inspect the output: multi-column layouts, running headers, and page numbers often survive extraction as mid-sentence noise. Clean these before upload rather than uploading raw extractions at scale. | |
| Transcripts (podcasts, sermons, meetings) | If you already have a text transcript, keep speaker labels and section breaks that carry meaning; strip per-word timestamps and filler tokens. If you only have audio/video, upload the media itself (or use the Studio YouTube connector) and let Gloo transcribe. |
| Structured records (database rows, JSON, spreadsheets) | Render each record as a small Markdown document — a heading plus labeled fields — rather than concatenating raw values. CSV/TSV/Excel/JSON upload directly too, but ask whether one row is really one retrievable document; if so, per-record Markdown items give each its own producer_id and metadata. |
Deduplicate — your half and Gloo’s half
Deduplication splits cleanly into two responsibilities:- You dedup within a run. Source systems frequently expose the same item more than once — a post that appears in two categories, a document reachable at two paths, a feed that repeats entries. Dedup on the source system’s native ID inside your adapter, before anything is uploaded.
- Gloo dedups across runs. Uploading with the same
producer_idagain doesn’t create a copy — the existing item is detected. This is what makes “just re-run the pipeline” a safe recovery strategy.
producer_ids, you never need to track “what have I already uploaded?” state yourself.
Choose a producer_id scheme before the first upload
This is the single highest-leverage decision in the whole pipeline. The producer_id is your stable handle on an item: it makes uploads idempotent, lets you update metadata without storing Gloo’s item_id, and lets a sync process map source-system changes onto Gloo items years later.
The recommended scheme is {source-system}-{native-id}:
- Derive it from the source system’s own primary key — the one identifier that survives edits, renames, and moves.
- Prefix with the source system so IDs stay unique when a second source later feeds the same publisher.
- Treat it as permanent: the same source item must always map to the same
producer_id.
- Derive it from the title, URL slug, or file path if those can change — a renamed item would look like a brand-new one, leaving the old version orphaned in your publisher.
- Derive it from position or ordering (row number, feed index).
- Reuse a
producer_idfor different content — that’s an update, not a new item.
Pre-chunk vs. let Gloo chunk
Default: let Gloo chunk. After upload, Gloo automatically splits your content into retrieval-sized chunks, embeds them, and indexes them — you don’t configure any of it, and for most content types (articles, reports, transcripts, long-form prose) automatic chunking is the right answer. Split content yourself before upload only when it has hard semantic boundaries that must not be crossed — units that would be wrong to retrieve partially or merged with a neighbor:- Q&A content — each question-and-answer pair is one unit; upload each pair as its own item.
- Devotionals or daily entries — each entry stands alone; a chunk spanning two days’ entries would mislead retrieval.
- Episodic collections — if each segment has its own title, date, and canonical URL, it deserves its own item and metadata.
producer_id (e.g. faq-item-291, devotional-2026-03-14) and its own metadata. Note this is a decision about item granularity — what constitutes one document — not about tuning chunk sizes. Within each item, Gloo still chunks automatically.
Metadata: attach at upload time vs. edit later
The item metadata fields —item_title, item_summary, item_url, item_image, publication_date, author, item_tags, and friends — can be set as soon as the item exists; you don’t need to wait for ingestion to finish. The decision rule:
- Attach immediately what the source system already knows. Title, author, publication date, canonical URL, and native tags are sitting right there in the adapter’s output — PATCH them right after each upload, as part of the pipeline.
- Edit later what has to be derived. Editorial summaries, curated tags, and classifications that need review can land in a separate edit pass — days or weeks later — targeting items by
producer_id.
item_url) deserves special attention: it’s what lets applications link users back to the original content when a search result or grounded completion cites the item. Capture it in the adapter; it’s often hard to reconstruct later.
Metadata edits are eventually consistent on the read path: a
GET immediately after a PATCH may return the old values. When your pipeline verifies edits, poll rather than asserting on the first read. See Part 3 of the RAG pipeline series for the polling pattern.Source Adapters
An adapter’s contract is small: yield items in a common shape, setting exactly one oftext (Markdown you extracted and normalized) or data (raw bytes of a file already in a supported format). Define that shape once:
The pattern is language-neutral. The sketches use Python and TypeScript to match the RAG pipeline series; port the same structure to Go, Java, PHP, or anything else.
CMS (WordPress, Contentful, Sanity, Drupal)
Page through the CMS’s content API, convert each entry’s HTML body to Markdown, and use the CMS’s own post ID as the native ID.API-based tools (Notion, Confluence, custom JSON)
Traverse the tool’s page or space hierarchy, render each page’s block tree to Markdown, and use the page UUID as the native ID.Database (knowledge-base tables, blog posts, CMS rows)
Query the rows, render each record as a small Markdown document (heading plus labeled fields), and use the primary key as the native ID.File library (S3, GCS, SharePoint)
List the objects, filter to supported formats, and use the object key as the native ID. Files can pass through as-is — Gloo detects supported formats automatically — so this adapter setsdata (raw bytes) rather than text. Scanned or layout-heavy PDFs still benefit from the extraction pass described under normalization; if you do extract text yourself, set text instead.
Feeds and batch exports (RSS, weekly CMS export)
Feeds are the incremental case: track the last GUID or timestamp you’ve seen and yield only new or changed entries. This same shape handles a weekly CMS export — diff the export against the last run’s state.producer_id, incremental sync degrades gracefully: if your sync state is lost, a full re-run re-uploads everything without creating duplicates. Re-uploading a changed entry with its existing producer_id updates the item rather than duplicating it; when source items are removed, delete the corresponding Gloo items with DELETE /engine/v2/items, scoped to exactly those item IDs — see Part 2 of the RAG pipeline series for the scoped-delete pattern.
Decision Matrix
Here is a skimmable summary of everything above:| Decision | Default | Choose the other option when… | Covered in |
|---|---|---|---|
| Custom pipeline vs. Studio managed ingestion | Studio managed, if a connector fits (website, YouTube, feed, file drops) | You need stable producer_id schemes, metadata at scale, incremental sync against a private system, or programmatic lifecycle management | Do you need a custom pipeline? |
| Pre-chunk vs. let Gloo chunk | Let Gloo chunk | Content has hard semantic units (Q&A pairs, devotional entries) that must never be split or merged | Pre-chunk vs. let Gloo chunk |
producer_id scheme | {source}-{native-id} | Never — always derive from the source’s primary key | Choose a producer_id scheme |
| Metadata at upload vs. edit later | Known-at-source fields at upload | Derived or editorial metadata (summaries, curated tags) → separate edit pass | Metadata timing |
| Markdown vs. original format | Convert to Markdown | Files are already clean Markdown/text/PDF/Word in a library → upload as-is | Normalize to clean text |
| Full re-sync vs. incremental sync | Incremental (track last-seen state) | Catalog is small (hundreds of items) → full re-runs are simpler and idempotency makes them safe | Feeds and batch exports |
| One publisher vs. several | One per distinct content brand or owner | Sources with different ownership, audiences, or lifecycle → separate publishers keep bulk operations safely scoped | Part 2: scoping |
| One file per upload vs. batch | One file per request | Never for pipelines — producer_id is ignored on multi-file uploads | producer_id scheme |
What Gloo Does for You
Do not build these yourself, they’re handled automatically after upload:- Format detection and parsing — Markdown, text, rich text, reStructuredText, ORG, HTML, PDF, Word, PowerPoint, EPUB, CSV, TSV, Excel, JSON, and XML files are detected and processed without any format flags.
- Transcription — audio (
aac,flac,m4a,mp3,ogg,wav) and video (avi,flv,mov,mp4,webm,wmv) files are transcribed automatically, whether uploaded as files or ingested via the Studio YouTube connector. - Chunking — content is split into retrieval-sized chunks automatically; there’s nothing to configure.
- Embedding — chunks are embedded for semantic search; you never manage models or vectors.
- Vector storage and retrieval indexing — no vector database to run, no index to maintain.
- Cross-run deduplication — re-uploading with the same
producer_idupdates rather than duplicates.
Next Steps
- Build an End-to-End RAG Pipeline, Part 1 — the runnable version of upload → edit metadata → verify, in six languages.
- Part 2: Manage the Content Lifecycle — updates, bulk edits with filters, and safely scoped deletes for keeping Gloo in sync with your source.
- Part 3: Verification, Errors & Resilience — error handling, retries with backoff, and health-check patterns for production pipelines.
- Upload Content and Edit Content — API-level reference for the upload and metadata endpoints.
- Building a Knowledge Base — Learning Center background on why chunking and metadata matter in RAG systems.

