Privacy Policy

Effective 3 September 2026 Version 1.0 shellorbit.com and ShellOrbit

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. It explains what we hold and why in the same terms we would want to read.

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, and your support messages. For this data we are the controller.
  • Event data is what your providers send to your ingest endpoints: headers, query strings, and raw payload bodies, which may contain personal data about your own users. For this data you are the controller and we are the processor acting on your instructions. The data processing addendum governs it.

1. Account data we collect

Identity and authentication. Email address, display name, authentication 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.

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 Paddle as merchant of record. Paddle 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.

Support correspondence. Anything you send to a ShellOrbit address, with its attachments and metadata.

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.

2. Event 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.

3. Why we hold each category

PurposeData usedLegal basis under GDPR
Provide the service, receive and deliver eventsAccount data, event dataContract
Authenticate you and keep sessions secureIdentity, session, IP, user agentContract, legitimate interest in security
Bill you, including metered usageBilling data, event countsContract, legal obligation for tax records
Notify you of delivery failures and account stateEmail address, delivery outcomesContract
Keep the platform stable and abuse freeRequest logs, usage metricsLegitimate interest
Find and fix faults before they spreadDiagnostic data, error reportsLegitimate interest in a working service
Diagnose a fault you reportedEvent data for the endpoint concernedContract, your instruction
Answer an enquiry and keep the threadContact form fields, correspondenceLegitimate interest, steps before a contract at your request
Improve the service using aggregate metricsCounts, sizes, latencies, error classesLegitimate interest
Meet accounting, tax, and legal dutiesBilling records, correspondenceLegal obligation
Send occasional product email you can declineEmail addressLegitimate interest, consent where required

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

DataRetention
Event payloads, headers, and delivery attemptsYour plan’s retention window: 3 days on Hobby, 14 on Starter, 30 on Pro, 90 on Business. Deleted automatically after that.
Events you delete manuallyRemoved from live systems immediately, purged from backups within 35 days
Endpoint configurationLife of the account, then 30 days
Account and identity recordsLife of the account, then 30 days, after which they are deleted from live systems
Backups containing any of the aboveRolling window, expiring within 35 days
Request and access logs365 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 Sentry90 days, then deleted on Sentry’s schedule
Billing and tax recordsAs long as tax law requires, typically 7 years, then deleted
Support correspondence24 months from last message
Contact form enquiries held in Zoho CRM24 months from the last message in the thread, then deleted
Aggregate usage metrics with no payload contentRetained 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 and stores your events; WorkOS operates authentication; Zoho Corporation’s ZeptoMail sends transactional email; Zoho CRM holds enquiries sent through the contact form; Sentry receives error reports with payload content stripped; Paddle 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.

6. International transfers

The service runs on Amazon Web Services infrastructure. Our subprocessors may process data outside the country where you are based, including in the United States 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 in a managed secret store rather than in configuration or source control.
  • 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.

Paddle sets cookies during checkout on its own domain, governed by Paddle’s 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.

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, it is event 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

Operator identity and registered contact details are available on request at legal@shellorbit.com.