Privacy Policy

Last updated: September 5, 2026

Who we are

DataEgress is data export and delivery infrastructure for B2B SaaS companies, operated legally by FENGAMO CAPITAL SL. This policy explains what information we collect through the Service and how we handle it — written to describe what the product actually does today, not an aspirational future state.

Information we collect

Account data. When you create a DataEgress account, we collect your name, work email, and a password (stored as a salted hash — we never store or can see your plaintext password), along with your organization/workspace name. We also keep basic authentication and session metadata needed to keep you securely signed in.

Contact and business data. If you submit our Contact form, we store the name, work email, company, and message you provide, so we can respond. If you tell us your role or use case, we store that too.

Billing data. If you subscribe to a paid plan, Stripe — our payment processor — handles your payment details directly. We never receive or store your card number. On our side, we store the identifiers Stripe gives us to associate your organization with its subscription (a customer ID, subscription ID, and current plan/billing state), so the dashboard can show you accurate billing information.

Product metadata. Operating the Service means storing the configuration you create: dataset definitions and the fetchUrl/configuration you provide for them, destination configuration (including encrypted credentials — see Credentials and secrets, below), schedules, and API keys. We also store metadata about each export run: status, row counts, checksums, timestamps, manifest contents, and error details when a run fails. None of this includes the row-level content of your exports.

Customer export data

This is the category worth being precise about, since it's the core of what the Service does:

Rows are retrieved through the fetchPage process that you, the customer, control and expose — we only ever see what that endpoint returns.
Those rows are processed to assemble an export file (CSV or Parquet).
Row data is not stored in DataEgress's application database. It exists only transiently, for the time it takes to generate a given export.
The generated export file itself may be stored temporarily in DataEgress-controlled object storage (Cloudflare R2 in production) as part of delivering it — for example, when the destination is a signed URL, or as a short-lived mirror alongside a direct-to-S3/R2 delivery.
For destinations you configure as your own (or your end customer's) S3/R2 bucket, the file is delivered directly into storage you control, not ours.

Generated export files in DataEgress-controlled object storage are automatically deleted 7 days after the export completes. Files delivered directly to your own (or your end customer's) S3/R2 bucket are not affected by this — once delivered there, they exist entirely under your own storage provider's account and retention settings, outside our control. See Data retention, below.

Credentials and secrets

Destination credentials (for example, S3/R2 access keys) are encrypted at rest and are never returned by any API response once saved — reading a destination's configuration back always shows the credential masked. API keys are stored as a one-way hash from the moment they're created; the full key value is shown to you exactly once, at creation, and we have no way to retrieve it afterward. Revoking a key or destination credential takes effect immediately.

Logs

We keep operational and security logs — request logs, error logs — to run and secure the Service. These logs do not contain the contents of the rows you export, and do not contain raw response bodies from your fetchPage endpoint. They may contain technical metadata: timestamps, status codes, error messages, and similar operational detail.

How we use this information

We use the information above to: provide and operate the Service; secure it against abuse and unauthorized access; troubleshoot a specific run or account when you ask us to, or when we detect a failure; process billing through Stripe; respond to support and contact requests; and understand product usage at an aggregate level so we can prioritize what to build next.

Third-party infrastructure

Running the Service means relying on a small number of infrastructure providers, each handling a specific part of the stack:

Vercel — hosts the application itself.
Neon — hosts our Postgres database.
Inngest — schedules and executes background jobs, including your scheduled exports.
Stripe — processes payments for paid plans.
Cloudflare (R2) — object storage for generated export files, where configured.

We're describing our actual infrastructure here, at a category level — this is not a formal, contractually-represented subprocessors list, and we don't yet operate one.

Data retention

Retention isn't uniform across every category of data we hold, so we'll be specific rather than give one blanket answer:

Generated export files in DataEgress-controlled storage — used for signed-URL delivery, and as a short-lived mirror alongside direct-to-S3/R2 deliveries — are automatically deleted 7 days after the export completes, by an automated process that runs continuously, not a manual or best-effort cleanup.
Files delivered to your own (or your end customer's) S3/R2 bucket are not covered by that deletion. Once delivered, they exist entirely under your own storage provider's account and retention settings — outside our control, by design.
Run metadata (status, row counts, checksums, timestamps, manifests) is kept for as long as your account exists, even after the underlying export file itself has been deleted 7 days later — this is what lets your dashboard keep an accurate delivery history and lets you verify what a past run actually did.
Account and product configuration persist for as long as your account or organization exists, so the Service continues to function correctly.
Destination credentials are retained only for as long as the destination itself exists — deleting a destination deletes its stored credentials immediately along with it.
Deletion of your account or organization does not yet follow a fixed automatic timeline across every data category — if you need data removed on a particular timeline, contact us and we'll do what we reasonably can.

This is not a certified or audited compliance program — it's an honest, specific description of what the system actually does today.

Security

Relevant, verified technical measures — not a marketing list:

Organization-scoped access controls, so one customer's configuration and data are not visible to another's.
Destination credentials encrypted at rest.
API keys stored as a one-way hash, never in recoverable form.
Protections against server-side request forgery (SSRF) on the URLs the Service is configured to call.
Stripe webhook payloads are cryptographically verified before being trusted.
No direct connection to your database, ever.

Full detail is on our Security page.

International data handling

Our infrastructure providers (listed above) operate data centers in multiple regions; we don't currently offer a data-residency guarantee or region-pinning as a product feature. If where your data is physically processed or stored is a hard requirement for you, contact us before relying on the Service for that use case.

Your rights and requests

You can access, update, or delete most of your account and configuration data directly from the dashboard. To request deletion of your account or data, ask a question about this policy, or make any other privacy-related request, contact us — we'll respond directly. We have not appointed a formal Data Protection Officer.

Cookies

DataEgress uses one cookie: the session cookie that keeps you signed in. It's strictly necessary for the Service to function and is not used for tracking, analytics, or advertising. We do not use any third-party analytics, advertising, or tracking cookies or scripts.

Changes to this policy

We may update this policy as the Service evolves. Material changes will be reflected by updating the "Last updated" date above.