What we hold, why we hold it, and how to get rid of it.

Echowide is operated by OPERATOR LEGAL NAME, REGISTERED ADDRESS. In this document “we” and “Echowide” mean that operator, and “you” means the person whose account it is.

The controller for the data described below is OPERATOR LEGAL NAME. Where a data-protection authority has jurisdiction, it is the one for JURISDICTION.

Five things, and nothing else.

• Your account. An email address and, if you give one, a display name. Authentication is handled by Better Auth; if you sign in with a third-party provider we receive the email address and name that provider releases, and nothing further.
• The platform accounts you connect. For each one: which platform it is, the handle, the platform’s own id for it, and a reference to the stored credential. Never the credential itself on that record — see below.
• The posts we ingest in order to republish them. When a flow is switched on, we read new posts from the origin account you chose: the text, any attached media, the platform’s id for the post, and a hash of the content so an edited post cannot be sent twice. We read your own posts on your own account. We do not read your followers, your direct messages, your contacts, or anyone else’s timeline.
• Delivery outcomes. For every attempt: which destination, when, whether it succeeded, the id of the resulting post, and — when it did not succeed — the reason the platform itself gave. This is the ledger, and it is the record you are shown.
• First-party analytics. On the public pages only: a page path, a referrer origin, a coarse country code, a browser and operating-system family, a device form factor and screen size, a language, any campaign tags in the link you followed, how long the page was open, where on the page you clicked and how far you scrolled, how quickly the page loaded, and a per-visit random session identifier. See the section below for what is deliberately not in that list.

We do not ask for a date of birth, a phone number, a postal address, or any special-category data, and there is nowhere to put one.

A credential that lets something post to your audience is the most dangerous thing we hold, so it is the thing this system is built around.

• Every credential — OAuth access and refresh tokens, a Bluesky app password, a Discord webhook URL, a Telegram bot token — is encrypted with AES-256-GCM under a key that exists only in the server’s environment file, and stored in a separate vault table.
• The row describing your connected account holds only an opaque reference to that vault entry. The reference is a random identifier; it encodes nothing about you, the platform, or the key.
• Credentials are decrypted at the moment of use and never written to a log, never included in an error message, and never passed as a command-line argument.
• For Bluesky we ask for an app password, never your account password, because an app password can be revoked on its own without touching anything else.
• For every OAuth platform we request the scopes that platform requires in order to read your own posts and publish on your behalf. The exact scopes are shown to you on the platform’s own consent screen before you approve anything.

We will not ask you for a session cookie. This is why Substack is not on our list: its only write path is a raw session cookie that grants full account access and cannot be scoped or revoked independently. A credential we cannot limit is a credential we will not hold, even at the cost of an integration.

Our own analytics are first-party: the events are recorded by this application, into our own database, on our own server.

• No raw IP address is stored. There is no column for one. A two-letter country code may arrive from the network edge; the address it came from is never written down.
• Do Not Track and Global Privacy Control are honoured. If your browser sends DNT: 1 or Sec-GPC: 1, the event is dropped at the door: nothing is written and no identifier is set.
• Paths only, never query strings. Query strings are where identifiers leak, so they are discarded before the event is stored.
• The session identifier is generated by your browser, rotates per visit, and is not an identity. It exists to join a first page view to the signup that ends it, and to nothing else. It expires after thirty minutes of inactivity and cannot be joined to an earlier visit, which is why a returning reader counts as a new one.
• The public pages only. The collector is mounted over the marketing, reference, legal and sign-in pages. It is not on the signed-in product and it is not in the operator panel, so nothing you do inside your own account is measured this way.
• The user-agent string is not stored. It is read once as the request arrives, reduced to a browser family, an operating-system family and a form factor, and then discarded. What is kept is the kind of thing that describes millions of people, not the string that describes one.
• Clicks are a position and a shape, never content. A click is recorded as a percentage across and down the page, plus a structural description of the element — its tag, its id, its class names. Attribute values are never read into it. No label is taken from a form field, a text area, a password box, an editable region, or anything near one. This is what makes a heatmap possible without a recording of you in it.
• There is no session replay, no camera and no gaze. “What was looked at” is inferred from where the page was scrolled to and for how long. Nothing observes you.
• Browser errors. When a script on the page fails, the message, the stack, the file and line, and the path it happened on are reported so it can be fixed. Errors are grouped by a hash of the message, so one broken component is one entry rather than one per person who met it.
• Nothing you typed, anywhere. Field values, text-area contents and anything inside a password field are refused by the browser code that collects and again by the server that receives, and there is no column in the database any of it could be written to.

Separately, an operator may enable third-party measurement tags on the public marketing pages. When any are enabled they sit behind a consent gate that is on by default: you are asked before a tag loads, and a Do Not Track or Global Privacy Control signal refuses them outright without asking. No third-party tag is ever loaded inside the signed-in product.

The destination platforms you choose, and nobody else. When a flow you switched on publishes a post, the content of that post and the media attached to it are sent to the 12 platforms you selected as destinations for that flow, using the credential you connected. That is the entire purpose of the service and it is the only routine disclosure we make.

• We do not sell personal data, and we do not share it for advertising.
• We do not share anything with data brokers.
• We use a small number of infrastructure suppliers — the hosting provider that runs the server, and the network in front of it — who process data only in order to run the service and on our instructions.
• We would disclose data if compelled by a valid legal order, and would tell you unless prohibited from doing so.

Where the UK GDPR or the EU GDPR applies, our lawful bases are: performance of the contract with you, for your account, your connected platform accounts, the posts we ingest and the deliveries we make — none of which the service can do without; and legitimate interests, for keeping the service secure and for first-party analytics that are limited as described above. Optional third-party tags rely on your consent, which you can withdraw at any time.

• Your account: for as long as the account exists.
• A connected platform account and its credential: until you disconnect it, or until the account is deleted.
• Ingested posts and delivery records: while they are useful to you as a ledger, and no longer than thirty days after an account is closed.
• Analytics events: swept on a retention cutoff, and detached from any user identity as soon as that user is deleted rather than deleted with them, so past totals stay correct without staying attributable.

Disconnecting one platform. On the Accounts screen, choose the connected account and disconnect it. The vaulted credential is deleted first and the account record only after that succeeds, so the failure case leaves you with no usable credential rather than a hidden one. Disconnecting stops every flow that used that account. Revoking Echowide’s access from the platform’s own settings has the same effect from the other side, and we recommend doing both.

Deleting the account entirely. Write to us at the address in the next section and say so. We delete the account, its connected platform records and their vaulted credentials, and the ingested posts and delivery records, within thirty days.

You can also ask for a copy of what we hold, ask us to correct it, ask us to restrict or object to a particular use, or complain to your data-protection authority. We do not charge for any of this and we will not ask you why.

The application and its database run on a server in SERVER LOCATION. Publishing a post necessarily sends it to the platform you chose, wherever that platform operates — which is the same journey the post already made when you posted it yourself.

Echowide is not intended for anyone under 16, and we do not knowingly hold data about anyone under that age. If you believe we do, tell us and we will delete it.

When this policy changes in substance we update the date at the top of the page and, for a change that affects what we collect or who we send it to, we tell account holders directly before it takes effect.

Privacy questions, access and deletion requests, and anything you think this page gets wrong: CONTACT EMAIL ADDRESS, or by post to REGISTERED ADDRESS. A person reads it, and we answer requests about your own data within thirty days.