Skip to content
Start free trial

DRAFT — not approved for production. Not yet reviewed by the company or by counsel.

Luma Proposals — Privacy Policy

DRAFT — requires legal review. This is a starter document prepared by the product team, not by a lawyer. It describes what the Luma software does today, but it is not final and must be reviewed by qualified counsel, including for the laws that apply where Luma is offered, before it is relied on. Every item in [SQUARE BRACKETS] is a fact or a decision the company has not yet supplied.

Version: 2026-10-02-draft

Last updated: 2 October 2026

1. Who we are

Luma Proposals ("Luma") is operated by Lumetrin Consulting Services LLC (doing business as Lumetrin Technologies), 4600 Forbes Blvd, Ste 301, Lanham, MD 20706-4359, United States ("we", "us"). Privacy questions and requests: privacy@lumetrin.com. [DATA PROTECTION OFFICER OR EU/UK REPRESENTATIVE, IF REQUIRED.]

2. Two roles

  • For account holders, we decide how their account data is used. For that data we are the controller.
  • For the content businesses put into Luma — their proposals and their clients' details — the business decides. We process that data on the business's behalf and on its instructions, under the Data Processing Addendum. If you received a proposal from a business through Luma, that business is responsible for your data; please contact it first. We will help it answer your request.

3. What we collect

Account data. Your name, your email address, whether you have confirmed it, and your password in a one-way scrambled form (we never store the password itself). The version of the Terms of Service you accepted and when.

Sign-in sessions. When you sign in we set a session cookie. We store only a fingerprint of the cookie's value, the time the session was created and last used, and when it expires.

Workspace data. Workspace names, branding, team members and their roles, invitations, API keys (stored only as fingerprints, with a short prefix for display), webhook endpoints, and a record of administrative actions taken in the workspace (who did what, and when).

Proposal content. Everything a business writes into a proposal, uploaded images, and client records the business enters, such as a contact's name and email address.

Recipient data. When someone opens a proposal link, Luma records that the proposal was viewed. When a recipient chooses an option or accepts, Luma records the choice and, on acceptance, the name, email address, organisation and title they enter, the option and figures shown, the terms as displayed, and the time. These view, choice and acceptance records do not include the recipient's IP address or browser details. Where a business presents a proposal on a website of its own through Luma's API (a custom frontend), that website collects these details and passes them to Luma.

Payment data. Payments are made through Stripe. Card and bank details go to Stripe and never reach Luma. Luma stores the Stripe identifiers, amounts, currency and status of payments and subscriptions.

Email. Luma sends only the email the service needs, never marketing email:

  • Account email to account holders: address confirmation, password reset, confirming a new email address, and team invitations (which name the workspace and the member who sent the invitation).
  • Proposals a business sends. When a workspace member sends a proposal by email, Luma writes to the recipient on the business's behalf. The message carries the recipient's name and email address, the business's name, the sending member's name and email address (replies go to that member), the proposal's title, its link and when the link expires, and any personal note the member wrote. Luma keeps the note nowhere but in the message itself.
  • Activity notifications to workspace members, when a client first opens a proposal, accepts it, or pays. They name the proposal and, where Luma has them, the person who acted, the option chosen and the amount. They go only to members whose own address is confirmed, and each member can turn each one off, separately for each workspace. Luma records which member was told about which event, so that nobody is told twice.

Every message holds the recipient's name and address, the sender, the subject and the text. Luma delivers it through Postmark, its email service provider: Luma hands each message to Postmark, which sends it on, and Luma keeps no copy of a message Postmark has accepted. Postmark keeps its own record of the messages it delivers. [CONFIRM POSTMARK'S RETENTION OF MESSAGE CONTENT AND DELIVERY RECORDS.] Open tracking and link tracking are off, so the links in Luma's email lead straight to Luma. A deployment not yet switched to Postmark delivers no email: it keeps each message in its own database instead, for the time set out in section 8.

Bounces and spam complaints. Postmark reports back to Luma when a message cannot be delivered (a bounce), when its reader marks it as spam (a complaint), and when an address is added to or taken off Postmark's own list of addresses it will not mail. From these reports Luma keeps two things:

  • A list of addresses Luma must not mail. When an address bounces permanently, its reader complains, Postmark stops mailing it, or Postmark refuses a message because it already has, Luma adds the address to this list and sends it nothing more, whichever workspace asks. The list holds a SHA-256 fingerprint of the address, never the address itself, with the reason, Postmark's code, the identifier of the message concerned, and when. A fingerprint cannot be turned back into an address, but anyone who already has an address can check whether it is on the list, so it is still personal data. A member who tries to email a listed address is told that the address no longer accepts mail from Luma, never why. The list is shared by every workspace, so that a person who refused mail sent through Luma is not mailed again by another business using it.
  • A record of each report: Postmark's identifier of the message, the kind of report and of bounce, the kind of message it was (for example a proposal or an invitation), what Luma did about it, and when. It holds no address; a report about an address rather than one message is filed under the address's fingerprint. From this record, workspace members see on a proposal's page when a proposal they emailed bounced or was reported as spam.

[LAWFUL BASIS FOR THE SUPPRESSION LIST AND THE REPORT RECORD, AND WHETHER LUMA HOLDS THE LIST AS CONTROLLER OR AS PROCESSOR FOR THE BUSINESSES WHOSE EMAIL CAUSED EACH ENTRY: to be set by counsel.]

Abuse protection. To limit how often a request can be repeated, Luma counts requests per IP address, per typed email address and per link. It stores only a fingerprint of each, never the value itself, and removes each count about an hour after its window closes.

Hosting logs. Our hosting provider may keep request logs, which can include IP addresses and browser details. [CONFIRM THE PROVIDER'S LOG CONTENT AND RETENTION.]

4. Cookies

Luma uses only cookies that are strictly necessary for the service to work:

  • luma_session keeps you signed in. It is set when you sign in and lasts up to 30 days, or until you sign out.
  • luma_flash carries a newly created proposal link to the next page after publishing. It lasts ten minutes and is readable only on that page.
  • luma_dev_flash carries a newly created API key or webhook signing secret to the Developers page, so it can be shown to you once. It lasts ten minutes, is readable only on that page, and is cleared as soon as the page has shown it.
  • luma_link keeps one proposal link open in the browser that opened it. It is set when a recipient opens a proposal link that has not expired or been withdrawn, holds that link's access key, and is sent only to that link's own pages, never to other proposals, the dashboard or the API. Page scripts cannot read it (HttpOnly), on the hosted service it is sent only over secure connections (Secure), and it is marked SameSite=Lax. It lasts until the link expires, and at most 30 days. It is used only to authenticate that proposal link, never for tracking or advertising.

Luma sets no analytics or advertising cookies.

5. How we use personal data

  • To provide the service: accounts, sign-in, workspaces, publishing and sharing proposals, recording acceptances and taking payments.
  • To keep it secure: rate limiting, preventing abuse, investigating incidents.
  • To send the email the service needs: account email, proposals a business asks Luma to send on its behalf, and the activity notifications members have not turned off; and to stop mailing an address that bounced or whose reader reported Luma's mail as spam.
  • To bill for subscriptions and meet our legal, tax and accounting obligations.

We do not sell personal data, and we do not use Customer Content to advertise to anyone. [LEGAL BASES FOR EACH PURPOSE, WHERE THE GDPR OR SIMILAR LAW APPLIES: to be set by counsel.]

6. Who we share it with

  • Service providers that host and run Luma for us, bound by contract to use the data only to provide their service: [LIST TO CONFIRM FOR PRODUCTION — the current build uses Vercel (hosting and file storage), Neon (database), Stripe (payments and billing) and Postmark (email delivery)]. The Data Processing Addendum keeps the list.
  • Stripe, when a business connects a Stripe account or a recipient pays, under Stripe's own privacy policy.
  • Systems a business connects. A workspace can configure webhooks and API access, for example to its own CRM. Luma then sends the data that business directs to the systems it chose.
  • Authorities, where the law requires it.

7. International transfers

Luma's application runs on Vercel in the United States (region iad1, Washington, D.C.), and its database runs on Neon in the United States (AWS us-east-1). Uploaded files are stored with Vercel, and their daily backup copies in a separate store in the United States. Our providers' own processing locations are set out in their terms. [COUNSEL: THE SAFEGUARDS FOR TRANSFERS FROM OUTSIDE THE UNITED STATES, FOR EXAMPLE STANDARD CONTRACTUAL CLAUSES.]

8. How long we keep it

  • One-time links for confirming an address, resetting a password or changing an email address expire after 24 hours, 30 minutes and 60 minutes respectively.
  • Sessions expire after at most 30 days.
  • Rate-limit counts are removed about an hour after their window.
  • An address on the list of addresses Luma must not mail stays there until Postmark lifts it — Postmark tells Luma when the address is reactivated there — or until we lift it by hand. Deleting an account or a workspace, or anonymising a client, does not remove it (section 9).
  • The record of each bounce or complaint report is deleted 45 days after it arrives, the time Postmark keeps its own history of a message by default.
  • Email Luma keeps instead of delivering is deleted after eight days: the longest any link in it stays usable (an invitation's seven days) plus one. It goes sooner when the account it was sent to is deleted, when the workspace it concerns is deleted, or when the business anonymises the client it names.
  • Account, workspace and proposal data are kept while the account or workspace exists. When a subscription ends, the workspace is restricted but its data is kept until an owner deletes the workspace; Luma does not delete it automatically. When an owner deletes a workspace, its data is deleted at once, except the anonymised record described below; backup copies of uploaded files expire within about 30 days. [COUNSEL: ACCEPTANCE AND PAYMENT RECORDS THE LAW REQUIRES US OR OUR CUSTOMERS TO KEEP.]

9. Your rights

Depending on where you live, you may have the right to access, correct, delete or export your personal data, to object to or restrict some uses, and to complain to a data protection authority. Some of this you can do yourself in Luma:

  • Account holders can change their email address and password, and delete their account, from their account page. Deleting it signs you out everywhere, removes you from every workspace, deletes any workspace where you are the only member, deletes the email Luma kept for your address and anonymises the account; a workspace you own that has other members must first be handed to one of them or deleted.
  • Workspace owners and admins can download an export of the workspace's data as one file, and can anonymise a client, which erases that person's contact, recipient and signer details. This is how a business answers a request from someone it sent a proposal to.
  • Workspace owners can delete the workspace, which deletes its clients, drafts, templates, branding, images and the email Luma kept about it.
  • Workspace members choose which activity notifications they receive.

The list of addresses Luma must not mail is kept after an account is deleted, a workspace is deleted or a client is anonymised. It holds only the address's fingerprint, and a list that forgot an address on deletion would mail again someone whose address bounced or who reported Luma's mail as spam. The fingerprint stays until Postmark lifts the address, as section 8 says. [HOW A PERSON ASKS TO BE MAILED AGAIN, AND COUNSEL TO CONFIRM KEEPING THE FINGERPRINT AFTER AN ERASURE REQUEST.]

Published proposals, acceptances and payments are kept after a deletion or anonymisation as the record of what was offered, agreed and paid. The people who signed or received them are anonymised, but a published proposal still shows the client name and company name it was published with, and any text its author wrote. An anonymised acceptance keeps, in place of the signer's email address, a keyed fingerprint of it (an HMAC computed with a secret key only Luma holds), so that if the address is presented later the record can still be matched to it. For anything else, including a copy of your own account data, contact privacy@lumetrin.com. [RESPONSE TIMES AND IDENTITY CHECKS.]

10. Security

Luma stores passwords, session cookies, share links and API keys only as one-way fingerprints, keeps each business's data separate from every other business's, and serves a proposal only to someone holding its link, or to the browser that opened that link and holds its luma_link cookie (section 4). No system is perfectly secure; if a breach affects your data we will tell you as the law requires.

11. Children

Luma is a business tool and is not directed at children. You must be at least 18 years old to create an account.

12. Changes

Each version of this policy carries a version identifier, shown at the top. We will tell account holders about material changes before they take effect.

13. Contact

privacy@lumetrin.com, 4600 Forbes Blvd, Ste 301, Lanham, MD 20706-4359, United States.