Privacy notice

Who controls what

There are two different relationships here, and they carry different obligations. Keeping them apart is the point of this section.

• Your account data — we are the controller. When you sign up, we decide what to collect and why: an email address, a name, a password hash, and what you told us you were routing. This notice governs that.
• The data you route — we are a processor. Tasks, workers, tags, task content and decision traces belong to you. We process them on your instructions, to run the routing you asked for, and for nothing else. We do not mine them, sell them, or use them to train models.

If the data you route includes personal data about your own staff or customers, you are the controller for it and we act under your instructions. Our standard data processing agreement covers that relationship and is already in force — nothing to request, though we will countersign a copy if your process needs one.

What we collect

Because you gave it to us: your name and email address, your password (stored only as a scrypt hash), your answer to the one signup question about what you are routing, and your workspace configuration.

Because the service runs: session records tied to your login, API-key hashes, usage counters for the assignments your workspace matched, and server logs containing IP addresses and request metadata for security and debugging.

Because of how you reached the sign-up page: the page of this site you pressed sign up on and, only if the link that brought you to the site carried them, the ad click id from a Google or Meta ad and the campaign tags in that link. They travel in the sign-up link itself, so nothing is stored on your device, and are kept with your workspace so we can tell which pages and campaigns bring people the product is useful to. They are not sent to Google or Meta; like any page address on the public site, the sign-up page's address that carries them is seen by our analytics processor, PostHog.

Because you sent it through the API: whatever you put in tasks, workers, comments and attachments. Routing needs only tags and identifiers — anything richer is your choice, and if it contains personal data, that is a choice you make as controller.

Because you visited a marketing page: a pageview or click event, with your IP address and user agent, recorded by PostHog on EU infrastructure in cookieless mode. This covers the public pages only — the console, /login and /app are excluded, so nothing about how you use the product is measured. There is no session recorder, and no advertising pixel or cookie on this site.

If you write to us from /support or /contact: your email address, the name if you give one, what you typed, and the page you sent it from. It is delivered to our support mailbox through SendGrid and kept there as correspondence so we can answer you. Nothing from these forms is stored on the website, and sending one does not add you to any mailing list.

If you press play on a video: our tour is hosted on YouTube. Nothing is loaded from YouTube until you press play, and then it plays in YouTube's privacy-enhanced mode, so Google receives your IP address and user agent at that moment and not before.

If you arrive from one of our Facebook or Instagram ads: the lead form shows an unticked box offering to let Meta know the ad worked. Only if you tick it, our server sends Meta a scrambled (SHA-256) copy of your email address, the ad click id from your link, your IP address and browser user agent, once. Nothing is stored on your device, and nothing is sent if you leave it unticked or arrive any other way.

If you arrive from one of our Google ads: the same, for Google. The lead form shows an unticked box offering to let Google know the ad worked. Only if you tick it, our server sends Google a scrambled (SHA-256) copy of your email address, the ad click id from your link and a reference number for your request, once, marked as consent to measure the ad and not to personalise ads. The Google tag is not installed on this site, so nothing is stored on your device, and nothing is sent if you leave the box unticked. The ad click id itself is kept with your request in our own records, whichever ad brought you, so we can tell which campaigns are worth running.

5xer Worker Portal browser extension

The 5xer Worker Portal browser extension has one purpose: to keep a worker's portal available in the browser side panel and notify that worker when new work is assigned. It does not inspect the pages a worker visits, read unrelated website content, record browsing history, or monitor clicks, keystrokes or other browsing activity.

Information the extension handles: the worker-portal URL supplied by the worker, the worker's account identifier, a worker-scoped authentication token created after the worker signs in, assigned task identifiers used to detect new work and prevent duplicate notifications, and the task selected when a notification is opened. The portal may also handle task comments and, where an employer has enabled a location-dependent feature and the worker grants permission, location information.

Workers continue to authenticate inside their employer's portal with their worker ID and PIN. The PIN is sent directly to that configured portal over HTTPS and is not stored by the extension. The resulting worker-scoped session is stored in the worker's Chrome profile and sent only to the configured 5xer API over HTTPS so the extension can check that worker's own queue and deliver notifications. It is never a workspace API key and cannot administer the workspace.

The extension does not sell this information, use it for advertising, use it to determine creditworthiness or lending eligibility, or transfer it for an unrelated purpose. Information is used only to provide the worker portal and assignment-notification functionality described above. Removing the extension removes its locally stored information; signing out or revoking the worker's device invalidates the corresponding server session.

The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements.

Why, and on what basis

• To provide the service — creating your account, authenticating you, running the routing engine, sending transactional email such as verification and worker invitations. Basis: performance of a contract.
• To keep it secure and working — logging, rate limiting, abuse prevention, incident investigation. Basis: our legitimate interest in operating a safe service.
• To bill and account — usage metering, and financial records once paid plans exist. Basis: contract and legal obligation.
• To reply when you contact us. Basis: legitimate interest.

We do not run marketing profiling and we do not send marketing email to addresses collected at signup unless you asked us to.

Who else sees it

Only the subprocessors listed below, each for one job. We do not sell personal data and we do not share it with data brokers. PostHog is an analytics vendor: it sees pageviews on the public marketing pages and nothing else — no account data, no task data, nothing from the console. Meta and Google receive ad-measurement data only from visitors who opt in on an ad lead form, and Google also passes us what a visitor types into its own lead form on one of our ads, as described above.

We may also disclose data where the law requires it. If we receive such a request and are legally permitted to tell you, we will.

International transfers

The platform runs in Frankfurt, Germany, inside the European Union. Your routing data stays there.

Two flows reach the United States: transactional email through SendGrid, and — only if your workspace uses the Worker-Portal Studio — the AI portal builder, which runs on DigitalOcean's own inference platform. That is the same company that hosts the rest of the service, but its inference endpoint has no EU region, so we treat it as leaving the EEA. A third flow touches only website visitors: the opt-in ad-measurement calls to Meta and Google described above, both of which may transfer onward to the United States. Where personal data is part of those flows, it is transferred under the safeguards required by GDPR Chapter V.

The safeguard in each case is the European Commission's Standard Contractual Clauses, incorporated in each provider's own data processing addendum, which we have accepted. The per-subprocessor detail is in Annex III of our DPA.

Both are avoidable if you need zero non-EEA processing: the Studio is opt-in, and worker invitations can be issued as links you deliver yourself rather than by email.

How long we keep it

• Account data — while your account exists, and up to 30 days after a deletion request while we complete it.
• Routing data — until you delete it or delete the workspace. Deleting a workspace removes its tasks, archives, comments, attachment records and live routing state, and queues the attachment bytes in object storage for deletion.
• Server logs — kept only as long as they are useful for security and debugging.
• Financial records — retained for the period tax law requires, once paid plans exist.

No automatic expiry. We do not currently age routing data out on a schedule. If your retention policy needs that, it is a manual deletion on your side today.

Your rights

If you are in the EU or UK you have the right to access your personal data, correct it, delete it, restrict or object to processing, and receive it in a portable form. You can also complain to your national data protection authority.

Much of this is self-serve: your account details are editable in the console, workspace data is exportable through the API at any time, and deleting a workspace deletes its contents. For anything else, email support@fivexer.com — we respond within one month, as GDPR requires.

If you are an end user whose data was routed through Fivexer by a customer of ours, that customer is the controller. Send your request to them; if you reach us instead, we will forward it.

Cookies & tracking

We set one kind of cookie: the session cookie that keeps you logged in. It is strictly necessary for the console to work, which is why there is no cookie banner asking for consent we do not need.

Local storage is used for interface preferences — your theme choice, the workspace you last had open, whether a panel was collapsed. That data stays in your browser.

The marketing-page analytics described above runs cookieless: it sets no cookie and writes nothing to local storage, which is the reason this site can ask you for nothing on arrival. The cost of that choice is ours to carry — we cannot recognise a returning visitor, and we would rather lose the number than open with a consent dialog.

Contact