Privacy Policy
What ShellOrbit collects, why it holds it, how long it keeps it, who processes it, and how to get it back or deleted.
This policy covers the ShellOrbit website, the ShellOrbit dashboard, the ingest endpoints, and the API, and Leak Alarm, including the GitHub App, log drains, the JavaScript SDK, and the MCP server. It explains what we hold and why in the same terms we would want to read.
Changes in version 1.4. From 19 October 2026, all email we send goes through Amazon SES, and our previous email provider no longer receives any data. The account records in Zoho CRM, product update email through Zoho Campaigns, support tickets in Zoho Desk, and the Leak Alarm sections described below apply from the same date, as does the sign-in history, with IP address, device, and approximate location, on every plan. Support tickets and contact form enquiries are now kept for 180 days from the last message.
Two kinds of data pass through the service, and they are treated differently:
- Account data is about you: your login identity, your endpoint configuration, your billing record, your account record, and your support messages. For this data we are the controller.
- Customer data is what we process for you on your instructions: event data, meaning what your providers send to your ingest endpoints, with headers, query strings, and raw payload bodies, and Leak Alarm data, meaning findings, fingerprints, and tripwire hits. Either may contain personal data about other people. For this data you are the controller and we are the processor. The data processing addendum governs it.
1. Account data we collect
Identity and authentication. Email address, display name, sign in method, and session records. Authentication is operated by WorkOS on our behalf, including single sign on where you use it. We receive the identity claims your provider releases, not your password.
Sign-in history and sessions. Each sign in, wrong password or code for an existing account, and sign out, with the time, the method, the result, the IP address, the browser and operating system from the user agent, and an approximate location (city, region, and country) worked out from the IP address by Amazon CloudFront in front of our API. For each signed in session we keep the same details plus when it was last active. Owners and admins of an organization can see this for its members; each member sees their own. We use it to keep accounts secure and to let you spot a sign in you do not recognise.
Endpoint configuration. Endpoint names, ingest identifiers, destination URLs, retry settings, transformation rules, alert settings, custom domains, and team membership.
Billing data. Plan, subscription state, billing email, country for tax, invoice history, and the metered event counts your invoice is based on. Payment is handled by Dodo Payments as merchant of record. Dodo Payments collects and holds the payment instrument. We receive a transaction record and tax status, never a full card number.
Usage and telemetry. Event counts, payload sizes, delivery attempts, response status codes, response times, error classes, dashboard actions with timestamp and actor, and API request logs. Request logs include IP address and user agent.
Account record. When you create an account we keep a record of it in Zoho CRM: your email address, name, sign in method, plan, billing cycle, monthly revenue, account and user ids, signup date, the date you were last active, and the stage your account has reached, such as verified, trial, paying, or cancelled. We also record how you found us: the UTM source, medium, and campaign, the referring site, and the first page you visited. These travel in the signup link, not in a cookie. The last active date is updated at most once a day.
Product update email. Only if you tick the marketing box at signup, which is never ticked for you, or opt in later. We send your email address, name, and the record of your consent to Zoho Campaigns, and Zoho sends you a confirmation email before anything else. Zoho Campaigns records whether each email was delivered, opened, or clicked. Unsubscribe from any email or in the dashboard at any time. Transactional email, such as sign in codes, alerts, and billing notices, is separate and does not depend on this choice.
Support tickets and correspondence. Anything you send to a ShellOrbit address, with its attachments and metadata. A ticket you create in the dashboard is held in Zoho Desk with its subject, description, your email address and name, your plan, your account and user ids, and the status and priority shown back to you; replies continue by email.
Domains and connected services. The hostnames you verify, the verification record and the result of each recheck, the GitHub repositories you connect, and the log drains you create. Credentials you give us for a connected service, such as a Postman key or an account we may revoke keys in, are encrypted with a separate key, used only for what you allowed, and deleted when you disconnect.
Enquiries sent through the contact form. First and last name, email address, company, position where you give one, subject, and message. The form posts straight from your browser to Zoho CRM, where the enquiry becomes a lead record and the reply thread is kept. Use one of the email addresses on the contact page if you would rather not have a CRM record created.
Diagnostic data. When something breaks in the dashboard, the API, or a delivery worker, an error report is sent to Sentry: the exception and stack trace, the request path and method, the endpoint and event ids involved, browser and operating system, IP address, and your account id. Request and response bodies are stripped before the report is sent, and headers carrying authorization, cookies, or signatures are removed.
Site analytics. The marketing site is measured with aggregate, cookie free counts of page views and referrers. There are no advertising trackers, no cross site profiling, and no data broker feeds.
Security research reports. If you report a vulnerability to us, we hold your report, the correspondence about it, and whatever contact address you wrote from. If you ask to be credited on the Hall of Fame, we also publish the name or handle you choose and, where you give us one, a single link to a profile or site of yours.
That publication is the one thing on this page we do purely on consent. We do not publish anything until you have told us to, silence is treated as a no, and you can have the entry changed or removed at any time by writing to security@shellorbit.com. We will act on that without asking why, and it will never affect how a report of yours is handled. Reporting anonymously is always available and is not a lesser option.
2. Customer data we process for you
For each request received at an ingest endpoint we store the method, path, query string, headers, source IP, timestamp, and the raw body, plus every delivery attempt with its destination, status code, response headers, response body excerpt, and timing. Oversized bodies are stored in object storage instead of the primary table, with the same retention.
We do not inspect payload content for any purpose other than delivering it, showing it back to you, applying a transformation you configured, and enforcing size limits. Payload content is not used to train models, is not shared with advertisers, and is not sold in any form.
You control what your providers send. If a payload should not contain a national identifier, a health record, or card data, the place to fix that is at the provider or in a transformation rule, and we can help you configure one.
Leak Alarm. We process the following only for what you verify or connect:
- Scans of verified domains. We fetch the pages and files a browser would and look for exposed keys, exposed
.env,.git, and source map files, open Supabase tables, and open Firebase rules. Content is discarded once scanned. A finding keeps the kind of key, where it was found, and a masked value such assk_…a1b2. For an open table we record its name and that it can be read, never its rows. - GitHub repositories. A read only GitHub App reads the repositories you choose. Code is scanned and discarded. A finding keeps the commit, file, line, kind of key, and a masked value, and the commit author shown by GitHub where the finding points to a commit.
- Log drains. Each line is scanned as it arrives and then dropped. Log lines are never stored.
- The JavaScript SDK. It sends masked values and one way, salted fingerprints of your app’s keys, never a key itself, so we can tell you when your real key turns up somewhere.
- Tripwires. When a tripwire is touched we record the time, the tripwire, what was touched, and the source IP address and user agent of the request. The person who touched it is usually not your user and not ours, and may be an attacker or an automated agent. We keep only that request metadata and never run anything on their machine.
- Postman checks and revoking. Using credentials you give us, we check whether your Postman workspaces are public and contain keys, and revoke keys you have allowed, after ten minutes in which you can cancel. We record what was done, when, and by whose permission.
We never test whether a key we find works, never store a key in full, never scan a domain you have not verified, and never show a full key to you or to an AI agent connected through the MCP server.
3. Why we hold each category
| Purpose | Data used | Legal basis under GDPR |
|---|---|---|
| Provide the service, receive and deliver events | Account data, event data | Contract |
| Authenticate you and keep sessions secure | Identity, session, IP, user agent, approximate location | Contract, legitimate interest in security |
| Show you and your organization’s admins who signed in, from where | Sign-in history and session records | Legitimate interest in account security |
| Bill you, including metered usage | Billing data, event counts | Contract, legal obligation for tax records |
| Notify you of delivery failures and account state | Email address, delivery outcomes | Contract |
| Keep the platform stable and abuse free | Request logs, usage metrics | Legitimate interest |
| Find and fix faults before they spread | Diagnostic data, error reports | Legitimate interest in a working service |
| Diagnose a fault you reported | Event data for the endpoint concerned | Contract, your instruction |
| Provide Leak Alarm for you | Leak Alarm data, domains and connected services | Contract, your instruction as controller |
| Keep an account record and understand how people find us | Account record in Zoho CRM | Legitimate interest in managing accounts and our own marketing spend |
| Answer a support ticket | Ticket fields, correspondence | Contract, legitimate interest |
| Answer an enquiry and keep the thread | Contact form fields, correspondence | Legitimate interest, steps before a contract at your request |
| Improve the service using aggregate metrics | Counts, sizes, latencies, error classes | Legitimate interest |
| Meet accounting, tax, and legal duties | Billing records, correspondence | Legal obligation |
| Send product update email | Email address, name, consent record | Consent, which you can withdraw at any time |
Where we rely on legitimate interest we have considered your interests too, and you can object using the contact in section 9.
4. How long we keep it
| Data | Retention |
|---|---|
| Event payloads, headers, and delivery attempts | Your plan’s retention window: 15 days on Hobby, 30 on Starter, 60 on Pro, 180 on Business. Deleted automatically after that. |
| Events you delete manually | Removed from live systems immediately, purged from backups within 35 days |
| Endpoint configuration | Life of the account, then 30 days |
| Account and identity records | Life of the account, then 30 days, after which they are deleted from live systems |
| Sign-in history and audit log | About 13 months (400 days), then deleted automatically. Your plan shows the most recent 30 days on Hobby, 60 on Starter, 90 on Pro, and a year on Business |
| Records of active sessions | Until the session ends or expires, then deleted automatically |
| Backups containing any of the above | Rolling window, expiring within 35 days |
| Request and access logs | 365 days. The CERT-In Directions of April 2022 require every service provider and body corporate in India to keep logs of all ICT systems for a rolling 180 days and to produce them to CERT-In on request. We keep them for a year, which clears that floor. These logs record which endpoint received a request and when; they do not contain payload bodies. |
| Error reports held by Sentry | 90 days, then deleted on Sentry’s schedule |
| Billing and tax records | As long as tax law requires, typically 7 years, then deleted |
| Support correspondence and Zoho Desk tickets | 180 days from the last message, then deleted |
| Account record in Zoho CRM | Life of the account, then deleted within 30 days of the account being deleted |
| Product update subscription in Zoho Campaigns | Until you unsubscribe or delete the account. We then keep only your email address on a suppression list, so you are never emailed again by mistake |
| Leak Alarm findings and tripwire hits | Until you resolve them, then your plan’s retention window. Deleted with the account |
| Pages, repository content, and log lines scanned by Leak Alarm | Not stored. Discarded as soon as they are scanned |
| Fingerprints sent by the SDK | Until you remove the key, the SDK project, or the account |
| Verified domains and connected service credentials | Until you remove them or delete the account |
| Security research reports and correspondence | 24 months from the last message. A published Hall of Fame entry stays until you ask us to remove it. |
| Contact form enquiries held in Zoho CRM | 180 days from the last message in the thread, then deleted |
| Aggregate usage metrics with no payload content | Retained indefinitely in aggregate form |
Deletion means deletion from live systems on request, followed by expiry from backups on the schedule above. We do not keep a hidden archive of payloads past your retention window.
One thing survives deleting an account, and it is fairer to say so than to let you discover it. Request and access logs are kept for a year because Indian law requires it, and they record that a request reached a particular endpoint at a particular time. They hold no payload body and no message content. Section 8(7) of the Digital Personal Data Protection Act 2023 allows retention where another law compels it, and this is that case: we cannot delete these on request, and neither can anybody else operating a service in India.
We also keep a record that an account was deleted, being the date and a one way hash of the email address. It cannot be reversed into an email address, and it exists so we can show when a deletion happened without keeping the person’s details to prove it.
5. Who else processes it
We use a small number of subprocessors, each for one job. The current list, with purpose and data categories, is on the subprocessors page.
In summary: Amazon Web Services hosts the service in the United States, stores your events, runs Leak Alarm, and sends all our email through Amazon SES; WorkOS operates authentication; Zoho CRM holds enquiries sent through the contact form and your account record; Zoho Campaigns sends product update email to people who opted in, and Zoho Desk holds support tickets; Sentry receives error reports with payload content stripped; Dodo Payments processes payment as merchant of record. Each is bound by a written agreement with confidentiality and security obligations, and none is permitted to use your data for its own purposes.
We do not use advertising networks, session recording tools, or customer data platforms. Services you connect yourself, such as GitHub, Postman, or a log platform, are your own providers and their own policies apply.
6. International transfers
The service runs on Amazon Web Services infrastructure in the United States. Zoho CRM, Zoho Campaigns, and Zoho Desk run in Zoho’s India data centre. Our subprocessors may process data outside the country where you are based, including in the United States, India, and the European Economic Area. Where personal data leaves the EEA, the UK, or Switzerland, transfers rely on European Commission Standard Contractual Clauses, the UK International Data Transfer Addendum where applicable, and each provider’s own approved transfer mechanism. Copies of the relevant clauses are available at privacy@shellorbit.com.
7. Security
Measures in place include:
- TLS for every connection to ingest endpoints, the dashboard, and the API. Plain HTTP ingest is not offered.
- Encryption at rest for stored events, object storage, queues, and backups, using managed keys.
- Least privilege access to production data, with administrative access logged.
- Secrets and signing keys stored only in AWS Systems Manager Parameter Store, encrypted with a dedicated key, rather than in configuration, source control, or anything sent to a browser. Keys are masked before a log line or error report is written.
- Separation of the ingest path from the delivery path, so a slow destination cannot stop receipt.
- Automatic dependency and platform patching, with alerting on failed jobs and error rates.
You can reduce the amount of personal data we hold on your behalf by shortening what your provider sends, by using a transformation to strip fields before forwarding, and by deleting events you no longer need.
Report a suspected vulnerability to security@shellorbit.com.
8. Cookies and local storage
The marketing site sets no cookies. The dashboard sets a session cookie through WorkOS so you stay logged in, and stores interface preferences such as your last selected endpoint in the browser’s local storage. There are no advertising or cross site tracking cookies anywhere on shellorbit.com.
Dodo Payments sets cookies during checkout on its own domain, governed by Dodo Payments’ privacy notice.
9. Your rights
Depending on where you live, you may have the right to access your data, correct it, delete it, restrict or object to processing, receive it in a portable form, and withdraw consent where consent was the basis. In the European Economic Area, the United Kingdom, and Switzerland these come from the GDPR and equivalent law. In California, the CCPA as amended by the CPRA gives rights to know, delete, correct, and to opt out of sale or sharing. We do not sell personal information and do not share it for cross context behavioural advertising, so there is nothing to opt out of.
In India, the Digital Personal Data Protection Act 2023 gives you the right to information about the processing, to correction and erasure, to grievance redressal, and to nominate someone to exercise your rights. Where we rely on consent, such as for product update email, you can withdraw it as easily as you gave it, and withdrawing does not affect anything we did before.
Grievance Officer. In line with the Information Technology Act, 2000 and the Digital Personal Data Protection Act, 2023, our Grievance Officer is Manish Sharma, reachable at privacy@shellorbit.com. We acknowledge a grievance within 48 hours and resolve it within 30 days of receiving it.
To exercise a right, email privacy@shellorbit.com from the address on the account. We respond within 30 days, and within 45 days for California requests, and will tell you if we need longer. Account holders can export event data and configuration through the API at any time without asking.
If the data you want is event data belonging to a customer of one of our own customers, the customer is the controller. Send the request to them and we will assist them under the data processing addendum.
You can lodge a complaint with your supervisory authority. We would rather you told us first at privacy@shellorbit.com so we can fix the problem.
10. Automated decision making
There is no profiling and no automated decision making with legal or significant effects. Automated systems do enforce plan limits, rate limits, and abuse thresholds, and any such action is reversible and reviewable by a person on request.
11. Children
The service is for developers and is not directed at children. We do not knowingly collect data from anyone under 16 as an account holder. If a child’s data reaches us inside a payload or a tripwire hit, it is customer data under your control and the data processing addendum applies.
12. Changes to this policy
We publish the effective date at the top of this page. For a material change we give at least 30 days notice by email to account holders before it takes effect. Superseded versions are available on request.
13. Contact
- Privacy and data rights: privacy@shellorbit.com
- Security: security@shellorbit.com
- Legal notices: legal@shellorbit.com
Operator identity and registered contact details are available on request at legal@shellorbit.com.