Your AI agent's retrieval logic is probably not the bottleneck. Neither is your model choice or your embedding strategy. The part that slows teams down most consistently is the layer that runs before any of that: pulling content in, parsing it, and getting it into a shape the rest of the pipeline can actually use.
If you have built a RAG pipeline or an LLM agent, the setup is familiar. You are using one library for PDF extraction, a separate scraping service for web pages, and a third tool for anything else that comes in. Each one has its own API key to manage, its own rate limit to stay under, and its own output format to normalise before the content gets anywhere near your retrieval layer. When one of them changes something on their end, you find out when your pipeline breaks.
EnConvert started as a file conversion tool. That version shipped and worked fine. The problem was that file conversion is a crowded market with no real gap to build a company around. We stepped back and looked harder at where the actual gap was. The answer kept pointing to the same place: the ingestion layer, before the model, before retrieval, at the point where content first enters the system. That is what EnConvert is now built around.
What EnConvert is
EnConvert is a unified ingestion API. One base URL, one authentication key, one consistent output format across all endpoints. Three are live today.
Perceive takes a URL and returns clean markdown. Web pages are built for browsers, not for language models. Navigation elements, scripts, layout markup, and ads add noise that makes web content harder to process reliably. Perceive strips that out and returns structured markdown with headings, lists, code blocks, and links preserved. Pass content_only: true to receive only the core content without navigation, ads, or layout markup. The output goes straight to your chunking step.
Ingest handles file ingestion for the formats that appear most often in document pipelines: PDF, DOCX, and similar structured types. You pass a file, Ingest extracts the content, and returns it in the same output format as every other endpoint. Tables come back as markdown tables. Headings come back as markdown headings. The document structure is preserved rather than collapsed into a single text block, which matters when content is being chunked for retrieval.
Convert handles format conversion between document types. It is the capability EnConvert was originally built around, now part of the broader ingestion layer. If your pipeline requires format normalisation before ingestion, or if your users upload files in types your system does not directly process, Convert handles the transformation step before Ingest takes over.
More endpoints are in development. They will ship when they are ready.
What consistent output actually costs you right now
The setup overhead of connecting multiple tools is a one-time problem. The output inconsistency is permanent.
Every tool in a fragmented ingestion setup returns content in a different shape. One returns raw text. Another returns structured JSON with its own field names. Another returns HTML you strip yourself. Before any of it reaches your retrieval layer, you are writing normalisation code to reconcile all of it into a shape your chunking and embedding logic can handle.
That normalisation code becomes part of your system. It needs tests. It needs to be updated when an upstream service changes its response format. It grows each time you add a new content type. When something upstream changes and your normalisation layer breaks, your pipeline loses access to that content source until you fix it.
The inconsistency runs deeper than field names. One parser might use ATX headings with a space after the hash. Another might omit that space. One might wrap code blocks in triple backticks with a language identifier. Another might not. These differences affect how your splitter segments content and how your embedding model interprets structure. Your chunking strategy ends up compensating for formatting inconsistencies that should never have existed.
When all your endpoints return the same format, you write the downstream logic once. Chunking, embedding, metadata handling, error handling, retry logic: all of it works across every input type without branching by source. When your pipeline breaks, you know the issue is in your retrieval logic or your model, not in the ingestion layer. Adding a new content type to your pipeline means calling a new endpoint, not writing a new adapter.
For retrieval pipelines specifically, consistent output structure also means consistent metadata fields. Your retrieval and reranking logic does not need to know whether a document came from a web page, a PDF, or a file upload.
Why markdown
Markdown is a practical middle ground for retrieval pipelines. It preserves document hierarchy through headings, lists, tables, links, and code blocks without carrying the complexity of raw HTML or proprietary document formats. That makes it easier to preserve semantic structure while keeping downstream processing predictable. Instead of writing separate preprocessing code for different content sources, your retrieval pipeline works from a single representation regardless of where the information originated. For RAG systems, consistency at this stage reduces the amount of application code sitting between your data source and your embeddings.
Code example
python
import requests
response = requests.post(
"https://api.enconvert.com/v1/perceive",
headers={
"Authorization": "Bearer YOUR_API_KEY",
"Content-Type": "application/json"
},
json={
"url": "https://example.com/article",
"content_only": True
}
)
result = response.json()
markdown_content = result["content"] # clean markdown, ready to chunk
The same request pattern works across Perceive, Ingest, and Convert. Change the endpoint path, adjust the input parameters, and the response structure remains consistent.
Getting started
The free tier is 500 operations per month with no credit card required. That is enough to test it against a real pipeline rather than a synthetic example.
Full API reference and output schema documentation at https://www.enconvert.com/docs/introduction. Pricing details at https://www.enconvert.com/pricing.
More endpoints are coming. If there is an input type or a workflow the current three do not cover, that is directly useful to know. The roadmap is built around what engineers are still handling by hand.
Top comments (0)