Privacy policy — unyx softphone

The German version (Datenschutzerklärung — unyx softphone) is the authoritative text. This English text is a translation for convenience; in case of conflict the German version governs.

This policy covers the app and its services. Visits to this website are covered by the general privacy policy (German).

1. Controller

UNYX GmbH
Augasse 25c, 6300 Wörgl, Austria
Company register number FN 675769d, Regional Court (Landesgericht) Innsbruck
VAT ID ATU83215101
Telephone: +43 5332 22808
E-mail: kontakt@unyx.at
Imprint: https://unyx.at/impressum

For data-protection questions and to exercise your rights, contact us at kontakt@unyx.at. No data protection officer is appointed.

2. What this policy covers

This policy covers the unyx softphone application (Android, iOS, Windows, macOS, Linux) and the UNYX-operated services it uses:

• the licence server license.unyx.at,
• the push gateway push.unyx.network,
• the SIP push proxy, where your organisation deploys it.

It does not cover the phone system or SIP provider you call through, nor their directory and presence services (Section 5.7). Who operates those is decided by your organisation or your provider, and their privacy terms apply there.

2.1 If you use the app through your employer

In most cases a company buys the licences and issues the app to its staff. In that case your company is normally the controller for your telephony data and UNYX acts as a processor under Art. 28 GDPR. For licence management itself (Section 5.1) UNYX is the controller.

3. The principle: what never leaves your device

Before the individual processing activities, the important part:

• Your address book does not leave your device. Device-contacts access is off by default; it has to be switched on in the app's settings and granted by the operating system. After that the app reads your contacts locally only — to browse the contact list and to show a name on an incoming call. The app contains no path that transmits contacts to UNYX or to any third party — no sync, no upload, no backup.
• A company directory, by contrast, is fetched. Where one is configured, the app downloads the contact list from the host your organisation or your provider names for it. That is a data flow to that provider, not to UNYX; Section 5.7 describes it.
• Your call history stays on the device. It is held in encrypted device storage, and the app does not transmit it. The UNYX push gateway deliberately stores no call metadata (one narrowly bounded exception for undelivered wake-ups is described in Section 5.6). One exception you switch on yourself: with the Android setting for the system call log (off by default) the app additionally writes your SIP calls into the operating system's call log — there, other apps with call-log access can read them, and the operating system's backup or sync may include them (Section 5.9).
• Call recordings stay on the device — unless you share them. A recording exists only if you press Record during a call. The app never transmits recordings; they leave the device only through the Share function. Whether operating-system backups include them depends on the platform (Section 5.13).
• Call content does not travel through UNYX. Audio flows directly between your device and the phone system or SIP provider you or your organisation configured — and only there. UNYX does not require call media to be routed through its own systems, and there is no media relay (TURN) any more: the function was removed completely on 2026-09-28.
• The app contains no third-party analytics, tracking or crash-reporting SDKs. No advertising identifiers are read, no profiles are built, and no usage data goes to Google, Apple or any other third party.
• There is one first-party, optional health report — and it is off by default. Only if you switch on "Share diagnostics" does the app send, once a day, a small report made of counters and bands (for example: how many calls failed and why, whether wake-ups arrived, whether the app crashed) to UNYX's own server. It contains no device ID, no phone numbers, no SIP addresses and no error-message text, and it is added into totals on arrival instead of being stored per device. Section 5.12 describes it in full.

4. Categories of personal data

5. The individual processing activities

5.1 Licence verification and device identity (license.unyx.at)

What is transmitted. On activation and periodically thereafter the app sends to the licence server: the licence key, a product identifier, the installation fingerprint, the app version, a nonce, the public half of the device key together with whether it lives in secure hardware, and — once, when a new key is first enrolled on Android — the operating system's keystore attestation chain. When a push-proxy certificate is requested, a certificate signing request (CSR) and, where set, your SIP domain are added. As with any internet service, the server processes your IP address.

What the installation fingerprint is. It is not a name and not a device serial that third parties could read. The app takes a stable operating-system device identifier — Settings.Secure.ANDROID_ID on Android, identifierForVendor on iOS, the system GUID on macOS, the device ID on Windows, the machine ID on Linux — combines it with a fixed, product-specific salt and hashes the result with SHA-256. Only that hash is transmitted, in the form sha256:…. This means the value cannot readily be correlated with the original device identifier or with other apps on the same device. Where the operating system offers no stable identifier, the app generates a random value in the form uuid:… instead. Both values are personal data, because they make a particular device — and therefore indirectly a person — recognisable.

Purpose. Verifying that a valid licence exists; allocating exactly one device seat per device; issuing the short-lived credentials the app needs for the push gateway and push proxy; detecting abusive multiple use of one key.

Lawful basis. Art. 6(1)(b) GDPR (performance of the licence contract). Where device identity additionally serves to detect a licence key being passed to unauthorised devices, UNYX relies on Art. 6(1)(f) GDPR; the legitimate interest is protecting the licence model against unpaid use.

Recipients. UNYX GmbH; for operating the licence server and its encrypted backups, hosting providers in Austria (Section 6).

Retention. Licence, device-seat and certificate data are kept for 7 years after the licence ends and then deleted.

5.2 Registration for incoming calls (push.unyx.network)

What is transmitted. So that a call can reach your device while the app is in the background or closed, the app registers with the push gateway: the device's push token, your SIP address (AOR), the push provider (fcm or apns), a short-lived push credential issued by UNYX — and, only where that credential is missing, the licence key itself — and the installation fingerprint. On iOS a second Apple token for silent background notifications is added. The server processes your IP address.

What of that is stored. The registration table holds the push token, your SIP address, the push provider, the licence identifier, your device key's thumbprint, a random registration handle and the credential's expiry. The installation fingerprint is not stored: the credential already carries its hash, and the value you send is only checked against it.

Purpose. Delivering incoming calls; refreshing expiring credentials; blocking revoked licences.

Lawful basis. Art. 6(1)(b) GDPR.

Retention. A registration that is not renewed for 30 days is deleted automatically; the sweep runs hourly. Registrations whose credential expired more than 24 hours ago are deleted as well. If you remove an account or switch push off, the app deletes the registration immediately.

5.3 Delivery on Android — Google Firebase Cloud Messaging

On Android the wake-up is delivered through Google's Firebase Cloud Messaging (FCM). Google necessarily receives your device's push token and the contents of the message.

The message deliberately contains nothing about the calling party. It carries only: the event type (type), the call's Call-ID, a delivery attempt counter (attempt), your own SIP address (aor) and a timestamp. The caller's number and display name are explicitly stripped on this channel and do not reach Google — not even when a caller tried to include them. Your device learns the number afterwards, from the SIP call itself.

Note that your own SIP address is transmitted, and it typically contains your extension and your organisation's domain.

Operating FCM also requires the Firebase library on your device to obtain a push token from Google; in doing so it transmits device and installation data to Google, per Google's own documentation. UNYX has no influence over that step.

Lawful basis. Art. 6(1)(b) GDPR — without push, incoming calls do not reach you in the background.

Recipient. Google (Firebase Cloud Messaging) as processor under the Firebase Data Processing and Security Terms (version of 2024-08-21); under those terms the contracting party is Google LLC, Google Ireland Limited or an affiliate, as applicable.

5.4 Delivery on iOS — Apple Push Notification service

Implementation status: no build of the native telephony library exists for iOS; at most, accounts using WebSocket (wss://) could register there. The processing below is therefore fully present on the server side and prepared in the app, but does not yet take place. It is described here because it takes effect with the first shippable iOS release — and because the difference from Android is material.

On iOS the wake-up is delivered through the Apple Push Notification service (APNs). There the message contains everything listed in Section 5.3 plus the calling party's number or SIP address (from_uri) and their display name (from_name).

In plain terms: on every incoming call to an iPhone, Apple learns who is calling you.

This is technically unavoidable. iOS requires an app to report the call to the system call register (CallKit) immediately on receiving the notification, and to report the handle with it — before any SIP connection exists. A notification without a number would ring as "Unknown" and call-blocking lists would stop working. Android has no such requirement, which is why the number is not transmitted there.

Lawful basis. Art. 6(1)(b) GDPR.

Recipient. Apple Distribution International Ltd. / Apple Inc.

5.5 SIP signalling, call setup and audio

The app establishes the SIP connection to the phone system or SIP provider you or your organisation configured. This transmits the SIP username and password, your SIP address, the numbers of both parties, the Call-ID, and your device's IP address and port. Audio flows directly between the endpoints or through your provider's systems. UNYX does not route call media through its own systems — clause 7 of the in-app end-user licence agreement states this as well (revision 2026-09-28.2). There is no media relay (TURN) any more: UNYX removed the function completely on 2026-09-28 — from the app, from the licence server, which no longer issues TURN credentials, and from the servers. Call media therefore flows only between your device and your SIP provider or phone system. Where an account carries a STUN server, it comes from your organisation's or your provider's configuration; a STUN server learns your device's public IP address and port but relays no call media. A TURN entry configured by the organisation is not used either: the account form refuses turn:/turns:, a stored entry is dropped on load, and the engine never receives one.

One exception you should know about: where an account registers over the WebSocket transport (wss://) and no STUN server is configured for it, the underlying WebRTC library falls back to a public Google STUN server (stun:stun.l.google.com:19302), which then sees your device's IP address. The app writes a warning into the diagnostic log when that happens. Accounts over UDP, TCP or TLS are not affected.

Where your organisation deploys the UNYX push proxy, SIP signalling passes through that proxy. It persists the registration table — your SIP address, your device's contact address including IP address and port, and the expiry — and keeps operational logs in which the Call-ID and the SIP headers of the transaction appear. Call detail recording (CDR/accounting) is not enabled in the proxy; the relevant module is not loaded.

Lawful basis. Art. 6(1)(b) GDPR. For processing in the proxy your organisation is normally the controller and UNYX the processor (Section 2.1).

Retention. A registration-table entry expires with the registration it stands for. The additional mapping tables — which registration belongs to which device, the refresh state, the busy-lamp subscriptions — expire two hours, respectively a little over one hour, after they were last refreshed. The proxy's operational logs are deleted on the server after 30 days; a copy in UNYX's central logging system is kept for at most 60 days (set in the operations configuration).

5.6 Buffer for undelivered wake-ups

If a wake-up does not reach the device, the push gateway can briefly hold the missed call so the device can collect it on its next contact. What is stored is the Call-ID, the calling party's number and display name, the failure reason and timestamps.

This feature is off by default and is enabled per customer. With it off, nothing is stored. With it on, a hard ceiling of 24 hours applies; entries are deleted automatically after that, as soon as the device has collected them, or when the associated registration ends.

Lawful basis. Art. 6(1)(b) GDPR, together with your organisation's decision to enable the feature.

5.7 Company directory and provider queries

The phonebook. Where a directory is configured, the app downloads a contact list from it over HTTPS — nothing is uploaded. The fetch is not only on demand: the app also retrieves the directory when it needs a name for a number, or when you open the contact list. The downloaded entries are held in memory only and are not stored on the device.

It is set up one of two ways, and that decides which secret travels:

• Through your provider. For supported providers your SIP account carries a phonebook key; the app inserts it into the address the provider prescribes and fetches that (with Innosoft/Innofon, for example, https://api.innosoft.at/phone-book/export/cti-client/<key>/…). The key travels in the address and is the only secret transmitted — the SIP username and password are not sent on this path. The whole directory of that account is downloaded, not just the entry you looked for.
• Through a directory address you entered. Where the directory requires authentication, the app sends the SIP username and password as HTTP Basic authentication — but only to the one host bound to that account, and to no other; redirects to other hosts are aborted, and any other directory is fetched without credentials.

On Android and iOS this fetch is HTTPS only. On the desktop builds (Windows, macOS, Linux) the app additionally allows an unencrypted http:// address when it points at a host on a private network — the ordinary case of an on-premise phone system. In that configuration the credentials above also travel unencrypted across your local network.

Presence query. Settings carry a button that checks whether your provider publishes the presence state of the extensions. It sends the same phonebook key and your phone system's main number over HTTPS to the provider's host, and writes the answer into the diagnostic log (the key itself is redacted there). It runs only when you trigger it.

Setting your own presence status, by contrast, is not an internet query: the app dials a feature code on your phone system, which is an ordinary call in the sense of Section 5.5.

Recipient. The directory's operator, respectively your phone system — normally your organisation or your provider, not UNYX. These fetches do not pass through any UNYX system.

5.8 The device address book and your own contacts

Using the device's contacts is off by default. You switch it on in the app's settings; only then does the app ask the operating system for the permission. What is read is a contact's name, numbers, e-mail addresses, company, address and note — and a contact's photo only when you open its detail view. All of it stays on the device (see Section 3). You can withdraw the permission at any time in the system settings, or switch the setting back off; the app then continues to work without address-book name display.

Contacts you create in the app itself, and your favourites, are held in the device's encrypted storage and are not transmitted.

5.9 Call history

The call history — number, name, direction, time, duration — is stored in your device's encrypted storage, capped at a fixed number of entries (currently 200), and the app does not transmit it. You can clear it in the app; uninstalling removes it entirely.

System call log (Android only, off by default). If you switch on the setting that makes calls appear in the system call log, the app reports each call there through Android's telephony interface. Those entries then live outside the app: any other app with permission to read the call log can see them, and backup or sync functions of the operating system or the device maker may include them. Clearing the history in the app does not remove them there; only the system call log can. The setting is off by default because a business line usually does not belong there.

5.10 Diagnostic log and support requests

The app keeps a troubleshooting log. It stays on the device and is transmitted only when you explicitly send it yourself — via the share sheet or a prepared e-mail to app@unyx.at. So that a log survives a crash, it is also held as a file in the app's private storage area (one live file of about a megabyte plus one predecessor; the older one is overwritten).

Redaction happens as the log is written, not only on export — so the file on the device carries no secrets either. Redacted are: passwords, tokens, certificates and keys, licence keys, signatures, the provider's phonebook key and long secret segments inside addresses, e-mail addresses (the domain part stays readable), alphabetic SIP usernames, the installation fingerprint, and phone numbers (at most the first five and last two digits of a number survive).

The log is not fully anonymous. For operational reasons the following stay readable, among others: numeric extensions of up to four digits, hostnames and domains, IP addresses and ports, Call-IDs and timestamps, plus device model, OS version and app version. Please send a log only if you are comfortable with that.

Lawful basis. Art. 6(1)(b) GDPR (providing support) or, where no support contract exists, Art. 6(1)(f) GDPR; the legitimate interest is resolving the fault you reported.

Retention. Submitted support logs are kept for 90 days and then deleted.

5.11 Application updates

At start-up and on request the app checks whether a newer version exists and, if so, downloads it from the licence server. This transmits the licence key, installation fingerprint and app version (as in Section 5.1) and processes your IP address server-side. The downloaded file is verified cryptographically before installation.

5.12 Optional health report ("Share diagnostics")

Availability: included from app version 1.8.59 (released 2026-09-28); the counts of failed calls and of the app being frozen are added with 1.8.60.

Voluntary and off by default. The app sends this report only if you switch on "Share diagnostics" in the settings. Without that consent nothing is collected or sent, and the app works exactly the same. The app records on your device when you consented and to which version of this policy (2026-09-28).

What is sent — in full. The report consists only of fixed choice values and counters; there is no free-text field, and the server rejects any report carrying an extra field:

• platform, OS major version, app version, device class (phone, tablet, desktop) and the period covered, in hours;
• the number of answered and outgoing calls; failed calls by cause (busy, declined, not found, timeout, network, authentication, media, other); call setup time in four bands; voice quality in three bands; calls in which no audio arrived at all; how often the operating system silenced the microphone;
• wake-ups by outcome (rang, registered, timeout, failed) and their duration in bands;
• registration failures by reason;
• how often and how long the system froze the app, gaps in reachability, background services that were stopped, and which settings from a fixed list are currently missing (for example microphone, notifications, battery optimisation);
• at most five crashes: the kind of error (the name of the error class), a fingerprint value, and the places in the program code where it occurred. The error message itself is never sent, because it could contain phone numbers or addresses; code locations that nevertheless contain a phone number, a SIP or an IP address are rejected by the server.

What is not sent. No device ID or other identifier of the device, no phone numbers, no SIP addresses, no names, no call history, no call content, no location data.

How often. At most once a day, at a randomly shifted time. The server accepts at most two reports per device per day.

Where it goes and what happens there. The report is sent encrypted to push.unyx.network, UNYX's own server in Austria. So that only genuine devices can report, the app authenticates exactly as it does for push registration (Section 5.2): with its credential bound to the device key and a signature by that key. The report is therefore pseudonymous in transit — linkable to a licence seat — and aggregated on arrival; the server processes your IP address as with any connection. The server checks the report, adds its values into totals and then discards it: it creates no record per device and writes neither the report nor your IP address to a log. For the daily limit and the five-device rule it holds the device key only as a keyed daily value in memory, under a key drawn fresh each day and never stored. The totals are broken down by app version, platform and customer — by customer only if at least five devices of that customer reported that day; otherwise they go into one shared catch-all group. Each crash is kept as a line of its own (kind, error class, fingerprint, code locations, app version, platform — no customer, no error message) in the operational log. The server also accepts reports only for customers who have switched the feature on for their installation (default: off). UNYX uses no service provider for this; the analysis runs on UNYX's own systems.

Purpose. Detecting and fixing faults across the fleet before anyone has to report them — such as wake-ups that do not ring, or a microphone the system silences.

Lawful basis. Your consent, Art. 6(1)(a) GDPR, and, for reading the values on your device, § 165(3) of the Austrian Telecommunications Act 2021 (TKG 2021).

Retention. The totals are deleted after 60 days, the crash lines in the central log likewise after 60 days, and in the server's own log after 30 days. On your device the counters are reset after every send.

Withdrawal. You can withdraw consent at any time with the same switch. Withdrawal takes effect immediately: the app stops sending and deletes the not-yet-sent report on the device. Values already sent exist only as totals that can no longer be attributed to any device; they therefore cannot be deleted individually and expire with the period above. The lawfulness of processing before the withdrawal is not affected (Art. 7(3) GDPR).

5.13 Call recordings

Only on your button press. The app records a call only if you press Record during it; there is no automatic or preset recording. Before the first recording of each app session, a dialog points out your duties towards the other party.

What is created. One WAV file per recording, with both sides of the conversation mixed, in the app's documents directory under recordings/. The file name contains the other party's number and the start time.

What the app does with it. Nothing beyond listing, playing, deleting and — at your request — sharing. The app never transmits recordings to UNYX or to anyone else; they leave the device only through the operating system's Share function, to the destination you choose there.

Operating-system backups — different per platform:

• Android: excluded from backup and device transfer (android:allowBackup="false", exclusion rules for cloud backup and device transfer).
• iOS: the app's documents directory is part of the device backup and the iCloud backup; if you have that switched on, the recordings are in it.
• macOS: the app runs without the App Sandbox, so its documents directory is your personal Documents folder — the recordings sit in ~/Documents/recordings, and if iCloud Drive sync for "Desktop & Documents" is on, they are uploaded there.

Retention. Until you delete a recording in the app or uninstall the app (on macOS: until you delete the file — uninstalling leaves ~/Documents untouched). There is no automatic deletion.

Who is responsible. A recording also concerns the other party — they are a data subject. The controller for a recording is whoever makes it, or the organisation on whose behalf you are calling; UNYX has no access to the files.

6. Recipients and processors

UNYX runs the monitoring of its servers (metrics, logs) itself; no further service provider is used for it.

No data is disclosed for advertising purposes. No data is sold.

7. Transfers to third countries

Google and Apple also process data in the United States. Transfers rely on the European Commission's adequacy decision for the EU-US Data Privacy Framework, where the entity concerned is certified under it, and additionally on Standard Contractual Clauses under Art. 46(2)(c) GDPR.

All UNYX servers are fully hosted in Austria — their backups included. Data leaves the EU only through Google and Apple, as described above.

8. Retention at a glance

9. Your rights

Under the GDPR you have the right to

• access the data processed about you (Art. 15),
• rectification of inaccurate data (Art. 16),
• erasure (Art. 17),
• restriction of processing (Art. 18),
• data portability (Art. 20),
• object to processing based on a legitimate interest (Art. 21) — here, the abuse detection described in Section 5.1,
• withdraw consent with effect for the future (Art. 7(3)) — this applies to the health report in Section 5.12 and is done directly in the app.

The right not to be subject to a solely automated decision (Art. 22) does not apply here; see Section 10.

How to exercise your rights: send your request informally to kontakt@unyx.at; before we give access or erase anything, we verify that the request comes from the data subject. If you use the app through your employer, please address your request to your employer first — in that case they are the controller (Section 2.1) and UNYX assists them.

10. Automated decision-making and profiling

No profiling takes place. The app contains no third-party analytics or tracking components, and no personal characteristics are evaluated, predicted or scored. The optional health report (Section 5.12) is added into totals on arrival and attributed to no person and no device.

Licence verification is automated. The server decides, without human involvement, whether a device receives a licence seat. If the licence has expired, has been revoked, or all seats are already taken on other devices, the app refuses new calls and stops registering; a call already in progress is not cut off. The decision rests solely on the state of the licence and a count of devices in use — not on an evaluation of you as a person. In our assessment this is not a decision within the meaning of Art. 22(1) GDPR. The block can be lifted at any time by UNYX or your administrator; contact whoever you obtained the licence from.

11. Permissions on your device

These are the permissions the app asks you for:

Beyond these, the Android build declares technical permissions to the operating system that apply without any action from you and unlock no personal data: internet access and network state, audio settings, vibration, keeping the device awake, a foreground service for the running registration and the call, integration with the system's call management, and restarting the service after the device is switched on.

The system call log (Sections 3 and 5.9) needs no permission of the app's own: the operating system writes the entries when you switch the setting on.

Location: the app collects no location data on any platform; it declares no location permission (not in the Android manifest, nor in the iOS or macOS settings). That has one consequence you should know: an emergency call made through the app carries no location, and the emergency service may be unable to locate you. The emergency notice at the top of the end-user licence agreement (revision 2026-09-28.2) says the same.

The app has no video calling — it was removed on 2026-09-24; the camera is used only for QR codes and is not required to run the app.

12. Security

Connections to UNYX services use TLS. Licence keys, SIP passwords, call history and settings are held in the operating system's encrypted storage (Android Keystore, iOS Keychain and their equivalents). The device key that identifies the device to UNYX is generated in secure hardware where available and cannot leave the device. Whether the SIP connection to your phone system is encrypted depends on that system's configuration.

13. Right to complain, and applicable law

Alongside the GDPR, Austria's Data Protection Act (DSG) applies and supplements it — among other things on the duty of confidentiality (§ 1 DSG), processing in the employment context, and proceedings before the supervisory authority. Provisions of the Telecommunications Act 2021 (TKG 2021) on telecommunications secrecy may also be relevant to the telephony function.

You may lodge a complaint with the supervisory authority at any time:

Österreichische Datenschutzbehörde (Austrian Data Protection Authority)
Barichgasse 40–42
1030 Vienna
Austria
Telephone: +43 1 52 152-0
E-mail: dsb@dsb.gv.at
Web: https://www.dsb.gv.at