Privacy
Updated 12 October 2026
This page covers the public website at heimdallresearch.com and the customer app at app.heimdallresearch.com, including its API and MCP server. Both are operated by Heimdall Research.
This website
The website does not use cookies or advertising trackers. It runs small scripts of our own for data tables, maps, search pickers and accessibility helpers, and loads one third-party script for anonymous site analytics, described below. Our accessibility script keeps your motion setting in your browser's local storage.
If you email us or use a contact form, we receive the details and message you send, and we use that information only to respond and to manage a professional relationship if one follows.
The site runs on third-party hosting infrastructure. The hosting provider keeps standard server logs, which may include IP address, user agent, and request path, for security and reliability; we do not keep our own copy.
We keep basic site statistics on the server. When a page loads, we record the page, the site that linked to it, any campaign tags in the link, approximate country and region, the name of the network the request came from, and a general device type. We also record clicks on dataset download links. Our own statistics hold no IP addresses, set no cookies, and do not try to identify individual visitors. These records are kept for up to three months.
We also use an analytics service to see which pages and sections people read and click, how far they scroll, and which paths through the site lead to sign-up. It runs without cookies or browser storage: the service links the pages of one visit using a daily, one-way hash of the request that it discards, and it does not build a profile of you. Some visits may be recorded as anonymous session replays of page activity; anything typed into a form is masked and never recorded. That service processes this data in the United States on our behalf. If your browser sends a Do Not Track signal, the script does not run. The script does not read Global Privacy Control.
Dataset downloads need no form or sign-up. Published files are on the mirror named on each dataset page (Zenodo, Kaggle and Hugging Face), and those services' own privacy policies cover what they collect.
If you send career materials, we receive whatever you choose to send, keep it to consider for future work, and use it for nothing else. We do not sell or share it. We do not ask for Social Security numbers, identity documents, or dates of birth, and you should not send them. We keep career submissions for up to two years unless you ask us to delete yours sooner. See careers for what to send.
If you sign up for updates by email, we send a confirmation link first and keep nothing on file until you click it. After that we keep your email address, the page you signed up from, and the date you confirmed, and we use them only to send you updates about new datasets, observations and field notes. Our email delivery provider holds your address to send those emails and for no other purpose. Every email carries an unsubscribe link; unsubscribing deletes our record and stops all further emails. We do not sell or share the list. Contact-form messages never add you to it.
Customer app, API and MCP server
You can download open files without an account. An account is needed for an API key, for the MCP server, and for saved areas. This section covers what the app stores and who else sees it.
What we store about your account
- Your email address, your name if you gave one, and whether the email is verified.
- Your organization's name, type and email domain, and your role in it.
- The plan on the account. During early access the plan is labelled Early access.
- Whether you turned on an authenticator, and hashed recovery codes if you did.
- How you signed up and any campaign tags in the link you used, and when you last used the app.
- Saved areas you create. An invite stores the invited email address and the role until it is accepted, expires or is withdrawn.
When someone signs up we send ourselves a notice with the name, email address, organization and campaign tags from the sign-up.
Signing in
You sign in with an emailed code or a password. Our sign-in provider, WorkOS, holds the identity record and the password; we never store a password. Each time you sign up or sign in, we pass the provider your email address, your IP address and your browser's user agent. Sign-in codes and key notices are sent through our email provider, Resend.
Creating, replacing and revoking an API key ask for a second code, sent by email or taken from your authenticator if you turned one on. Creating a key skips that step for the first key made at sign-up and, if you have no authenticator, for a key made within 10 minutes of signing in with an emailed code. We email the account whenever a key is created or revoked. The email names the key prefix, not the secret.
To limit repeated sign-in code requests we keep the visitor's IP address (the first half of an IPv6 address) and the email address being used, each for one hour.
Password reset links and the sign-up link in our emails carry their value after the # sign. A browser does not send that part when it asks for the page, so it does not reach our server logs. Older links that carry the value in the address still work.
Cookies and session records
| Cookie | What it does | How long |
|---|---|---|
hr_session | Keeps you signed in. HTTP only, SameSite Lax, and Secure on HTTPS. | Up to 30 days. The session ends after 24 hours without use. |
hr_csrf | Makes sure a form post comes from the app. | 8 hours |
hr_auth_state | Matches the return trip from the hosted sign-in page. | 10 minutes |
These cookies make sign-in work. They are not advertising cookies. For each session we store a hash of the cookie value, the IP address and user agent from sign-in, and the session tokens the sign-in provider issued. We do not store the cookie value itself.
A session record is not deleted when the session ends or when you sign out. It stays until the account is purged, described under How long we keep account data.
API keys, usage and assistants
We store a hash of each API key and a public prefix. The full secret is shown once, when the key is created. Each API or MCP call adds a usage row with the time, organization, key, channel (API, MCP or download), dataset, route or tool name, status and a size. A usage row holds no IP address and no prompt text.
If you connect an assistant, we also store its client name, the key prefix it used, and its user agent. Do not put a person's name, email address or other private identifier in a prompt. A place is fine. Your assistant provider is a separate service with its own privacy terms.
Analytics in the app
The app uses the same kind of analytics. Its browser script records page views and page leaves and does not use
autocapture. It stores an anonymous ID in local storage under heimdall_portal_anon_id
and does not identify you or your organization from the browser. The analytics library may
also set its own cookie. Text, form fields and element attributes are masked in session
recordings, and sign-in, sign-up, password reset, verification and billing pages, and the
two-step and recovery code screens, are not recorded.
Do Not Track and Global Privacy Control switch the browser script off. Our server still sends the analytics service a few product events with your user id and organization id: account created, organization created, key created, first API call, purchase completed, and in-app actions such as saving an area, creating an alert, starting checkout, sending an invite or copying an assistant setup line. We do not set a deletion period for analytics data, so it is kept under that provider's settings.
Error reports and server logs
The live API and the live app send error reports and a sample of performance traces (about one request in ten, and every sign-in and checkout page in the app) to an error-reporting service. Session replay is off there. Authorization headers, cookies, API keys, sign-in codes and email addresses are removed before a report is sent. We do not set a deletion period for error reports, so they are kept under that provider's settings.
The app's web server log records the method, host, protocol, path, status, size and timing of a request. It leaves out query strings, headers and visitor addresses. The API log records the method, path and status in the same way. The hosting provider, Railway, keeps its own request log with the visitor's address and user agent for abuse handling.
Payments
Stripe takes card payments through its hosted checkout. During early access checkout is refused and nothing is charged. We never store a full card number. We store Stripe customer, subscription and invoice ids when a subscription or invoice exists, and the contact email, purchase order number and notes on an invoice request.
How long we keep account data
The owner of an account can delete it in the app settings. Deleting turns off the organization's API keys, ends every member's sessions, pauses saved areas and cancels subscriptions. The rows stay for 90 days after the request so a mistake or a break-in can be undone. After that a purge removes the organization's usage rows, orders, sessions, keys, saved areas, memberships and account rows, and the user records of members who belong to no other organization.
Until then, and while the account is open, we keep account data as long as the account exists. Usage rows and session records are not cleaned up on their own. A log row that says an account was deleted stays, without the organization link. Records of invites in that log can hold the invited email address. A product-updates email subscription is a separate list. Its unsubscribe link removes it.
A member can download a copy of their own account data from the app. An owner or admin can download the organization's export. Keys appear as prefixes and secrets are left out.
What we do not do
We do not sell personal information and we do not share it for advertising across sites. We do send it to the providers below so they can host the site, store files, send email, sign you in, measure use, report errors and take payment.
The Data Use Policy sets out what people who use our data may do with it. The data describes counties, lakes, sea passages and storms, not individuals.
Children
Do not create an account if you are under 18. We do not knowingly collect account data from children.
Providers
| Provider | What it does | What it receives |
|---|---|---|
| Cloudflare | Hosts the website. Stores files in R2 and serves signed file links that last 15 minutes. | Requests to the site and the files. Its own server logs. |
| Railway | Hosts the API and the customer app. | Requests to them, with its own request log. |
| WorkOS | Sign-in, identity and authenticator codes. | Email address, IP address and user agent at sign-up and sign-in; the password. |
| Resend | Sends sign-in codes, key notices, update emails and contact mail. | The address and the message. |
| Analytics provider | Analytics for the website and the app. | Page events. In the app, the anonymous id and product events, some with user and organization ids. |
| Error-reporting provider | Error reports and performance traces for the API and the app. | Scrubbed errors and traces. |
| Stripe | Card payments when checkout is open. | What it needs to charge a card and identify the organization. |
| Zenodo, Kaggle, Hugging Face | Host the open dataset files. | Whatever you send them, under their own policies. |
Your requests
Write to privacy@heimdallresearch.com to see, correct or delete personal information we hold about you. We may need to confirm that the request comes from the account holder. If a law where you live gives you other rights, name the law in your email. Nothing on this page removes a right that a statute says cannot be removed. For anything else, write to info@heimdallresearch.com.
If we change this page we change the date at the top. If a change materially expands what we collect on an account, we will email the account before it takes effect.