Privacy Policy

This Privacy Policy explains how 854 Labs LLC (“854 Labs”), an Indiana limited liability company operating html.contact (“html.contact”, “we”, “us”, or “our”), handles information when you use html.contact.

html.contact is a form backend. Customers create forms, whitelist source domains, verify recipient emails, receive submissions in a dashboard, optionally store one attachment, and send notification emails.

Roles

For form submissions, html.contact processes submission content on behalf of the customer who created the form. End users who submit forms should review the privacy policy of the website or organization operating that form.

For account registration, billing, support, security, abuse prevention, product analytics, legal compliance, and service administration, html.contact processes certain information for its own business and service-administration purposes.

Customers are responsible for deciding what their forms collect, providing their own notices and consents, and using html.contact lawfully.

Information We Collect

We may collect:

Account information, such as email address, first name, and last name.
Sign-in provider information when you sign up or sign in with Google, LinkedIn, or Slack: the provider’s account identifier, your verified email address, your name, and the profile photo URL the provider returns, which is stored with your account. We also store the tokens the provider issues at sign-in: access and refresh tokens are encrypted, and any ID token, a signed statement of your identity at that provider, is stored as issued. We do not use these tokens to access your Google, LinkedIn, or Slack account after sign-in.
Sign-in session records, including the IP address and browser user agent of each signed-in session.
Rate-limit records for account and sign-in requests, such as sign-in, sign-up, and password-reset requests. Our authentication library stores each record with the requester’s IP address and the request path. Records are deleted by that library while it handles later requests and by our scheduled cleanup, within about a day after the last request (see Retention, Export, And Deletion).
Verified recipient emails linked to an account.
Form configuration, allowed domains, form names, and routing settings.
Form submission fields, such as names, emails, phone numbers, messages, and other fields chosen by the customer.
One optional attachment per submission, if the customer form accepts file uploads.
Network and request metadata for each submission, including blocked attempts that are stored. See Submission network and request metadata.
Connection details for integrations a customer sets up, such as Slack workspace and channel identifiers, webhook endpoint URLs, and the credentials those connections need. See Slack, webhook, and Zapier connections.
Agency account information, such as invited teammates and client contacts. See Agency accounts.
Email delivery and audit metadata, including recipient status, provider status, message IDs, and delivery lifecycle information when available.
Billing, subscription, invoice, and usage metadata processed through Stripe.
Product analytics events using internal unique IDs rather than email addresses.
Support, privacy, legal, security, and trust correspondence.

Submission Network And Request Metadata

When a form submission reaches html.contact, we store the following with the submission record. This applies to accepted submissions and to blocked or rejected attempts that are stored:

The visitor’s IP address.
The source host and URL, the Origin and Referer headers, and the browser user agent.
The request metadata Cloudflare attaches to the request. Depending on the request, this can include approximate country, region, city, postal code, latitude and longitude, time zone, network (ASN) details, the Cloudflare data center, and connection details such as the TLS version. Location values are derived from the IP address and are approximate.
Keyed hashes of the IP address, used for submission rate limits and abuse controls.

We use this metadata to enforce allowed-domain checks, screen spam, apply rate limits, investigate abuse and security issues, and support customers. The raw IP address and the full Cloudflare request metadata are available only to html.contact staff for those purposes. The customer’s dashboard shows the approximate location, source, and user agent of a submission, and CSV exports include the approximate location. The Agency API and MCP integration do not return raw network or security metadata.

We keep this metadata for as long as the submission itself is stored, as described in Retention, export, and deletion.

Prohibited Data

html.contact is not intended for sensitive or regulated data. Do not use the service to collect or process:

Health information or PHI.
Payment card numbers.
Social Security numbers, tax IDs, government IDs, or identity documents.
Passwords, private keys, API keys, secrets, or credentials.
Children’s data.
GLBA, FERPA, HIPAA, PCI, or similar regulated workloads.
Other highly sensitive personal data.

See the Acceptable Use Policy for more.

How We Use Information

We use information to:

Provide, operate, secure, and improve html.contact.
Receive, store, display, export, and route form submissions.
Send notification, verification, billing, security, and support emails.
Enforce allowed-domain checks, recipient verification, rate limits, spam screening, usage limits, and abuse controls.
Provide account, billing, and customer support.
Monitor reliability and product usage.
Investigate abuse, security reports, legal requests, and policy violations.
Comply with legal, accounting, tax, and operational obligations.

Product Analytics

We use PostHog for product analytics to understand usage patterns and improve the product. Public and authentication pages use cookieless analytics without PostHog browser storage or identified visitor profiles. Inside the signed-in app, analytics may use local browser storage and an internal unique user ID so we can understand product usage over time.

We do not use PostHog for advertising, cross-context behavioral advertising, email tracking, session replay, or form-submission inspection. Analytics events use internal unique IDs rather than email addresses, and our analytics helpers deny or redact sensitive properties such as emails, form keys, API keys, submitted fields, message bodies, Stripe payloads, cookies, passwords, submission IDs, and attachment IDs.

On public pages, we prefer analytics configurations that avoid non-essential persistent storage where feasible. Logged-in app analytics may use product analytics tied to internal unique IDs.

Connected MCP Clients

A verified, fully onboarded account holder may authorize a compatible AI or coding-agent client, including ChatGPT, with specific scopes. The default forms:read scope permits committed public-documentation tools, bounded form configuration and account usage, public installation instructions, deterministic form-readiness checks, and bounded review of form markup supplied by the client. The separate forms:write scope permits confirmed form creation, allowed-domain replacement, basic form-setting changes, synthetic test submissions, and owner-only notification tests.

Recipient and submission data require additional, non-default authorization. With recipients:read, a client may list account-linked email addresses and their verification and deliverability state and may read a form’s complete To, CC, and BCC routing snapshot. With recipients:write, a client may send a verification email to a proposed linked address and, after confirmation, replace a form’s complete routing snapshot using verified linked addresses. With submissions:read, a client may list bounded submission metadata and read the visitor-provided fields and safe attachment metadata of a specifically selected submission. Account holders should authorize only the scopes needed for the task.

Documentation tools use a fixed build-time allowlist and do not fetch user-supplied URLs. Form diagnosis returns bounded status codes and recommendations without recipient addresses, suppression reasons, billing internals, or submission content. Form-code review does not execute the supplied markup or fetch a URL, and does not return the supplied code. Supply only the relevant form markup and omit unrelated source files, secrets, tokens, credentials, and personal data. Submission list results omit visitor fields and identity. Submission detail results exclude raw network and security metadata, full source URLs, email-provider identifiers, internal spam signals, event payloads, and private attachment-storage keys. The MCP integration does not expose payment records, billing management, account administration, API-key management, deletion actions, arbitrary outbound email, or linked-email deletion.

A synthetic MCP test is stored as a submission, consumes normal accepted-submission usage, and may cause a real notification email to configured form recipients. In contrast, an owner-only notification test sends only to the signed-in account email, does not notify the form’s To, CC, or BCC recipients, does not create a submission, and does not consume submission usage. A linked-email verification request sends a real email only to the proposed address. These actions require an exact confirmation in addition to the applicable authorization scope.

For MCP actions that can change product or external state, html.contact stores content-free tool diagnostics such as account/client identifiers, tool name, outcome, error code, timing, and a keyed resource reference. Read-only MCP tools do not create diagnostic events. These events never store tool arguments or results.

The third-party client’s own privacy terms and data controls apply to information processed by that client. html.contact does not send account or form data to OpenAI merely because the MCP endpoint exists; information is returned to an OpenAI service only when an account holder connects and authorizes an OpenAI client and that client requests an authorized tool. Disconnect the client and revoke its html.contact authorization when it should no longer act for the account. MCP access tokens are separate from browser sessions, html.contact API keys, and social-provider tokens.

Slack, Webhook, And Zapier Connections

Customers can send new accepted form responses to other services. html.contact sends data to these services only after the customer connects them, and only for the forms the customer chooses. Blocked spam, rejected attempts, and synthetic test submissions are not sent to them.

Slack notifications. When you connect a Slack channel, we receive and store, encrypted, the incoming-webhook URL Slack issues for that channel, together with your Slack workspace and channel names and identifiers. For each new accepted response, we post the form name, the submitted fields you chose for that destination, and a link to the submission in html.contact to the selected channel.
Signed webhooks. You provide each endpoint URL, which we store encrypted. We generate a signing secret, store it encrypted, and use it to sign each request. For each new accepted response, we send the form ID and name, the submission ID, the submitted fields you chose, and a link to the submission in html.contact to that URL.
Zapier. The html.contact Zapier app is available to invited pilot accounts. When you connect it, Zapier receives OAuth credentials, which we store as hashes, for the forms you approve. For each new accepted response on an approved form, Zapier receives the submitted fields, submission details such as the form name, submission ID, and time, a link to the submission in html.contact, and access to download that submission’s attachment if it has one.

For these deliveries, encrypted retry payloads expire after seven days, and we keep delivery history, such as status, attempt times, and safe error codes, for up to 30 days. Data delivered to Slack, a webhook endpoint, Zapier, or the apps your Zaps connect stays in those services under their own terms, and is not deleted when you delete the submission from html.contact. You can disconnect a destination at any time.

Signing in with Slack is separate from Slack notifications and does not connect a channel.

Google Sheets Connections

Google Sheets access is currently limited to pilot accounts. When this integration is available and you connect Google Sheets, we receive your Google account identifier, verified email address, and authorization credentials. We encrypt the stored credentials and use them to maintain the connection, including refreshing access while you are away. This connection is separate from Google sign-in to html.contact.

Google Picker lets you select existing spreadsheet files. We request access to the files you select, rather than your entire Drive. Google grants permission at the spreadsheet-file level, including its worksheets. We read selected-file metadata, worksheet names, managed headers, and submission IDs to configure your destination, maintain columns, and reconcile deliveries. Setup may inspect an existing worksheet to confirm that it is empty. We do not persist unrelated worksheet contents.

When you enable a form’s destination, we send newly accepted responses to its dedicated worksheet. Rows include submitted fields, attachment filenames where applicable, the submission ID and timestamp, and an authenticated link to the submission. Attachment bytes and public attachment-download links are not exported. Existing submissions are not exported automatically.

Encrypted retry payloads expire after seven days. We retain safe integration-delivery metadata for up to 30 days. You can pause or remove a form’s destination, disconnect the shared Google connection in Settings, or revoke the grant through your Google account. Disconnecting deletes locally usable Google credentials and cancels pending exports. Archiving an Agency client, or turning off Agency features, does the same for that client’s Google, Slack, webhook, and Zapier connections. Rows already exported to Google remain under your control and are not deleted when their source submission is deleted from html.contact. Google’s own privacy terms apply to information stored there.

We do not sell Google user data, use it for advertising, or use it to train generalized AI or machine-learning models. Our use and transfer of information received from Google APIs follows the Google API Services User Data Policy, including its Limited Use requirements.

Agency Accounts

An Agency account can manage forms for its clients. When an Agency uses these features, we process:

Teammates and client contacts the Agency invites: their email address, role, assigned client workspaces, and invitation status. We send the invitation email, and the person’s own account details apply once they accept.
Client workspace names and the private client details and notes the Agency enters, such as a primary contact’s name and email address. Saving these details does not invite, email, or verify anyone.
Portal branding, such as the Agency name and logo shown to its client contacts.
Access history: sign-in and access events for up to 180 days. These events record a keyed network fingerprint rather than the raw IP address.

When an Agency archives a client, the client’s Google, Slack, webhook, and Zapier credentials stored with us are deleted, and the client’s data stays readable to the Agency’s Owners and Admins. When an Agency deletes a client, we delete that client’s forms, submissions and uploaded files, connections, notification email addresses, client details and notes, and activity. We keep billing usage totals, API key history, access history until it expires, and a record that the client was deleted. Deleted submission identifiers are kept for 90 days so that late retries and delivery updates cannot recreate the deleted content.

The Agency decides which teammates and client contacts to invite and what client details to enter, and is responsible for having a lawful basis to share them with us.

Cookies And Similar Technologies

html.contact may use necessary cookies and browser storage for login, sessions, security, preferences, dashboard operation, and first-party referral attribution for signup credits or promotions.

We do not use advertising cookies or cross-site advertising trackers.

html.contact is an endpoint service. It does not automatically embed cookies, trackers, scripts, or banners on customer websites. Customers are responsible for their own website notices, cookie disclosures, form labels, and consent requirements.

We share information with service providers that help operate html.contact. These include infrastructure, billing, analytics, uptime/status, and email-alias providers. See Subprocessors.

We may also disclose information when needed to:

Provide support or respond to a request.
Process billing through Stripe.
Send operational emails.
Investigate abuse, security incidents, fraud, spam, or policy violations.
Comply with law, legal process, or enforceable government requests.
Protect html.contact, customers, end users, or the public.
Transfer the service in connection with a merger, acquisition, financing, reorganization, or sale of assets.

We do not sell personal data. We do not share personal data for cross-context behavioral advertising.

Storage And International Processing

html.contact is operated from the United States. Information may be processed in the United States and in other locations where our service providers operate.

The service is U.S.-first at launch. We do not claim EU data residency or broad enterprise EU/UK compliance coverage at launch. If your organization needs a DPA, email legal@html.contact.

Retention, Export, And Deletion

Submission persistence is a core product feature. We store submissions so customers can view, export, and manage them. Accepted submissions, with their network and request metadata, are kept until the customer deletes them or their account is deleted.

We may move the submitted fields and request metadata of submissions older than 12 months from our database into Cloudflare R2 object storage, where uploaded files are also kept, stored separately for each account. A moved submission stays available to view and export and is deleted with the rest of the submission. Text search in the dashboard may not search the submitted fields of moved submissions.

Blocked submissions are handled differently. Submissions that html.contact blocks automatically as spam, or because they fail an allowed-domain or honeypot check, are stored in a shortened form: long field values are cut to a few kilobytes, and long request details, such as browser and referring-page information, are cut too. These blocked submissions are purged together with their network and request metadata 90 days after they are received. Submissions held because an account reached its usage limit, and submissions a customer marks as spam, are kept until the customer deletes them.

Rate-limit records, which can include IP addresses or hashed IP signals, are deleted within about a day after their limit window ends.

Customers can export forms and submissions through available product features. Account access, correction, export help, and deletion requests can be sent to support@html.contact. Privacy-specific questions can also be sent to privacy@html.contact.

Deletion may exclude limited records retained for security, abuse prevention, billing, tax, accounting, legal, audit, or compliance reasons.

We do not promise an automatic inactivity deletion policy at launch.

Security

We use technical and organizational measures designed to protect the service. See the Security page for details.

No internet service can guarantee perfect security. You are responsible for protecting your account, using strong passwords, keeping private API keys secret, and never placing hc_live_ keys in browser code.

Children

html.contact is not intended for children and must not be used to collect children’s data.

Your Choices And Requests

Depending on where you live, you may have rights to access, correct, delete, or receive a copy of certain personal information. Send requests to support@html.contact. We may need to verify your identity or account ownership before acting on a request.

End users who submitted a form on a customer website should contact the website or organization operating that form first.

Changes

We may update this Privacy Policy from time to time. If changes are material, we will provide notice by email, in-app notice, or another reasonable method.

Contact

For privacy questions, email privacy@html.contact. For support, access, export, or deletion requests, email support@html.contact.

Written correspondence may be sent to:

854 Labs LLC
5534 Saint Joe Road
Fort Wayne, IN 46835
United States