Datenschutz

This policy explains what PushCaster collects when you use the Service, why we hold it, where it is processed and what you can ask us to do with it. It covers the marketing site, the dashboard and the API.

In it, “we” and “us” mean the operator of the Service. You can reach us at the address at the foot of this page for anything in this policy, including any request under section 10.

To give you an account and let you sign in to it, we hold:

• your email address, which is the account identifier and must be verified before you can create an application or receive credit;
• your name, if you choose to give one — it is optional and blank by default;
• a hash of your password. We do not store the password. It is hashed with Argon2, which is designed so that the stored value cannot be turned back into what you typed;
• your two-factor secret, if you enable it, encrypted at rest, along with your recovery codes;
• your preferences: interface language, display currency and time zone;
• the time and IP address of your last sign-in, a count of consecutive failed attempts, and a lock expiry if the account has been locked by that count.

If you use an organisation, we also hold its name, optionally its country, and the membership and role of each person in it. Invitations record the inviter, the invited address and an expiry.

If you contact support, we hold the ticket: its subject, the messages on it and any files you attach. Attachments are stored in our own database, not with a third party.

We do not retain the content of the events you publish. A message is accepted, routed to the subscribers of its channel and dropped. It is not written to a database, it is not archived and it cannot be replayed to you later.

This is a design property rather than a promise about our intentions: there is no store to read it out of. It is also the reason the terms say not to treat the Service as storage — if something must survive delivery, your application has to keep it.

We do not read message content in the ordinary course of operating the Service, and we do not use it to train models. We may inspect specific content where we reasonably need to in order to investigate a report of abuse, respond to a security incident, or comply with a legal obligation.

What we do keep is the count. Metering records how many messages passed and how long connections were held, because that is what you are charged for. Counts and durations are not content.

One consequence worth naming: where your events carry personal data about your own users, you are that data's controller and we act as your processor. Section 9 of the terms is the written agreement covering that, and it sets out what we undertake in the role.

We treat the confidentiality of your traffic as our responsibility rather than as a best effort. Your events are not intercepted, not inspected, not written to any log and not retained. Nobody here reads them in the course of running the Service, and there is no facility that would make doing so convenient: once a message has been delivered there is nothing left to read. Section 4 lists everything we do record, and none of it contains the content of a message.

Where that responsibility ends is with your own application, and it is worth being exact about it rather than leaving it to be discovered. The Service carries what you give it to the subscribers you tell it to reach. It cannot know that a channel you made public was meant to be private, that a payload you published contains something that should not have left your server, or that a subscription you authorised belongs to somebody who should not have been authorised.

So if your application secret is embedded in client-side code, if personal data is published to a channel anyone may subscribe to, if subscriptions are authorised without checking who is asking, or if a credential is shared with a third party, the resulting exposure follows from how the application was built and not from how the Service handles it. That is outside our control and outside our responsibility, and no amount of care on our side can compensate for it.

We would rather prevent this than disclaim it. If you are unsure whether a channel type or an authorisation flow is the right one for the data you are putting through it, ask us before you ship it — that is a question we would much rather answer early.

Running the Service produces records that are about you rather than from you:

• an audit log of actions taken on your account — who did what, to which object, when, from which IP address and with which browser user agent, together with the before and after state of the change;
• a record of each active session: when its refresh token was issued and last used, from which IP address and user agent, and when and why it was revoked;
• usage aggregates per application: messages, connection time, bytes and peak connections, rolled up by minute, hour and day;
• billing records: wallet transactions, ledger entries, payments, invoices and the rate applied to each charge;
• server logs and metrics, which are operational and are scanned to keep secrets out of them.

The audit log exists so that a disputed change has an answer, including a change made by us. That is why it is append-only and why it is not editable from the dashboard.

None of the records above contains the content of a message. They record actions taken on the account and volumes carried, which is a different thing from what was carried.

Each category above rests on one of three grounds:

• Performance of our contract with you — your account, your applications, delivering your events, metering them and charging for them. Without this data there is no service to provide.
• Our legitimate interests — keeping the Service secure and available, preventing fraud and abuse, and being able to answer a dispute. The sign-in IP address, the failed-attempt counter and the audit log sit here. We keep these narrow: they record actions, not behaviour, and we do not profile you.
• A legal obligation — financial records. Accounting law requires them to be kept for years after the transaction, which is why section 9 says they cannot be deleted on request.

We do not rely on consent for anything described here, because nothing here is optional to the Service. If we later do something that needs consent — analytics being the obvious candidate — we will ask for it first and this policy will say so before it starts, not after.

The control plane — the database holding everything in sections 2 and 4 — runs on a single server in the Netherlands.

Realtime traffic is served by two clusters: eu1 in Amsterdam, the Netherlands, and eu2 in Germany. These carry your events in flight. They hold no account data and no billing data.

Off-site backups are encrypted on our server before they are uploaded and are stored in the EU. The storage provider holds ciphertext and does not have the key.

So the Service itself — your account, your data and your traffic — operates within the EEA. Section 7 names the providers that sit outside that, and says what each one receives.

We use these third parties to process personal data:

• Resend — sends our transactional email: address verification, password resets, low-balance warnings and support notifications. It receives the recipient's address and the content of the message. Resend is based in the United States.
• Cryptomus — takes payments. We send it an amount, a currency, an internal reference and two callback URLs. We do not send it your name, your email address or your account identifier. When you complete a payment you are dealing with Cryptomus directly, and what it collects on its own page — including your wallet address and IP — is governed by its privacy policy, not by this one.
• Cloudflare — provides authoritative DNS for our domain and hosts our public status page. Traffic to the site, the dashboard and the API is not proxied through Cloudflare; it goes directly to our own servers, where our own software terminates TLS.

We do not sell personal data, we do not share it for advertising, and we do not use it to train models. There is no advertising network, data broker or analytics vendor in this list because there is none in the system.

If we add a sub-processor, this section changes before it starts processing, not after.

The marketing site sets no cookies at all. It loads no analytics, no tag manager and no third-party script. Nothing on it tracks you, and there is no consent banner because there is nothing to consent to.

The dashboard sets one cookie, named pc_refresh. It holds your session's refresh token, is marked HttpOnly and Secure so that page scripts cannot read it, is restricted to the single API path that renews a session, and is deleted when you sign out. It is strictly necessary to keep you signed in and is not used for any other purpose.

Your theme and language choices are stored in your browser's own local storage. They stay on your device; they are not sent to us and are not readable by anyone else.

The Service is capable of loading Google Analytics if an operator switches it on. It is switched off, and while it is off nothing is requested from Google and no identifier is set. Before it is ever switched on, this section will change and a consent mechanism will be in place first.

Retention is enforced by the system rather than left to judgement:

• Message content — not retained at all.
• Usage detail — per-minute figures for 7 days, hourly for 90 days, daily for 3 years. The dashboard will not offer a granularity beyond its window rather than quietly returning a sparse chart.
• Node health data — 7 days.
• Sessions — until the refresh token expires or is revoked; revoked rows are kept for a period so that a stolen-token reuse can still be detected.
• Account data — for as long as the account exists, and then as described in section 10.
• Financial and audit records — 7 years. Ledger entries, payments, invoices, promotional grants and audit logs are excluded by name from every retention job, and a test in the codebase fails the build if that list is widened.

The seven-year floor is a legal obligation, not a preference, and it is the reason erasure is partial rather than total. We would rather say that here than imply otherwise and explain it only when someone asks.

You have the right to ask us for a copy of the personal data we hold about you, to have it corrected, to have it erased, to restrict or object to how we use it, and to receive it in a portable form. You also have the right to complain to a data protection authority.

Some of this you can do yourself, immediately, in the dashboard: your name, email address, language, currency, time zone, two-factor settings, API tokens and application credentials are all editable there, and a change takes effect at once.

For anything else — a copy of your data, erasure, restriction or objection — write to the address at the foot of this page. These requests are handled by a person rather than by a button in the dashboard. We will acknowledge and respond within one month, which is the statutory period, and we will tell you if a request is one we cannot fully grant and why.

What erasure actually does, so that it is not a surprise: your applications stop serving and your credentials stop working; your profile, organisation details and support history are anonymised; and your financial and audit records are kept for the period in section 9 with your organisation's reference intact but your personal identifiers replaced by a tombstone. Your email address is not retained in those records — where a record needs to remain linkable, it holds an irreversible hash of the address rather than the address.

Anonymisation is not instant by design. There is a cooling-off period first, during which the request can be reversed, because an account deleted by mistake or by someone who should not have had access is not recoverable afterwards.

Passwords are hashed with Argon2. Two-factor secrets are encrypted at rest. Session tokens, API tokens and invitation tokens are stored only as hashes, so a copy of our database does not yield a working credential. Every comparison of a secret or a signature is constant-time, and that is enforced structurally: the build fails if a signature is compared with an ordinary equality check.

All traffic is TLS-only, with HSTS preloaded. Application secrets are held outside the codebase, and logs are scanned so that a secret cannot reach them by accident.

Access to production is limited to the people who operate the Service, and administrative actions are written to the audit log described in section 4 — including ours.

No system is beyond breach. If personal data is exposed in a way that is likely to result in a risk to you, we will notify the relevant supervisory authority within 72 hours of becoming aware of it where the law requires, and we will tell you directly, without undue delay, where the risk to you is high. We will describe what happened and what we know, rather than what is comfortable.

This policy carries a version, shown at the top of the page. When we change it we change that version.

Where a change reduces your protections or widens what we do with your data — a new sub-processor, a new purpose, a longer retention period — we will tell you by email to the address on your account before it takes effect, and give you at least 30 days' notice. Corrections and clarifications that do not change our handling take effect when published.

This policy forms part of the terms of service.