Home / Policies / privacy
MIPROXY / POLICIES

Privacy

Reviewed October 16, 2026

MiProxy handles account and order information to operate the workspace. A real proxy connection goes directly to the supplier gateway. This page describes those boundaries and the information currently documented for the workspace; a complete production privacy notice is still being finalized.

Information handled by the workspace

CategoryExamplesOperational purpose
Account and session informationEmail, name, sign-in identity and session recordsAccount access and authorization
Orders and payment referencesSelected packages, order state and payment-event referencesTracking checkout and allocation setup
Connection detailsGateway settings and encrypted credentialsProviding the authorized allocation's connection information
Usage snapshotsAggregate supplier usage and sync timesShowing the latest available usage view
Support requestsInformation participants submit about an issue or requestAdministrator review and follow-up

This table summarizes the known workspace model; it is not a completed inventory of every deployment log, cookie, vendor or data transfer.

Payments and sign-in

Stripe handles card details in the checkout flow; the MiProxy application does not store card numbers. Checkout uses live Stripe payments. Public registration is available with email verification. Sign-in uses the deployment's identity system and application sessions to identify the account and apply access controls.

The production notice needs a verified list of the identity, hosting, payment, communications and supplier services involved, including their roles and applicable retention practices.

Proxy connections and credentials

Stored gateway credentials are encrypted and revealed through an authenticated ownership check. Encryption is a protection for stored connection details; it is not a claim that no data exists or that every connected service has the same practices.

MiProxy's application does not relay proxy browsing payloads. A real connection uses the supplier gateway, and the supplier has separate data-handling practices. Those practices must be reviewed and disclosed for the selected service before production launch. The lack of an application traffic relay is not a network-wide “no logs” claim.

What to keep out of support requests

Do not send proxy passwords, session cookies, authorization headers or private destination URLs. A useful report normally needs the order reference, time, action and sanitized error. Remove credentials from screenshots and connection strings before sharing them.

Retention and deletion requests

Account deletion and other retention requests currently require manual review through workspace support. We retain account details while your account exists. You can request account deletion through support; requests are reviewed manually. Billing records may be retained for accounting, dispute handling and legal obligations after account closure. Retained records are limited to those purposes. This policy does not promise immediate deletion from backups or independent supplier systems.

Cookies, recipients and transfers

Public pages use Umami for page-view analytics. Tracking excludes workspace, authentication and API routes, omits URL query strings and fragments, and respects Do Not Track. Referrers are reduced to their origin. A complete production notice must also identify actual session/cookie behavior, service recipients, storage locations and any cross-border transfer arrangements. These need a deployment-specific inventory. This draft does not claim that analytics, third-party tracking or international transfers are absent merely because they are not listed here.

Contact about your information

Existing customers can submit a privacy or deletion request through workspace support. If account access is unavailable, contact the administrator who arranged workspace access. A verified public privacy contact and named responsible entity remain required for the production notice.