Privacy Policy

1. Unclaimed launch previews — and how to erase one

Shipam sometimes builds a preview page for a company that has not asked for one, from that company's public launch and release data, and sends it to them once — with at most one follow-up, never a sequence. If you are reading this because you found such a page about your company: it is unofficial, nobody at your company approved it, and it deletes itself on its own. It is kept out of search engines and we publish no directory of these pages — but the URL is not a secret, and if we sent it to you in public (a reply to your launch announcement, say) then anyone who saw that post can open it too. The page states its own deletion date, in its header and again in its footer; that date is the commitment, and it is never more than two weeks out.

What we processed. Public information only: your public site, changelog, release notes, repository README, or launch listing; brand assets you publish on your own site, such as your logo, colours, and fonts; screenshots of public pages; and, where we emailed you, a work contact address obtained from public sources. Shipam does not use logins, private repositories, purchased personal data, or anything behind an account.

Why we are allowed to. We rely on legitimate interests for a single, relevant, business-to-business message about a company's own public launch, and on the corporate-subscriber position under UK PECR. There is no drip sequence, no profiling, and we never sell or share this data.

How to make it stop, three ways.

• Open the page from the personalized link in the email we sent you, and press “Delete this draft” in the claim section at the bottom. That link is what authorises the button, so it only appears when you arrive through it. Confirming deletes the page and everything captured to build it, with no account, no reply, and no decision from us needed.
• Reply to the email, or contact us through the channels listed on shipam.page, and ask for it to come down. We take it down the same hour we see the request, without asking why and without arguing the merits.
• Ask us to erase your contact details as well, and we will. Removal already deletes them from our own systems; this route also covers the one copy outside them — the original message in the sender’s own mailbox — which we delete and confirm on request.

What removal means. The page stops being served immediately, and what we captured to build it — the screenshots, the brand assets, the rendered content, the traffic records, and your contact details — is deleted from the systems that run the product.

What we keep, and why.Two things deliberately survive, because removal does not work without them. The first is a do-not-build entry: the public source address the page was built from — your changelog URL or repository path — with its hostname and the internal identifier of the page it came from. It is readable and it does identify your company; we are not going to claim otherwise. It is also what stops a future batch rebuilding the page. One limit worth knowing: it suppresses the exact address we built from, not your company in general — if we could reach you through a different public address (a second repository, another site), that one is not covered. Tell us and we will add it. The second is the page’s retired address: the slug it lived at, derived from your company name, stays on the tombstone that answers the old URL with 410 (gone), so the address is never re-issued and anyone following the link sees the page is down.

Where copies can outlive the removal.Deleting from the live product is not the same as deleting from everywhere, and we would rather name the gaps than imply there are none. Encrypted database backups taken before your removal still contain the page; we do not edit backups, so those copies age out on their own schedule (see section 7), and re-applying removals is a required step of any restore. The working file for the batch your page was built in sits on our own machine and is cleared by hand. Operational logs record that a removal happened, with the internal page identifier and no company name. The one email we sent you sits in the sender’s own mailbox, where no database command reaches. And if the page expired on its own rather than being removed, we keep one aggregate record for up to 45 days — the internal identifier and yes/no flags for whether it was viewed, engaged with, and claimed, no content and no contact details — so we can tell whether a batch worked at all.

If any of that matters to you, ask. We will tell you exactly what is left, delete what we can, and confirm when it is done — the email copy included.

If you would rather we did not keep the do-not-build entry either, ask and we will delete it — but say so explicitly, because without it nothing stops the page being generated again.

2. Data we collect

Shipam collects data needed to operate the product, including:

• account and contact details such as email address and basic profile information;
• changelog content and related assets you create, upload, publish, or send through the service;
• analytics events from hosted pages, such as page views, badge clicks, and performance telemetry when visitors consent to analytics cookies;
• subscriber and delivery data needed to send release emails and confirmation flows.
• integration metadata, access tokens, webhook configuration, and related identifiers for customer-enabled integrations;
• billing status, plan entitlement, support, security, and operational log data needed to run and protect the service.

3. How we use data

We use personal and product data to:

• authenticate users and secure accounts;
• host and render changelog sites, roadmap pages, and widgets;
• measure product usage and hosted-page performance;
• process billing and manage plan entitlements;
• send subscriber emails, login links, and service messages;
• import, transform, publish, and deliver updates through customer-enabled integrations;
• generate AI-assisted drafts only when an enabled AI feature is invoked.

4. Infrastructure and sub-processors

Shipam uses third-party infrastructure and service providers to operate the product. These providers process data on our behalf only to the extent needed for their role in delivering, securing, or supporting Shipam.

• Railway: application hosting and runtime services.
• Hetzner: hosting for self-managed database and shared data-plane services.
• Cloudflare: DNS, edge security, tunnels and access controls, object storage, and operational backups.
• Stripe: payments, billing, invoices, tax, and subscription management.
• Resend or Amazon SES: transactional email, subscriber email delivery, login links, and service messages, depending on the active production email configuration.
• Google: hosted-page font stylesheet delivery for selected non-system fonts, plus optional social sign-in and account profile authentication when Google sign-in is configured.
• Slack, GitHub, Linear, and Discord: optional customer-enabled integrations for importing release data, receiving events, and publishing or sending updates.
• OpenRouter and selected model providers: AI-assisted draft generation when customers use enabled AI features.
• Grafana Cloud, OpenTelemetry, and Sentry: observability, error reporting, logs, metrics, and traces when enabled for the relevant environment.

5. AI-assisted generation

Shipam uses OpenRouter for AI-assisted generation features. For AI-assisted changelog drafts, the current configured model chain uses Anthropic Claude Sonnet 4 via OpenRouter with Google Gemini 2.0 Flash as a fallback.

When an AI feature is enabled and invoked, Shipam may send the relevant prompt context to OpenRouter and the selected model provider. For changelog drafts, that context may include release-note text, GitHub release data, git ranges, git logs, commit messages, pull request titles, repository origin URLs, and related git context. For AI social-post generation, that context may include the entry title, entry markdown, tags, and the generated entry URL. Shipam does not use customer data to train Shipam-owned models.

Model providers process AI requests under their own service terms. Shipam does not claim fixed LLM regional residency, zero data retention, model-provider retention periods, or regulated compliance certifications unless those commitments are separately documented in a signed agreement.

6. Cookies and similar technologies

Shipam uses essential cookies for authenticated dashboard sessions. We also use hosted-page analytics cookies only after a visitor accepts the cookie banner shown on hosted changelog pages.

• Essential cookies keep authenticated dashboard sessions working.
• Analytics cookies support first-party hosted-page metrics collected through the site events pipeline and performance reporting.
• Visitors can reject analytics cookies and continue browsing hosted pages.

7. Data retention and control

We retain data for as long as needed to provide the service, comply with legal obligations, resolve disputes, and enforce our agreements. Customers control the content, assets, subscribers, and integrations they manage through Shipam and may update, delete, or disconnect them through the product where those controls are available.

Deletion requests can also be sent through Shipam's support channels. Deleted data may remain in backups, logs, billing records, security records, or other operational systems until those records age out under normal retention schedules or must be retained for legal, security, billing, or dispute-resolution reasons.

8. Contact

If you have privacy questions, sub-processor questions, or deletion requests about Shipam, use the primary contact channels listed on shipam.page.