1. Who is responsible for data
Xsender is the controller for account, authentication, billing, security, marketing, support, and abuse-prevention data.
Customers decide which lead lists, recipients, messages, targeting, schedules, and campaign purposes to use. For personal data processed only to carry out those instructions, the customer is the controller or business and Xsender is the processor or service provider.
2. Data we process
- Account data: email address, Google sign-in data, authentication provider, workspace identifiers, and preferences.
- Connected-account data: X handles, account identifiers, connection state, and assigned cloud workers.
- Campaign data: lead lists, recipient handles, message text, replies, campaign settings, schedules, variants, results, delivery states, and error codes.
- Inbox data (the Unibox): the X DM conversations of connected X accounts, including encrypted X Chat conversations once the user saves the X Chat passcode (when connecting the account or later in the inbox). This covers message text, reactions, files that are opened or sent from the inbox, the other person’s public X profile details, and the tags, notes, pipeline stages, saved replies, and follow-up GIFs and voice notes the customer adds.
- Customer-directed integration data: the API keys and AI app connections a customer creates, webhook destination configuration, signing and delivery metadata, and the campaign, contact, selected lead fields, conversation, and message data sent to an endpoint or app that the customer chooses.
- Device and security data: installation identifiers, scoped worker credentials, IP address, the country a connection comes from as reported by Cloudflare, user agent, timestamps, logs, cooldowns, task leases, and worker health.
- Sign-in protection data: a short-lived scrambled form of what was typed at X’s username step after X refuses a sign-in, per-address counts of refused and accepted sign-ins, and short-lived browser state from X’s sign-in pages, as section 3 explains.
- Sign-up progress and failed sign-ins: for each login, the guided-setup steps it reached, the errors it hit on the way (for example a refused card or X refusing a sign-in), and its failed sign-ins (for example a wrong password or an expired code). Each is kept as a step name and a short code, with the time. Xsender’s own servers record this whatever the analytics choice. When a sign-in fails, the email address typed is used only to find the matching login and is not stored.
- Billing data: subscription and trial status, how many free DMs a workspace has sent and when, invoices, payment evidence, tax information, and limited payment records supplied by Stripe. Xsender does not receive or store full card details.
- Trial-abuse marker: an irreversible keyed HMAC of the normalized verified login email, plus short-lived checkout reservation state. The raw email is not stored in this ledger.
- Free-DM marker: the same kind of irreversible keyed HMAC of the normalized verified login email, and the numeric X account ID of each X account that sent free DMs, each with the workspace that used it and when. The raw email is not stored in this ledger.
- Communications: support messages, legal requests, feedback, abuse reports, and related attachments.
- Telemetry from the retired Chrome extension, collected until it was retired: normalized event categories, status and timing buckets, coarse counters, extension version, browser family, and rotating pseudonymous identifiers.
- Anonymous visit counting: on public website pages, page visits, time on page, section and scroll reach, button and link clicks, page loading speed, referrer, approved campaign parameters, and device and browser type. In the guided setup after sign-up, the steps reached, buttons pressed, time on each step, and outcome codes. All without cookies or browser storage and without linking to a person or account.
- Optional website analytics: consented page visits, clicks, navigation, section and scroll reach, pricing choices, signup and checkout steps, heatmap coordinates, frontend errors, Core Web Vitals, device and browser characteristics, viewport, approved campaign parameters, landing referrer, and coarse location enrichment.
- Optional session recordings: masked visual snapshots and interactions on acquisition pages. Every input is masked; request and response headers and bodies, console logs, canvas content, passwords, authentication tokens, recovery and OAuth codes, Stripe session identifiers, payment details, and customer campaign content are excluded.
3. Cloud worker and X data
Each connected X account runs in a cloud worker: a browser session on Xsender’s cloud server, signed in to that X account. The user signs in on X’s own sign-in page, shown in a window inside Xsender. Login input, including passwords and verification codes, passes transiently through the cloud service and is not intentionally recorded or stored, apart from the short-lived scrambled record described below.
Each connected account reaches X through one internet address (IP address) that Xsender rents from its address provider, IPRoyal. Several accounts, including other customers’ accounts, can share one address. For a new connection, Xsender picks the address by the country the user is connecting from, as reported by Cloudflare when the sign-in window opens or when Xsender Connect hands over a session. If the country is unknown, the United States is used. Xsender uses an address in that country if one has room. If none has room, Xsender may buy one there from IPRoyal, also for users who have not started a trial or plan. Its orders to IPRoyal never name a customer. The user may wait up to five minutes while a new address gets ready. If Xsender does not buy one, or the new one is not ready by then, Xsender uses the closest address with room: the same continent, then the United States, then anywhere else. Xsender keeps each account on the same address while it stays connected, including when the user signs it in again. If that address stops working, Xsender moves the account to another address in the same country. If none there has room, Xsender asks the user to sign the account in again, and that sign-in gets the closest address with room, starting with that country. The country of the address is kept with the connection, and the country the user connected from may appear in service logs.
When X refuses a sign-in in that window (for example, “We’ve temporarily limited your login”), Xsender stops the same X account from being tried again too soon, because each quick retry makes X wait longer. While a sign-in window is open, the cloud server turns what is typed at X’s username step (a username, email address, or phone number) into a scrambled value: a salted hash, combined with the workspace. If X refuses the sign-in, that value is kept in the server’s memory, never on disk, and blocks the same identifier in that workspace for one hour. If it is typed again within that hour, the window stops before it reaches X and tells the user when to try again. This record never holds what was typed in readable form. The salt is replaced whenever the server restarts, and after that no kept value can be matched to anything.
Xsender also counts, for each of its internet addresses, how many sign-ins X refused and accepted there, and when it last refused one. These counts contain no personal content. When X refuses a user’s sign-in, the cloud server’s service log records the user’s Xsender user ID, which of Xsender’s addresses was used and its country, and how many sign-ins X had refused on Xsender’s cloud server that day, counting all users. If the founder has switched this on, a note with the user’s Xsender sign-in email, the country of the address used, and that same daily count is also sent to the founder by Telegram, at most once an hour per user. Neither the log nor the note includes what was typed into X.
So that a user who tries again looks to X like the same device coming back, Xsender may keep X’s own cookies and the browser storage of X’s pages from a sign-in window that closed without connecting an account. X’s sign-in cookies are never kept this way. This state is held in the server’s memory only, never on disk, and only for the same Xsender user on the same internet address. It is used only to open that user’s next sign-in window there within 24 hours, and is dropped when X refuses a sign-in, when an account connects, or when the server restarts.
Xsender Connect, where Xsender offers it, is an optional Chrome extension for connecting an X account the user is already signed in to in their own Chrome. Until the user starts a connection from Xsender, it only lets Xsender’s own pages see that it is installed. When a connection starts, it opens a consent screen and reads seven named x.com cookies in that Chrome, on the user’s own computer: the six listed below, and X’s list of the accounts signed in to that Chrome, which it uses only to count them. It sends nothing until the user clicks “Connect this account” on its consent screen. It then sends Xsender’s API only the six X cookies that keep that one account signed in and identify the browser (auth_token, ct0, twid, kdt, guest_id, and personalization_id), with the browser’s user agent and brand details. It never sends X’s list of signed-in accounts or any data of the other X accounts in that Chrome. Xsender then runs the account from its cloud server like any other connected account, on an address chosen as described above. Because Xsender uses the same X sign-in as that Chrome, signing out of that X account on x.com also signs Xsender out of it. Xsender Connect does not send messages, runs no background schedule (it keeps itself awake only while its one call to Xsender is under way), and has access only to x.com and to Xsender’s own website and API. While a connection request waits for the user’s answer, it holds the user’s Xsender sign-in token, and the Xsender workspace the request is for, in Chrome session storage. It deletes them when the connection finishes or is cancelled, or when the consent screen is closed, and Chrome deletes them when the browser closes. Removing a connected account from Accounts in Xsender deletes the session it handed over, in the same way as any other connection.
Xsender stores the signed-in X session encrypted on its cloud server. The worker uses the session to resolve the selected recipient, check DM availability, send the exact message of a campaign the customer confirmed, check the account’s own standing on X (such as a lock, or X’s public note that the account’s country may not be accurate), and, for the Unibox, read the account’s X DMs and send the replies written there and any follow-ups the workspace has switched on. When a cloud connection is removed or the Xsender account is deleted, the saved X session is deleted from the cloud server, usually within the hour, and from encrypted backups within 30 days.
An X account connected by a workspace that has not started a plan stays connected while it sends free DMs. Once it has sent no DM for about 7 days, including after its free DMs are used, Xsender disconnects it, deletes its saved X session from the cloud server, and frees its place on its internet address. The user can connect it again later. When a workspace that had a trial or plan no longer has an active one, Xsender does the same with its X accounts about 3 days later.
The X Chat passcode is optional: the user may enter it when connecting the account (or skip it) or later in the inbox. Xsender keeps it encrypted on its cloud server only after X accepts it, uses it only to unlock that account’s X Chat there, and deletes it when X rejects it, when the user removes it, or when the cloud connection is removed. The readable conversations go to the workspace inbox. When an account is first connected, up to 30 days of DM history is read back.
The worker keeps connection state, scoped platform tokens, device credentials, task lease state, execution receipts, cooldowns, retry data, and deduplication records on the cloud server to run approved work safely.
Xsender has retired its original Chrome extension, which ran this worker in the user’s own Chrome profile. Xsender Connect, described above, is a separate extension that only hands over a session. Xsender’s servers no longer give the original extension work or accept new connections from it, and Xsender can no longer read or use anything it stored. Data it kept in that Chrome profile, including any saved X Chat passcode, stays there until the user removes the extension from Chrome.
4. Where data comes from
Data comes from users and customers, connected cloud workers, the Xsender Connect extension when the user chooses to use it, X pages and campaign threads needed for approved tasks, authentication providers such as Google, Stripe, Cloudflare (the country a connection comes from), service providers, and security or support interactions.
5. Why we use data
- Provide accounts, connect workers, execute approved campaign tasks, synchronize campaign-thread replies, and show results.
- Choose the internet address each connected X account uses by the country the user connects from, buy an address in that country when none has room, and protect X accounts from repeated sign-in attempts after X refuses one.
- Authenticate users, maintain sessions, secure the service, prevent abuse, investigate failures, and enforce limits.
- Support customers, respond to rights requests, resolve disputes, and comply with law.
- Investigate support requests and reported or detected abuse and enforce the Acceptable Use Policy.
- Count public website visits and guided-setup steps anonymously, without cookies, to see which pages and sections help visitors and where they leave.
- See where each new login stops in the guided setup and which errors it hits, so we can help that person finish and fix what blocks people.
- See which of Xsender’s own marketing brought each new customer, for example by checking whether their email name or a connected X account matches someone Xsender’s own X outreach has messaged.
- Analyze reliability and improve Xsender using normalized telemetry and, only after optional consent, website analytics, heatmaps, errors, performance metrics, and masked acquisition-page session recordings.
- Administer free DMs, trials, subscriptions, payments, taxes, refunds, accounting, and abuse prevention (free DMs once per identity and per X account, one trial per identity).
- Send relevant B2B marketing until the recipient opts out, and send required service, billing, legal, or security messages.
Depending on the context, the legal basis may be contract, steps requested before a contract, legitimate interests, consent, or compliance with a legal obligation. Customers are responsible for selecting and documenting the lawful basis for their outreach and lead data.
6. Support, security, and enforcement access
Xsender does not routinely review or hold campaigns before sending. Authorized staff open a customer’s campaigns, lead lists, or inbox conversations only when needed for a support request, a reported or detected security, reliability, or abuse issue, a legal request, or enforcement. To run the service, the founder routinely sees account, billing, and sign-up progress records and the state of connected X accounts, as this policy describes. Access is limited to the people who need it and recorded where appropriate.
8. International transfers
Some providers may process data outside the European Economic Area. Where required, we use an adequacy decision, Standard Contractual Clauses, or another lawful transfer mechanism and assess supplementary safeguards.
Xsender’s cloud server is in Germany. Each connected X account’s traffic to X passes through an internet address chosen by the user’s country, which can be outside the European Economic Area. Telegram, Anthropic, Resend, and Calendly may process the data they receive outside the European Economic Area.
Normalized product telemetry is sent to Xsender’s PostHog EU Cloud project. Client IP data is discarded by the analytics project.
Consented browser website analytics and masked session recordings are processed in PostHog EU Cloud through Xsender’s first-party managed proxy. Canonical consent-gated checkout and subscription events may be sent directly by Xsender’s backend to PostHog EU ingestion. PostHog may enrich browser events with coarse geographic, browser, and device information; the project is configured to discard client IP data.
9. Retention
- Campaigns, lead lists, and their results: kept while the account exists. A campaign the customer deletes leaves the dashboard at once and stays in a restricted archive for up to two years, or until the account is deleted.
- Security logs: 30 days.
- Cloud server service logs (sign-in, connection, and sending events, which can name the Xsender user ID and the connected X account; never cookies, passwords, or what was typed into X): about 30 days, then deleted automatically.
- Scrambled identifiers after X refuses a sign-in: in server memory only, never on disk. They block that identifier for one hour and can no longer be matched to anything once the server restarts.
- Browser state kept from X’s sign-in pages: in server memory only, never on disk, used within 24 hours, and dropped sooner after a refusal, a successful connection, or a server restart.
- Per-address sign-in counts: kept with Xsender’s records of that internet address; they contain no personal content.
- X accounts of a workspace that has not started a plan: disconnected, with the saved X session deleted, after about 7 days without a DM. X accounts of a workspace whose trial or plan has ended: the same, about 3 days after it ended.
- Internal alerts to the founder on Telegram: kept in that chat until the founder deletes them.
- Support chats on Telegram: kept in Telegram until they are deleted there.
- Sign-up progress and failed sign-ins: kept with the login and deleted when the account is deleted.
- Customer audit records: 180 days.
- Webhook delivery metadata: retained with the customer account until the endpoint, source message, campaign, or account is deleted.
- Inbox conversations: kept in the workspace inbox, hosted on Cloudflare, while the workspace exists. Copies of files are removed 30 days after they were last opened; X keeps the originals. GIFs and voice notes saved for follow-ups stay until the customer replaces or removes them.
- Backups: up to 90 days.
- Normalized product telemetry from the retired extension: retained under the existing PostHog raw-event retention setting.
- Anonymous visit counts: retained under the existing PostHog raw-event retention setting; they are never linked to an account.
- Consented website analytics events may be linked to an account after sign-in and are retained under the existing PostHog raw-event retention setting.
- Consented acquisition-page session recordings: 30 days.
- Invoices, payment evidence, and accounting records: at least ten years where Lithuanian accounting law requires it.
The irreversible trial-abuse and free-DM markers are intentionally retained after account deletion, so deleting and recreating the same verified login identity, or connecting the same X account again, does not create another trial or give the free DMs again. The email markers cannot be used to recover the raw email without the separately protected server secret.
A valid erasure right overrides ordinary retention unless tax, fraud prevention, security, litigation, or another legal obligation requires continued storage. When data is no longer needed, it is deleted, anonymized, or isolated until deletion is possible.
Deleting a campaign removes it from the dashboard immediately and creates a restricted service-only archive. The archive is deleted automatically after two years. It is deleted sooner when the account is deleted, or when a verified erasure request applies and no law requires keeping it.
Account deletion is immediate and irreversible. It revokes sessions, removes the authentication user and cascading tenant data, and schedules retryable cleanup of non-cascading configuration tombstones. Saved cloud X sessions are deleted from the cloud server, usually within the hour, and from encrypted backups within 30 days. Legally required Stripe transaction and accounting evidence is not erased by deleting the Xsender account.
10. Your privacy rights
We offer GDPR-style rights globally: access, correction, deletion, portability, restriction, objection, and withdrawal of consent. These rights can be limited where law permits, including where identity cannot be verified or retention is legally required.
Anonymous visit counting does not use cookies or browser storage, is not linked to a person or account, and cannot be used to identify you. You may object to it by emailing us; blocking the analytics proxy in your browser also stops it.
Optional website analytics and session recording are off until a valid choice enables them. Use “Privacy choices” on the website to accept, reject, customize, or withdraw consent. Withdrawal stops future browser capture and recording, resets the analytics identity, clears PostHog persistence, and updates the server-side conversion preference for an authenticated account. You may also request deletion of identifiable analytics data by email.
A workspace owner can download a copy of the workspace’s data (settings, lead lists, campaigns, connected accounts, and inbox) from Account Profile while its free DMs, a trial, or a plan is active, and for 30 days after a trial or plan ends. Any user can delete their account there at any time.
For any other request, email [email protected], say which right you want to use, and include enough detail to find the data. If you have an Xsender account, send it from your account email. If you do not, for example because you received a message sent through Xsender, include your X handle. We may ask for information needed to verify identity and authority. We normally respond within one month, subject to lawful extensions. If Xsender processes data only for a customer, we may pass the request to that customer and help them answer it.
You may complain to the Lithuanian State Data Protection Inspectorate or another competent supervisory authority, including the authority in your country of residence where applicable.
11. Marketing and required messages
We may send relevant B2B marketing where permitted by law. Every marketing message should provide a practical way to opt out. Required service, billing, legal, and security messages are not marketing and may continue while an account or legal obligation remains.
Xsender also sends its own outreach messages on X, using its own product. A link in those messages can be made for one recipient. Xsender’s server counts each click on it without a cookie, so we can see that this recipient’s link was opened.
12. Sensitive data
Customers may process sensitive data only when they have a valid lawful basis and satisfy consent or notice requirements, minimization, security, and any required data-protection impact assessment. Xsender may reject or remove data it cannot safely or legally process. Xsender does not claim HIPAA or other regulated-data compliance.
13. Security
We use reasonable technical and organizational safeguards, including scoped worker credentials, HTTPS, access controls, payload minimization, signed customer webhooks, encrypted webhook secrets, pacing and duplicate-send controls, and revocation options. No system is perfectly secure, so we cannot promise absolute security.
14. Children
Xsender is for people aged 18 and over and is not directed to children. Contact us if you believe a child has provided personal data.
15. Changes to this policy
We may update this policy to reflect product, provider, or legal changes. Material changes will receive reasonable notice and a new effective date. English is the authoritative language.
Contact
Use the contact below for support, privacy requests, legal notices, intellectual-property complaints, and abuse reports.
XsenderNot VAT-registeredConstanza Hauser, 213 Curtis Dr, Pennsville, NJ 08070, United States[email protected]