https://txtfetch.com/sources/
Your documents don't live on a local disk. Here's how txtfetch reaches them.
Every store below answers one question. Can it hand txtfetch a URL with no Authorization header, or do you send the bytes yourself?
One fact settles every row
txtfetch's ?url= parameter fetches a document server-side, but it sends no custom headers of its own. A store that can mint a URL needing no Authorization header lets ?url= reach it directly. A store that can't means you fetch the bytes with your own credentials, then POST them to txtfetch instead.
Nothing below is a benchmark of these stores. It's a map of one narrow, practical question: which path gets a document from each one into txtfetch.
the decision table
| Store | Pre-authenticated URL? | txtfetch path | Link lifetime | The trap |
|---|---|---|---|---|
| Google Drive | No — Drive requires a Bearer header on every download | POST the bytes | N/A — no public link ever exists | A native Google Doc, Sheet, or Slide has no raw bytes. Export it first, and the export tops out at 10 MB. |
| SharePoint & OneDrive | Yes — @microsoft.graph.downloadUrl needs no header | ?url= | Minutes — Microsoft warns it can expire fast | The URL might expire within minutes. Fetch it right before the txtfetch call, never from a queue or a retry. |
| Amazon S3 | Yes — a presigned GET URL | ?url= | Your choice, set when you sign it | Set the expiry longer than the async job can take, or a slow OCR pass outlives the link. |
| Dropbox | Yes — the returned temporary link | ?url= | About four hours, then 410 Gone | Refreshing the access token that generated the link can cut a live link short. |
| Confluence | No — none is documented | POST the bytes | Not documented, and not a signed expiry | The download path has already moved once, from the v1 _links.download field to v2's downloadLink. Check the current API reference before you depend on either. |
| Email inbox | No — a mailbox has no download URL at all | POST the bytes | N/A | The Gmail API's raw field is base64url-encoded text, not a file. Decode it before you write the .eml file, or txtfetch reads garbage. |
Full citations, dated, live on each spoke below. See the error reference for what a failed fetch actually returns.
What ?url= can and can't do
- It sends no custom headers. There's no way to pass an
Authorizationheader on the fetch itself. - It rejects credentials written into the URL, like
https://user:pass@host. A blocked address fails the same way. - It only fetches over
httpandhttps, on the default web ports. - It follows a redirect chain, re-checking every hop against the same rules, so a redirect can't smuggle past a header or scheme limit.
- It runs under a fixed time and size budget. A source that's slow or huge fails the same way a broken link does, with a typed
fetch_failederror.
See the error reference for every code ?url= can return, and async jobs & webhooks for how a slow source stays inside that budget.
No connector ships for any of them
txtfetch ships no plugin or connector for Google Drive, SharePoint, OneDrive, S3, Dropbox, Confluence, or a mailbox. Each spoke below shows the whole path: fetch the document with the store's own API, then hand it to txtfetch. Already running on a no-code platform? See integrations for the platform side of the same wiring. For where the extracted text goes next, see ingest into a vector store.
pick a source
Google Drive
A file that needs a header on every download, and an export step for anything native.
POST the bytes
SharePoint & OneDrive
The download URL that needs no Authorization header at all.
?url= works
Amazon S3
Credentials that ride in the query string, not blocked by the SSRF guard.
?url= works
Dropbox
A four-hour link, minted by a token that never leaves your side.
?url= works
Confluence
A download link Atlassian never promises will work without your credentials.
POST the bytes
Email inbox
The whole message, not a link, since a private inbox has no download URL.
POST the bytes
frequently asked questions
- Does txtfetch connect directly to Google Drive, SharePoint, OneDrive, S3, Dropbox, Confluence, or a mailbox?
- No. txtfetch ships no connector or plugin for any of the six. Fetch the document yourself, using the store's own API, then send it to txtfetch as a URL or a file.
- How do I know if a store needs ?url= or a file upload?
- Check whether the store can hand you a link with no Authorization header. SharePoint, OneDrive, S3, and Dropbox can. Google Drive, Confluence, and a mailbox can't, so you POST the bytes instead.
- Why does ?url= work for some stores and not others?
- ?url= sends no custom headers of its own. A store that needs an Authorization header on every download can't be reached that way, no matter how the link looks.
- Does txtfetch benchmark accuracy or speed for any of these sources?
- No. None of these six is a text-extraction service, so there's no such comparison to make here. See /benchmarks for txtfetch's own measured extraction numbers.
Point it at your source files.
Pass a signed URL and the text comes back. There is no connector to install.
Get an API key →