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).

Google Analytics

Google Analytics is the site's analytics provider. It sets cookies and is governed by Google's own policy. See /subprocessors.

Least-privilege intent

The extraction Lambda's IAM role is scoped to what the function needs to run. That means compute and the artifacts it reads, nothing broader.

Single region

All compute and storage run in a single AWS region (us-west-2). There's 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, not 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, Google Analytics) are out of scope. Report those directly to the provider.

Safe harbor: make a good-faith effort to find and report a vulnerability. Avoid data destruction, privacy violations, and service disruption. Do that, and we will not pursue legal action against you for that research.

How to report: send details through /contact. There's 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.

Machine-readable policy: /.well-known/security.txt

Stop parsing. Start shipping.

Create an account and get an API key in minutes. The free Hobby plan needs no card.

Get started →