Effective 24 July 2026. Last updated 24 July 2026.

Privacy policy

Purpose

This policy describes how mintfax collects, uses, discloses, and retains personal data through the mintfax fax API and dashboard.

Scope

This policy applies to the mintfax service and the mintfax dashboard, in both sandbox and live environments. Retention, encryption, and access controls are identical between sandbox and live.

This policy does not cover the mintfax marketing website.

Definitions

Personal data. Any information relating to an identified or identifiable natural person, as defined in Article 4(1) of the General Data Protection Regulation (Regulation (EU) 2016/679) and its United Kingdom equivalent.

Controller. The natural or legal person that determines the purposes and means of processing personal data, per Article 4(7) of the GDPR.

Processor. The natural or legal person that processes personal data on behalf of the controller, per Article 4(8) of the GDPR.

PHI content. The five field categories mintfax treats as Protected Health Information for retention and scrub purposes: fax content files (uploaded source documents, rendered TIFFs, preview images), cover-page body text, sender name, recipient name, and recipient company name.

Operational metadata. Non-PHI fields preserved after PHI content deletion: destination phone number, fax status, error codes, error messages, timestamps, attempt history, page count, document mime type, and document size.

Environment. A mintfax API environment. Each account holds a sandbox environment and a live environment. Retention settings are configured per environment.

Terminal classification. The point at which a fax reaches a final status of fax.delivered or fax.failed. Retention timers and zero-footprint scrub begin at this point.

Customer. The organisation that holds a mintfax account and integrates the mintfax API. Customers are businesses; mintfax does not offer a consumer product.

1. Controller identity

The mintfax service is operated by Ediblesites Ltd, UK Company Reg. 12109195, 71-75 Shelton Street, London, WC2H 9JQ, United Kingdom.

For the personal data described in this policy, Ediblesites Ltd acts as the data controller for account-level data and as the data processor for fax content submitted by customers. Section 2 sets out the split.

2. Controller and processor roles

mintfax processes personal data in two distinct capacities.

mintfax as processor. For PHI content, the customer is the controller and mintfax is the processor. The customer decides what to send and to whom. mintfax stores, transmits, and scrubs PHI content on the customer’s documented instructions. The Article 28 obligations that apply to this processing are set out in the Data Processing Addendum, available for self-serve execution in the dashboard.

mintfax as controller. For account-level personal data, mintfax is the controller. Account-level data includes dashboard user identities, billing details, API-key metadata, member email addresses, and BAA and DPA acceptance records. This category is operational regardless of any fax content that passes through the account, and is retained under the terms of this policy rather than under the DPA.

3. Personal data mintfax collects as controller

Account registration through POST /v1/account/register and POST /v1/account/register/verify collects:

• The legal name of the customer entity, where the customer supplies it for a BAA or DPA.
• A billing address and a payment method. Payment card details are collected by Stripe, as described in Section 6.
• An email address for account administration and for compliance and service notices.
• A one-time 6-digit verification code exchanged during account creation.

Dashboard users authenticate through session-based authentication. This is separate from the bearer API-key authentication used for the mintfax API. Section 13 sets out the cookies used.

When a customer accepts a BAA or DPA through the dashboard, mintfax stores a durable evidence record. The record contains:

• The account identifier.
• The template version accepted.
• The signer’s name and title.
• An accepted_at timestamp.
• The accepting IP address and user agent.
• For the DPA, a snapshot of the sub-processor list current at that moment.

Operational metadata associated with API traffic, including per-request identifiers such as X-Request-Id, is retained under the operational log described in Section 8.

4. Personal data the customer submits (mintfax as processor)

Customers submit the following categories of personal data when sending a fax. mintfax stores and processes them under the customer’s instructions and the terms of the DPA.

• Fax content files. PDFs and images uploaded by the customer, rendered TIFFs generated for transmission, and preview images.
• Cover-page body text. The free-text field submitted as cover_page_body.
• Sender natural-language fields. sender_name.
• Recipient natural-language fields. recipient_name and recipient_company.

Destination phone number is not treated as PHI. It is retained as operational metadata past PHI content retention, for support, dispute handling, and fraud monitoring, as described in the operational-metadata definition above.

The optional tags field on POST /v1/faxes is opaque to mintfax. Customers should not embed personal data in tag keys or values. Tags are stored on the fax record, returned on GET, and included on webhook payloads without further processing.

5. Purposes and lawful bases

mintfax processes account-level personal data for the purposes set out below. The lawful basis noted against each purpose is proposed under Article 6 of the GDPR and its United Kingdom equivalent, and is subject to review by mintfax’s legal advisers before publication.

• Providing the mintfax service under the customer contract. Lawful basis: performance of a contract to which the data subject is party, or steps taken at the request of the data subject prior to entering into a contract (Article 6(1)(b)).
• Meeting legal obligations, including invoicing and tax records, HIPAA record-keeping obligations, and GDPR and UK GDPR record-keeping obligations. Lawful basis: compliance with a legal obligation (Article 6(1)(c)).
• Preventing and detecting fraud, including monitoring of destination phone numbers for International Revenue Share Fraud. Lawful basis: legitimate interests (Article 6(1)(f)), balanced against the rights and freedoms of data subjects.
• Communicating service and compliance updates, including sub-processor change notices, incident notices, and material changes to this policy. Lawful basis: performance of the customer contract (Article 6(1)(b)) and legitimate interests (Article 6(1)(f)).

Consent under Article 6(1)(a) is not the operative basis for the core mintfax service.

For PHI content, mintfax processes personal data on the customer’s documented instructions under Article 28. The customer, as controller, is responsible for identifying the lawful basis for its processing and for providing any privacy information required to its data subjects.

6. Sub-processors

The current sub-processor list is published at /legal/sub-processors. Each entry names the sub-processor, its role, its region, a link to its own DPA, and its status (primary, standby, or historical).

Change notice. Adding or replacing a primary sub-processor triggers 14 days of advance notice. The notice is delivered through four channels:

• Email to account administrators who have accepted the DPA.
• A dashboard banner during the notice window.
• An Atom feed of sub-processor changes.
• The public sub-processor page.

Standby sub-processors. A separate section of the list pre-discloses candidates that may be activated on short notice. Adding a candidate to the standby list carries the same 14-day advance notice. Activating a standby (promoting it to primary) does not require additional notice.

Right to object. The DPA encodes the customer’s Article 28(2) right to object to a new or replacement sub-processor. The 14-day change window is the operational mechanism for that right.

Payment processing. Payments are processed by Stripe. Accepted card networks are Visa, Mastercard, American Express, and Discover.

7. International transfers

PHI content and operational metadata are stored in a single United States AWS region. The specific region is named on the sub-processor list.

EEA to United States. Transfers of personal data from the European Economic Area to the United States are covered by the EU Standard Contractual Clauses, Module Two (controller to processor). The clauses were adopted by Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

United Kingdom to United States. Transfers of personal data from the United Kingdom to the United States are covered by the UK International Data Transfer Addendum to the EU SCCs. The addendum was laid before Parliament on 2 February 2022 and is in force from 21 March 2022.

Other jurisdictions. Transfers from Brazil and other jurisdictions are covered by the mechanisms set out in the DPA for those jurisdictions.

Region change and region choice. The Data Processing Addendum commits to at least 30 days of advance notice before any change to the storage region for an existing customer, with a mechanism for the customer to object. When additional regions become available, customers will be able to choose a region at account creation.

8. Retention

PHI content. Default retention is 30 days from terminal classification. Customers may configure the retention window per environment between 7 and 365 days.

Zero-footprint mode. A per-environment toggle. When enabled, PHI content is scrubbed immediately upon terminal classification. Operational metadata is preserved. Default off.

Per-fax deletion. Customers may delete the PHI content of a specific fax at any time via DELETE /v1/faxes/{id}/content. The fax resource remains queryable, with PHI fields returned as null.

Audit stream. Retained for 6 years from row creation, in line with the HIPAA Privacy Rule at 45 CFR 164.530(j)(2). This retention period is fixed and is not customer-configurable.

Operational stream. Default retention 365 days, customer-configurable.

Account-level data. Account records (dashboard user identities, membership records, and API-key metadata) are retained for the lifetime of the account. On account closure, these records are deleted or anonymised within 30 days, with the exception of billing records described in the bullet below.

Billing records. Retained permanently, regardless of retention mode or environment-level settings.

Detailed retention behaviour is set out in the Data retention policy. The developer-facing configuration guide is at /docs/data-retention.

9. Data subject rights

Under the GDPR and the UK GDPR, data subjects hold the following rights, as set out in Articles 15 to 22:

• Access to their personal data.
• Rectification of inaccurate personal data.
• Erasure.
• Restriction of processing.
• Data portability.
• Objection to processing.
• Rights related to automated decision-making.

Where mintfax is the processor. Data subject requests should be directed to the customer as controller. The Data Processing Addendum obligates mintfax to assist the customer in responding to data subject requests, in line with Article 28(3)(e). The operational path for an Article 17 erasure request on a specific fax is DELETE /v1/faxes/{id}/content, executed by the customer through their environment.

Where mintfax is the controller. Data subject requests should be sent to [email protected]. That mailbox carries a one-business-day response SLA.

California residents. Under the California Consumer Privacy Act as amended by the California Privacy Rights Act, California residents hold the following rights:

• The right to know what personal information is collected and how it is used.
• The right to delete personal information.
• The right to correct inaccurate personal information.
• The right to opt out of the sale or sharing of personal information.
• The right to limit use and disclosure of sensitive personal information.
• The right to non-discrimination for exercising these rights.

Brazil. Under Article 18 of the Lei Geral de Proteção de Dados Pessoais (Law No. 13.709/2018), data subjects in Brazil have the rights of confirmation of processing, access, correction, anonymisation or blocking, portability, deletion, information about shared processing, and revocation of consent.

Other jurisdictions. Data subjects in other jurisdictions may hold equivalent rights under local law. The DPA sets out mintfax’s obligations under the LGPD, the UK GDPR, and similar regimes.

To exercise a right, contact [email protected] with sufficient information to identify the account and the data at issue. mintfax may request identity verification before responding.

10. Automated decision-making

mintfax does not carry out automated decision-making or profiling that produces legal effects or similarly significant effects on data subjects, within the meaning of Article 22 of the GDPR.

11. Security

Encryption at rest. Fax content is encrypted at rest with AES-256 envelope encryption under mintfax-managed keys. One key is provisioned per environment, with automatic rotation. Database rows are encrypted using the cloud provider’s default at-rest encryption.

Encryption in transit. TLS 1.2 minimum for both inbound API traffic and outbound webhook delivery. Webhook endpoints registered with an http:// scheme are rejected at registration.

Customer-managed encryption keys. Not offered. Encryption keys are mintfax-managed.

End-to-end encryption. Not claimed. The T.30 fax protocol is not encrypted, and the carrier and recipient legs of a fax transmission are outside mintfax’s control.

Compliance boundary. The controls in this section cover mintfax’s API infrastructure, content storage, operational databases, and application logs. They do not cover upstream carriers, recipient fax infrastructure, developer webhook endpoints, or payment processors.

12. Audit log and personnel access visibility

PHI content access events are recorded to the customer-visible audit stream. Recorded events include:

• Customer API calls that download content, including calls to GET /v1/faxes/{id}/content.
• Dashboard “View content” clicks by dashboard users.
• Any mintfax personnel action that renders customer PHI in support tooling.

Personnel access rows carry a pseudonymous staff identifier and a mandatory reason field. Every such row is visible to the customer in the audit feed.

Customers may export the audit stream via GET /v1/account/audit (paginated JSON) or as a CSV download from the dashboard. Each row includes prev_hash and row_hash fields, so customers can verify chain integrity offline using a published reference verifier.

13. Cookies

The mintfax dashboard uses session cookies to authenticate signed-in users. These cookies are strictly necessary for the dashboard to function.

The mintfax API does not set cookies. API traffic is authenticated by bearer API key.

This policy does not cover cookies used by the mintfax marketing website at mintfax.com.

14. Data breach notification

Where a personal data breach affects account-level data for which mintfax is the controller, mintfax notifies affected data subjects and the relevant supervisory authority where required. The notifications are made in line with Articles 33 and 34 of the GDPR.

Where a personal data breach affects fax content processed on behalf of a customer, mintfax notifies the customer without undue delay, in line with Article 33(2) of the GDPR. The notification provides the information the customer needs to meet its own notification obligations. The specific notification timing is set out in the Data Processing Addendum.

15. Children’s data

The mintfax service is directed to businesses and their developers. It is not directed to children under 16, and mintfax does not knowingly process personal data of children under 16.

16. Frameworks not held

mintfax does not hold SOC 2, ISO 27001, HITRUST, FedRAMP, or PCI DSS Level 1. These frameworks are not offered.

For HIPAA, mintfax operates under a signed Business Associate Agreement with each covered customer. For the GDPR, the UK GDPR, the LGPD, and similar data-protection regimes, mintfax operates under a Data Processing Addendum.

Data residency and customer-managed encryption keys are addressed in Sections 7 and 11 respectively. Neither is offered as a current capability.

17. Complaints to supervisory authorities

United Kingdom. Data subjects in the United Kingdom may complain to the Information Commissioner’s Office. Details of how to complain are published at ico.org.uk/make-a-complaint.

European Economic Area. Data subjects in the EEA may complain to their national data protection authority. A directory of authorities is maintained by the European Data Protection Board at edpb.europa.eu/about-edpb/about-edpb/members_en.

Other jurisdictions. Data subjects in other jurisdictions may hold equivalent rights of complaint under local law. Contact [email protected] for guidance on the applicable authority.

18. Governing law

This policy is governed by the laws of England and Wales. Where a data subject holds rights under the GDPR, the UK GDPR, the LGPD, the CCPA and CPRA, or another regime, those statutory rights are not affected by this choice of governing law.

19. Changes to this policy

Material changes to this policy are dated on this page through the effective_date and last_updated fields shown at the top. Material changes affecting customer processing, such as the addition of a sub-processor or a change to the storage region, follow the sub-processor change-notice mechanism at /legal/sub-processors.

Related documents

• Terms of service
• Data Processing Addendum
• Data retention policy
• Sub-processor list
• Data retention developer guide
• HIPAA developer guide

Contact

For questions about this policy, contact [email protected]. The mailbox carries a one-business-day response SLA.