The API

Turn your documents, images, audio and video into a corpus your application can retrieve from - one endpoint, one file out.

What it does

You POST files. You get back JSONL: one JSON object per line, each carrying a passage of text, its embedding and the metadata needed to trace it back to the file and the moment it came from. Nearly every vector database imports newline-delimited JSON, which makes it the working standard for moving a corpus between systems.

It is deliberately one endpoint. Conversion is the expensive step and the one you run least often - on upload, on a schedule, or when a source system signals a change. Retrieval is what sits in your request path, and that runs against your own vector store, not against us.

One call

curl -X POST https://api.ragconverter.com/v1/convert \
  -H "Authorization: Bearer $RAGCONVERTER_KEY" \
  -F "file=@handbook.pdf" \
  -F "file=@keynote.mp4" \
  -o chunks.jsonl

The manifest - what each file produced, and how its text was obtained - comes back in the x-ragconverter-manifest header. Keys are minted from your account page after signing in.

Three engines on a video, and paying for fewer

A video carries three separate things worth indexing, and they are read by three different models: Carmenta takes the text on the frames, Argus describes what those frames show, and Mercury transcribes the audio track. Each becomes its own passage, timestamped, so a query lands on the minute that answers it.

You do not have to buy all three. Name the ones you want and the rest are never run - not filtered out afterwards, never started. Asking for the speech alone out of a long recording is one pass instead of several hundred, and the bill follows the work.

# just the transcript
curl -X POST https://api.ragconverter.com/v1/convert   -H "Authorization: Bearer $RAGCONVERTER_KEY"   -F "engines=asr"   -F "file=@keynote.mp4"   -o transcript.jsonl

# slides and speech, but no descriptions
  -F "engines=ocr,asr"

Omit the field and you get all three. An unrecognised name is an error rather than a silent fallback to everything - a typo that quietly widened the request would be billed as three engines and would never show up as a mistake.

About Argus

Argus is the one that makes a picture searchable when there is no text to read. A photograph, a diagram, a frame of a screen recording - OCR returns nothing from any of them, and the file is either described or it is not in your index at all. That is what it is for, and it is the reason a video is worth more than its transcript.

It is still the expensive one - a description is a full forward pass, which is why video samples it ten times more sparsely than it reads text - but it is no longer the expensive one it was. The current build encodes an image as a single tile and 64 image tokens rather than seventeen tiles and 1088: 37.6 seconds against 544 on the same photograph, measured by the engine's own authors.

What that drops is fine print and small objects, not the subject. Which is the right trade here precisely because Carmenta has already read the text off the same frames a moment earlier - paying nine minutes for a second, worse reading of words we already have properly would be spending the whole budget on the one thing this engine is not for.

What it reads

Text and Markdown, PDF, Word, PowerPoint and Excel are parsed directly. Images and scanned PDFs go through OCR at full resolution - no browser memory ceiling, which is the main reason this tier exists. Audio is transcribed. Video is taken apart into three tracks: the text on screen, what the frames show, and what is being said, each timestamped so they line up.

Each passage records HOW its text was obtained - parsed, read by OCR, heard by a speech model, or described by a vision model. That distinction matters when your application cites a source: a transcription is a record of words that were really there, and a description is inference that can be confidently wrong. An application that presents both as quotations will eventually quote something nobody said.

What people build with it

Support that answers from your docs

A support assistant that has read your manuals, release notes and past tickets answers the eighty percent of questions that are already documented, and cites the page it used. The value is not the deflection rate on its own - it is that the answer is traceable, so a wrong one can be found and fixed at the source.

Search that understands the question

Keyword search fails when the user's words are not the document's words. Someone asking "can I get my money back" never matches a page headed "Refunds and Returns" on keywords, and matches it immediately on meaning. Retrieval over embeddings is the difference.

Onboarding and internal knowledge

New staff ask the questions already answered in a wiki nobody can navigate. A retrieval layer over the same material turns it from a filing system into something answerable, without anyone rewriting it.

Contracts, policies and compliance review

Finding every clause across hundreds of agreements that touches liability, notice periods or data residency is a retrieval problem before it is a reasoning one. Conversion is what makes those clauses findable - including the ones inside scanned PDFs, which is where they usually hide.

Recorded meetings and calls

An hour of audio is unsearchable until it is a transcript with timings. Once it is, "what did we agree about the renewal" becomes a query rather than an afternoon of scrubbing.

Video, training material and screen recordings

A recorded walkthrough carries three separate things worth indexing: the text on screen, what the frames show, and what the presenter said. Read apart and timestamped, a question lands on the minute that answers it.

What it is worth

The value of retrieval is not that the model sounds better. It is that the answer is grounded in a passage you can point at. A model without retrieval answers your customer's question about your refund policy from its training data, fluently and wrongly, and neither you nor the customer can tell. With retrieval the answer comes from your document, and when it is wrong, the document is wrong - which is a problem you can actually fix.

The other half is reach. Most of an organisation's useful material is not in a database: it is in PDFs, decks, scans, recordings and video. Conversion is what makes that material addressable at all, and it is usually the difference between a retrieval feature that covers a quarter of what people ask about and one that covers most of it.

What is not built yet

Conversion is stateless: you send files and receive a corpus, and we keep nothing. A stored corpus and a hosted query endpoint are planned and are not built, so retrieval today happens in your own vector store. HEVC video does not decode - the codec is absent, and it is what iPhones record by default. MP3 and M4A audio are not decoded either; WAV and FLAC are.

This list is not marketing modesty. GET /health reports the same status for every capability on this page, from the running instance, so you can check rather than trust.

Free, and private, in the browser

If your material cannot leave the machine it is on - identity documents, medical records, anything under an NDA or a data residency clause - the browser converter does the same job on your own hardware and uploads nothing. Same output format, no account. The API is for volume and for the larger models, not for the sensitive cases.