What's actually enforced, and what's next.
txtfetch is pre-launch and hardening in public. Here's the honest split between what's shipped today and what's on the roadmap — no claim outruns the code.
in-place-today
In-memory processing, no content store
Every request is held in memory for the duration of the extraction and never written to a datastore. See the data handling note below for the exact posture.
TLS in transit
CloudFront and the Lambda function URL terminate TLS with AWS-managed certificates (ACM) — every hop between you and txtfetch is encrypted.
AWS-managed encryption at rest
Anything txtfetch stores in AWS (S3 assets, CloudWatch logs) is encrypted at rest using AWS-managed keys (S3 SSE).
Cookieless analytics
Site analytics are aggregate and cookieless — no personal data, no tracking cookies, no consent banner required.
Least-privilege intent
The extraction Lambda's IAM role is scoped to what the function needs to run — compute and the artifacts it reads, nothing broader.
Single region
All compute and storage run in a single AWS region (us-west-2) — no unnecessary data replication across geographies.
on-the-roadmap
planned
SSRF-guarded URL fetch
Server-side URL fetching (?url=) will be restricted with an allowlist and IP/metadata-endpoint guards, closing off internal-network targets.
planned
Abuse controls beyond rate limiting
Additional request-shape and reputation checks are planned on top of today's basic rate limiting.
planned
Automated dependency & runtime scanning
A published patch SLA plus CI-driven dependency and base-image scanning — see the target windows in the data handling note below.
planned
SOC 2 Type II
A formal audit is on the roadmap, not completed. Details on scope and timeline live on the /compliance page.
Read more →data-handling
No content store, and we're closing the last gap.
Document bytes are processed in memory and discarded — we do not persist document content to any datastore. We are actively closing out a request-logging path that could otherwise capture raw request data in operational logs; until that work lands, treat this as our target posture rather than a fully audited guarantee. Full detail is on the privacy page.
Patch targets: critical vulnerabilities within 7 days, high-severity within 30 days. Today that's a manual process; automated scanning is on the roadmap above.
vulnerability-disclosure
Found a problem? Tell us.
Scope: txtfetch.com, the extraction API, and any subdomain of txtfetch.com. Third-party services we depend on (AWS, Plausible) are out of scope — report those directly to the provider.
Safe harbor: if you make a good-faith effort to find and report a vulnerability — avoiding data destruction, privacy violations, and service disruption — we will not pursue legal action against you for that research.
How to report: send details through /contact — no email address to guess at. Include what you found, how to reproduce it, and its potential impact.
Response window: expect an acknowledgment within 3 business days. We'll follow up with a timeline once we've triaged the report.
Stop parsing. Start shipping.
Create an account and get an API key in minutes — the free Hobby plan needs no card.
Get started →