Privacy Policy

Last updated 25 October 2026

This policy explains how personal data is processed when you visit this website, when you hold a Pelyr account, when you buy a paid plan, and when you use the map, the Stream API and HTTPS API, the MCP server, zone alerts, route events or data exports (together, the “Service”). It is provided under the EU General Data Protection Regulation (Regulation (EU) 2016/679, “GDPR”), the Austrian Data Protection Act (Datenschutzgesetz, “DSG”) and the Austrian Telecommunications Act 2021 (Telekommunikationsgesetz 2021, “TKG 2021”).

1. Controller

The controller within the meaning of Art. 4(7) GDPR is:

Use these details for any data protection question or to exercise your rights. Further details are in the Imprint.

2. Data Protection Officer

We have not appointed a Data Protection Officer (Datenschutzbeauftragter), as the law does not require one for our activities (Art. 37 GDPR). The controller named in section 1 is your point of contact for all data protection matters.

3. Overview of processing

Where we rely on legitimate interests (Art. 6(1)(f) GDPR), you have a right to object — see section 18.

4. Processors and infrastructure

The following providers process personal data on our behalf as processors under Art. 28 GDPR:

Other recipients

The following recipients are not our processors. They process the data they receive as controllers in their own right, under their own terms.

GitHub. If you sign in with GitHub, GitHub, Inc. (USA) confirms your identity to us and processes your data on its own platform under its privacy statement (§8, §15).

Map background. When you open a map on the dashboard, your browser loads the background map (coastlines, place names) from OpenFreeMap (tiles.openfreemap.org), operated by Hyperknot Software Kft., Hungary. OpenFreeMap receives your IP address, your browser’s technical data and the map area shown, as for any website you load, and processes them under its own privacy policy. We send OpenFreeMap no account data. Legal basis: Art. 6(1)(f) GDPR, our legitimate interest in showing a detailed map. You may object at any time (see section 18).

Recipients you choose. Zone alerts (§9) are sent where you tell us to send them: to a webhook address you enter — which may belong to a service such as Slack, Discord or Microsoft Teams — and to a Telegram chat you link to our bot. These recipients receive each alert on your instruction and handle it under their own terms. For Telegram this is the operator of the messenger, under Telegram’s privacy policy; to deliver to a chat, Telegram learns that our bot writes to it. An alert carries the names you gave the zone and the alert, the vessel’s identity, position and voyage data and the attribution of its data source — nothing else about you. If you connect an AI assistant to our MCP server, the results of the requests it makes on your behalf go to the provider of that assistant, which handles them under its own terms.

Paddle, our Merchant of Record

Paid plans are sold by our reseller and Merchant of Record, Paddle.com Market Limited, 30 Old Bailey, London EC4M 7AU, United Kingdom (for buyers in the USA or Canada, Paddle’s local entity named in its Buyer Terms). Paddle is not our processor: it processes your name, email address, billing address, country, VAT ID, payment details and transaction history as a controller in its own right, under its own privacy notice. We never receive your card or bank details.

So that Paddle can link a purchase to your account and carry out what you ask, we pass Paddle the identifier of your Pelyr account and the plans you choose when you open a checkout, and the plans concerned when you change a paid plan. If you have no Paddle customer identifier with us yet, we also pass the verified email address of your account (the address you sign in with, or the one you added to a GitHub account) to Paddle when we prepare a checkout, before any payment and also if you then close the checkout without buying. Paddle stores this address as a customer record, which it keeps under its own privacy notice even if you do not buy. Where you already have them, we also pass your Paddle customer and subscription identifiers, to change or cancel your subscription, to open Paddle’s customer portal and to end the subscription when you delete your account.

Prices on the dashboard. When you view our prices on the dashboard, signed in or not, your browser loads Paddle’s script from Paddle’s servers and asks Paddle for the prices, so that you see the price including the VAT of your country. Paddle receives your IP address, your browser’s technical data and which plans are shown, and uses the IP address to determine your country. Until you open a checkout we pass Paddle no account identifier and no email address. Paddle processes this data under its own privacy notice. Our website pelyr.com loads no Paddle script. Its pricing page shows Paddle’s prices for the country that Cloudflare determines from your IP address: our server asks Paddle for the prices of that country and passes Paddle only the country code, never your IP address, browser data or any identifier.

Legal basis for the prices: Art. 6(1)(f) GDPR — our legitimate interest in showing you, before you decide, the price you would actually pay, including the VAT of your country. You may object at any time (see section 18).

Of what Paddle reports to us, we store your customer and subscription identifier, the developer plan and map plan of the subscription, its billing interval and status, the end of the current billing period and any change scheduled for it, such as a cancellation at the end of the period. We store no name, email address, billing address, country or VAT ID from Paddle, except in the copy of a notice described below. For each checkout we prepare we also store the transaction identifier and the customer identifier Paddle gives it, with the plans and the time, so that only a purchase through our checkout unlocks a plan. If Paddle reports a subscription we did not prepare a checkout for, we keep its identifier so that its later events are not applied. We use this data to unlock your plan and to open Paddle’s customer portal for you. Before a checkout or a change of a paid plan we also record your confirmation of the characteristics set out in section 2a of the API Terms: the plans concerned, the version of the API Terms and the time.

Where we must notify you of a change we make to your paid plan, or a law requires us to notify you, and we hold no email address for you, we look up the email address you gave at checkout in Paddle’s records for that purpose only, without adding it to your account — see section 8, “Service emails”.

Legal basis: Art. 6(1)(b) GDPR; Art. 6(1)(f) GDPR for the record of your confirmation, so that we can prove it; Art. 6(1)(c) GDPR for the records we are required to keep ourselves (section 13).

We do not sell data about our users. Apart from our processors, data reaches others only as described in this policy: Paddle (above), GitHub when you sign in with it, the map background service, the alert channels and AI assistants you choose, and AIS data as described in section 11. Disclosure to public authorities occurs only where we are legally obliged to do so.

Cancellation and withdrawal functions

When you use “Cancel contracts here” or “Withdraw from contract here”, we record your declaration with the date and time we received it and the result of our automated check against bots, send a confirmation to the email address you give through Sinch Mailjet (see the table above), and look up the subscription that belongs to that address, in our records and, if needed, at Paddle. For a withdrawal, and for a cancellation where a renewal was charged for a billing period that began after the cancellation should have taken effect, we also read from Paddle the subscription’s completed payments, with their amounts, billing country and whether the purchase was made as a business. We use them only to decide whether we carry out a withdrawal automatically or a person reviews it, and to find such a renewal, which is refunded in full. We do not store them, only the reason for a review and the payment concerned. If another email address belongs to the same subscription, in our records or at Paddle, we also notify that address. We then pass your declaration to Paddle, which as merchant of record ends the subscription and makes any refund. So that no one can end your plan in your name, we act only on the subscription of the email address given, and the notice contains a link you can use if you did not send the declaration. Your IP address is used to count declarations sent from it within an hour; the count is held in memory only. To limit the emails sent to one address, we count them for one hour under a pseudonymous key derived from the address. We keep each declaration as proof for the period set out in section 13, also if you delete your account.

5. Website and server logs

When you access the Service, technical connection data is processed so the site can be delivered and operated securely: the IP address of the requesting device, date and time, the requested address including its parameters (for example the vessel or area an HTTPS API request asks for), the HTTP status, the referrer where transmitted, and the user agent. Cloudflare processes this data at the edge (section 4), and the access log of our reverse proxy records it, including your full IP address. Our services also log each request they answer, with its address, parameters, time and status. These technical records are not linked to your account; we use them to deliver the Service, to find faults and to investigate security incidents, and not to build user profiles.

Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in the secure, stable provision of the Service.

Storage period: the access logs of our reverse proxy and the logs our services write on their servers are deleted after 14 days; operational telemetry after 15 days; error reports at Sentry after 90 days. Entries needed to investigate a specific security incident are kept until it is resolved.

Operational telemetry and error reports

Our services send technical logs and traces — log entries and timing measurements — to a monitoring system we run ourselves on a server hosted by STRATO GmbH, Berlin (section 4), so that we can find and fix faults. Errors, and a sample of requests for performance measurement, are also reported to Sentry (Functional Software, Inc., USA, section 4). These records concern the operation of our services. They can contain technical request data, such as the address, parameters, time and status of a request and the type of client; for the Stream API, a shortened IP address and the non-secret prefix of an API key (see section 10). Error reports are set up not to contain the content of forms you send or your cookies. Data sent to Sentry may be processed in the USA (section 15).

Legal basis: Art. 6(1)(f) GDPR — legitimate interest in an operable, diagnosable service.

6. Cookies and local storage

Storing information on, or reading it from, your device is governed by § 165(3) TKG 2021. We store only what is strictly necessary for functions you use: a sign-in cookie once you are signed in (valid for up to 30 days), short-lived cookies that secure a GitHub sign-in or the connection of an AI assistant (up to 15 minutes), and, in your browser’s local storage, the settings you choose on the dashboard (such as theme, map filters and open panels) and the page to return to after confirming your email address. There are no analytics, advertising or cross-site tracking cookies of ours.

Paddle’s script is loaded only on dashboard.pelyr.com: as soon as you open the pricing page (dashboard.pelyr.com/pricing), signed in or not, and when you open the purchase dialog, a checkout or a payment link, so your IP address reaches Paddle (see section 4). It is never loaded on pelyr.com.

When you open a checkout, Paddle’s script sets cookies that are necessary for payment and fraud prevention, under Paddle’s own responsibility (see section 4).

On the forms listed in section 10, Cloudflare Turnstile reads signals from your browser to tell people from bots, which is strictly necessary to protect the form you are using. We do not use Turnstile’s pre-clearance option, which sets a Cloudflare cookie.

Because nothing beyond what is strictly necessary is stored on your device, no cookie consent banner is used.

7. Reach measurement with Plausible

To see which pages are used, we run Plausible Community Edition on our own server. Plausible is designed to work without cookies and without following anyone across sites.

We measure reach on both of the surfaces we operate: this website (pelyr.com) and the dashboard (dashboard.pelyr.com). They are kept as two separate sites in Plausible. Nothing links a visit to one with a visit to the other.

Each page view records the page, the referrer, the country derived from your IP address, a coarse device and browser type, and how far you scrolled and how long the page was in view. Your IP address is not stored. It is used only to determine the country and to derive a hash that changes daily, which is what lets Plausible tell a returning visitor from a new one within one day. There is no identifier that survives to the next day, and no way to recognise you across websites.

On the dashboard we additionally count a few named actions — for example that a ship was selected on the map, a coverage cell opened, a track loaded, a search run across all vessels, the vessel list filtered or paged, a ship saved, or a search run on the satellite page. We also count the steps of signing up and signing in, of choosing, buying, changing or paying for a plan (for example that the order was placed or the payment completed), of creating, copying or revoking an API key, of setting up alert channels, of activating the contributor portal, and of submitting a cancellation, withdrawal or dispute. Each such event records only its name: that a track was loaded or a search was run, never which ship, cell, filter or search term.

The dashboard is used while you are signed in. Three safeguards apply to it, so that being signed in does not make the measurement more revealing than it is on the public website:

• No identifier of you is sent. A measurement event carries no account, user or station identifier, and no custom properties.
• Your session cookie is removed before the event is passed on to the Plausible instance. The instance therefore receives nothing that identifies your account.
• The address is shortened before it leaves your device. An address that would identify a single station or vessel is reduced to a placeholder, so we can see how often the station and vessel pages are used but not which station or vessel was opened. Everything after the “?” in an address is discarded as well, which includes the destination carried along through a sign-in.

Processor: the instance runs on a server operated by STRATO GmbH, Berlin, Germany (see section 4). The measurement data is stored only there. On its way there each event passes through Cloudflare, which delivers our websites (section 4).

Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in understanding whether the website and the dashboard are useful, measured with the least data that answers the question. You may object at any time (see section 18).

8. Accounts and sign-in

An account is required for API keys (Stream API, HTTPS API and MCP server), paid plans, saved vessels and zone alerts. You create it either through GitHub — you authenticate at GitHub, and GitHub confirms your identity to us — or with an email address and password, which you confirm through a link we send to that address. An account has exactly one of the two sign-in methods.

A GitHub account may add an email address, which you confirm through a link we send to it. We use it for the emails about your account and its sign-in, for purchases and for the notices the law requires. GitHub stays the way you sign in; the address adds no password.

We store:

• for a GitHub account: your GitHub user ID and login name, and the date your GitHub account was created; if you add one, an email address; until you confirm it, it is held for at most 24 hours;
• for an email account: your email address and a securely hashed form of your password — never the password itself. Until you confirm the address, the address and the hash are held for at most 24 hours; a password reset link is valid for one hour;
• a display name;
• the scope and limits assigned to your account (permitted data sources, maximum number of keys and concurrent connections);
• timestamps: account creation, last sign-in, and when your GitHub login name was last seen;
• while you are signed in, a session record that links your sign-in cookie to your account; it ends when you sign out or after 30 days at the latest;
• a hash of a one-time recovery code, where one has been issued;
• the vessels you save on the map (their MMSI numbers), for as long as you keep them on the list;
• if you use zone alerts: your zones, alerts and channels and your acknowledgement of the alerts notice — see §9.

The GitHub account creation date is used as one signal against automated mass registration. Signing in transmits data to GitHub under GitHub’s own privacy statement, for which GitHub is the controller.

Legal basis: Art. 6(1)(b) GDPR for providing the account; Art. 6(1)(f) for its security and against abuse.

Service emails

If you have a paid plan, Paddle.com Market Limited, as merchant of record, sends you the receipts and the payment and renewal emails (section 4). We email you ourselves about changes to a paid plan you hold or to its limits, about changes to the API Terms, about a suspension of your access, about the end of free access, and where we are legally required to notify you. We send these emails to the email address of your account. A GitHub account without an added address has none, so for it we send notices of a change to its paid plan and notices required by law to the address you gave Paddle at checkout (section 4). We send these notices from our mailbox hello@pelyr.com (Microsoft 365, section 4), where a copy is kept for the period set out for email correspondence in section 13. These are not marketing.

Legal basis: Art. 6(1)(b) GDPR, as these notices are part of your contract (sections 6.4, 8, 9 and 12 of the API Terms); Art. 6(1)(c) GDPR for notices a law requires, such as Art. 34 GDPR; Art. 6(1)(f) GDPR for keeping a copy, so that we can prove the notice.

9. Stream API keys and usage accounting

For each API key we store a cryptographic hash of the key, a short non-secret prefix used to identify it in logs and in the interface, an optional label you choose, its scope, the timestamps of creation, revocation and last use, and who revoked it.

We record when a key was last used, so that you can identify unused or compromised keys.

If you connect an AI assistant through the MCP server, we also store which assistant you connected (its client identifier), the scope you granted, hashes of the access and refresh tokens issued to it, and when they expire, were replaced or were revoked. While a connection is being set up, the request and its one-time code are held for up to 15 minutes. Token records that expired more than 7 days ago are removed when the assistant next renews its access, and in any case when you delete your account.

For each key we count, per day and per calendar month, connections and rejected connection attempts on the Stream API and the messages and bytes delivered there, and per day the requests answered on the HTTPS API and the MCP server and the bytes delivered. These counts enforce no limit of your plan; we use them to plan capacity and to notice a key being abused.

We keep no record, linked to your account or key, of which vessels or areas you follow on the stream or query over the HTTPS API. Our technical access logs and error reports do record the address of each HTTPS API request with its parameters and the time (section 5); they are not linked to your account and are deleted after the periods given there.

Legal basis: Art. 6(1)(f) GDPR — capacity planning and security.

Zone alerts

Zone alerts tell you when a vessel enters, leaves, stays in or goes silent in an area you draw, or changes its status there. If you use them, we store:

• your zones (name and outline) and alerts (name, the events they report, the vessel criteria you choose — categories, MMSI and IMO numbers, destination terms — and your settings for pauses, quiet hours and digests);
• your channels: for a webhook its name, address and format, and for a generic webhook its signing secret, stored encrypted; for Telegram the chat’s id and title, which Telegram tells us when the chat is linked;
• while a Telegram chat is being linked, a hash of the one-time link token, valid for 15 minutes;
• your acknowledgement of the alerts notice: its version and when you gave it;
• the event log of your zones — which vessel did what and when, with a snapshot of its AIS data at that moment — and, per alert and channel, whether and when a message was sent, held or failed (an error class and the HTTP status, never the receiver’s response);
• for each zone, the state of the vessels inside it (since when, last position, status and destination), so that an event is reported once and not again after a restart.

A webhook address is shown back to you only shortened to its host, and our logs record the host only. The signing secret is shown once, when it is created or renewed.

Zones, alerts and channels belong to your account, whether you create them in the portal or through the HTTPS API with a key you have allowed to manage alerts. Deleting a zone or an alert stops its detection and delivery.

Legal basis: Art. 6(1)(b) GDPR — providing the alerts you set up; Art. 6(1)(f) GDPR for checking webhook addresses and keeping the delivery log, so that misuse and faults can be traced.

10. Abuse protection and how IP addresses are handled

Failed connection attempts on the Stream API are logged so that systematic key-guessing can be detected. In the Stream API’s own log the IP address is truncated before it is written:

• IPv4 keeps only the first two octets — 203.0.x.x
• IPv6 keeps only the leading network portion

This is enough to see whether attempts come repeatedly from the same network, and not enough to identify an individual connection. To block repeated failed attempts, the Stream API also counts them under a keyed hash of the full IP address; the count is deleted after at most about two hours. Cloudflare’s edge and the access log of our reverse proxy process the full address (section 5).

Rate limits at the edge and in our application count requests per IP address, held in memory for at most an hour; no profile is created. To stop password guessing, we count failed email sign-ins per email address for 15 minutes under a pseudonymous key derived from the address.

Legal basis: Art. 6(1)(f) GDPR — legitimate interest in the security of the Service and of its users’ keys.

Cloudflare Turnstile

We protect the forms for registration, email sign-in, password reset, adding an email address to a GitHub account, the contact form, and the pages “Cancel contracts here” and “Withdraw from contract here” with Cloudflare Turnstile. When you open one of these forms, your browser loads Turnstile from challenges.cloudflare.com. Cloudflare processes your IP address and signals from your browser, such as the user agent, to tell people from bots, and gives the form a token. Our server asks Cloudflare whether the token is valid. We do not send your IP address to Cloudflare with this check, and we do not store the token. Cloudflare describes its processing in its Turnstile Privacy Addendum.

If Cloudflare rejects the token or none is sent, a registration, sign-in, password reset, request to add an email address or contact message is not processed; you can write to hello@pelyr.com instead. A cancellation or withdrawal is always accepted and confirmed; if the check fails, we note this with the declaration and check it by hand before it is carried out.

Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in protecting these forms and the people who use them against automated abuse.

11. AIS and vessel data

AIS is a radio system that vessels use to broadcast their identity, position and voyage data publicly and unencrypted for safety of navigation. We receive these transmissions from third-party feeds and from community stations and pass them on.

Data. An AIS message can contain a vessel’s MMSI, IMO number, name, call sign, ship type and dimensions; its position, course, speed, heading, rate of turn and navigational status; and its destination, estimated time of arrival and draught. From these messages we derive track histories, route events (such as port calls and passages), the presence of vessels in zones, and a record of the names a vessel has used. From satellite images we also detect vessels and compare them with AIS data: we record whether a detected vessel was transmitting AIS, possible ship-to-ship meetings with the vessels involved, and the draught a vessel reports over time.

Sources. We receive AIS data from the AISHub data-sharing network, which shares data only among its members, from the open data services of public authorities, which anyone can access, some after a free registration (Fintraffic’s Digitraffic, Finland; BarentsWatch and the Norwegian Coastal Administration (Kystverket), Norway), and from receiving stations run by contributors to our network. All of them receive the radio signal that vessels broadcast openly.

Recipients. Visitors to the map who are not signed in see vessel positions without MMSI, name or source, under an identifier that changes over time. Holders of free and paid Pelyr accounts, wherever they are, receive the data with the vessel’s identity, depending on their plan: on the map and the satellite page, through the Stream API, the HTTPS API and the MCP server (including AI assistants they connect to it), and in the zone alerts they set up, which reach the channels they choose. Once we offer them, buyers of data extracts will receive them as well. Where a contributor’s station is set up for it, the data that station receives is also passed to the AISHub network, whose members receive it. Our processors (section 4) process the data on our behalf. How long we keep the data is set out in section 13.

Why we inform you here. We do not know who owns or crews a vessel and have no means of contacting them; finding out would require collecting further data about them, which Art. 11(1) GDPR does not require of us. We therefore provide this information publicly in this policy (Art. 14(5)(b) GDPR).

For commercial vessels this data relates to the ship, not to a person. It can nevertheless become personal data where a vessel is attributable to a natural person — a small private craft, for example — since the position of the vessel may then permit conclusions about the position of a person.

Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest lies in providing publicly broadcast maritime data, free and as paid products: (a) live data on the map, the stream and the APIs; (b) vessel history, route events and alerts; (c) satellite detections and their comparison with AIS data; (d) data extracts, once we offer them; (e) coverage statistics and research. Weighing this against the interests of those affected, we take into account that the data is broadcast openly and without encryption by law, is intended by design to be received by anyone, and is widely available from other sources.

If you are affected, you may object to this processing at any time on grounds relating to your particular situation (Art. 21 GDPR); contact us using the details in section 1. We examine every objection individually and tell you the outcome and what we have done. We can only act on our own processing: the vessel’s own transmission continues, and the same signal remains receivable by anyone.

Using data licensed by us under the Pelyr Data Licence for the surveillance or tracking of individuals is prohibited (Pelyr Data Licence, section 3.7); data under CC BY 4.0, NLOD or NLOD 2.0 remains subject to the law, including the GDPR.

Archiving. Received AIS messages are not only delivered live but also written to an archive we keep in Cloudflare’s object storage (R2). The archive holds individual messages, not merely aggregated figures, and each record carries the identifier of the feed or station it came from. We use it to compute coverage, to produce statistics, for research and, once we offer them, for data extracts.

12. Contributor stations

If you operate an AIS receiving station for the network, we additionally process data about it. To run the station we process the contact email address you give in the contributor portal, the station’s name, the position you register for it, any antenna and hardware details you enter, its coverage area, and its operating and uptime statistics. We use the registered position to check whether receptions are within plausible range; it appears in no public response. We calculate its availability per calendar month and show it to you in your dashboard. With each upload we also receive the device and software details your receiver reports (product, vendor, serial number, software version), the position it reports for itself, and a pseudonymised hash of the IP address it sends from. We use them to check that contributions are genuine; where a check raises a suspicion, they are kept in the record of that suspicion (section 13). Contributors are not paid, and we collect no bank details, tax identifiers or identity documents from them. Details are governed by the separate contributor agreement.

Raw recording in individual cases. There is deliberately no blanket raw archive of station uploads. Where there is a concrete suspicion that contributions are being manipulated, or where a delivery fault cannot be diagnosed from the metadata alone, we can switch on a recording for the individual station concerned for a limited period of at most 30 days at a time. While it is active, that station’s complete uploads are stored in Cloudflare’s object storage (R2), linked to the station, and are deleted after 90 days. They serve only to check the plausibility of contributions and to diagnose faults in a station’s delivery. They are not used for anything else. We do not announce a recording in advance, because an announced recording could not detect manipulation. If you ask us under Art. 15 GDPR whether we hold such a recording of your station, we will tell you, as we do for any other data.

Legal basis: Art. 6(1)(b) GDPR for operating the station, including calculating and showing its availability; Art. 6(1)(f) GDPR for the upload details and the raw recording — our legitimate interest in the integrity of the network’s data and of the coverage and availability figures we calculate, and in diagnosing delivery faults that cannot be traced from metadata alone.

13. Storage periods

Deleting your account deletes everything in this table that is kept until the account is deleted, including the vessel states of your zones; we keep no per-customer billing records after the account is deleted. Invoices and payment records stay with Paddle (section 4).

If you ask us to delete your data

An account that has no contributor station attached can be deleted by you directly, and that deletion is immediate. If you operate a station, deletion is not a single step: coverage records are anonymised rather than deleted, and records of suspected manipulation are kept for a limited period. You can request deletion at any time using the details in section 1, and we then handle it as follows.

“Restricted” means blocked, not kept in use: the data is retained solely to meet the obligation named beside it and is not otherwise processed. Once the period ends, it is deleted.

We carry out such a request within the period stated in section 18.

14. Contact by email

If you contact us at hello@pelyr.com, we process your address and the content of your message in order to answer it.

Legal basis: Art. 6(1)(b) GDPR where the enquiry concerns a contractual relationship, otherwise Art. 6(1)(f).

Contact form

If you use the contact form, we process your name, your email address and your message in order to answer you. The form sends them as an email through Sinch Mailjet (section 4) to hello@pelyr.com, with your address as the address for our reply. We do not store the message in our own systems or logs; it is kept in our mailbox, for the period set out for email correspondence in section 13.

To protect the form against abuse, your IP address is used transiently to count the messages sent from it within an hour; the count is held in memory only, and no profile is created.

Legal basis: Art. 6(1)(b) GDPR where the enquiry concerns a contractual relationship, otherwise Art. 6(1)(f) — our legitimate interest in answering enquiries; Art. 6(1)(f) GDPR for abuse protection.

Community access

If you ask us for Community access, by email or through the contact form, we process your request and what you tell us about your organisation, project or station in order to decide on it. Where you tell us you run a receiving station, we check whether your account has one registered. If we grant the access, we record with your account the group it was granted to, its start and end, a note on the decision, and who granted it. A person decides on every request. Your station’s availability figures and deliveries are not used for this decision.

Legal basis: Art. 6(1)(f) GDPR for deciding on a request — our legitimate interest in deciding to whom we give Community access; Art. 6(1)(b) GDPR for providing it once granted.

15. International transfers

Three of the providers in section 4 are companies based in the United States: Cloudflare, DigitalOcean and Sentry (Functional Software, Inc.). Transfers to them take place on the basis of the European Commission’s Standard Contractual Clauses (Art. 46(2)(c) GDPR) in conjunction with the relevant provider’s data processing addendum, and where applicable on the provider’s certification under the EU–US Data Privacy Framework (adequacy decision of 10 July 2023, Art. 45 GDPR).

GitHub, which you choose for sign-in, is an independent controller in the United States (section 4); what we exchange with it at sign-in relies on its certification under the EU–US Data Privacy Framework (Art. 45 GDPR).

Paddle (section 4) is based in the United Kingdom; transfers there, including what your browser sends to Paddle on the dashboard pricing page and in the purchase dialog, rely on the European Commission’s adequacy decision for the United Kingdom (Art. 45 GDPR). Where a purchase is completed in the United States, Paddle.com Inc. (USA) sells the plan; data exchanged with it is covered by the European Commission’s Standard Contractual Clauses (Art. 46(2)(c) GDPR), which form part of Paddle’s Data Sharing Addendum. Where Paddle’s Canadian entity sells the plan, transfers to Canada rely on the European Commission’s adequacy decision for Canada (Art. 45 GDPR).

In the case of Cloudflare this concerns not only delivery at the edge but also Turnstile (section 10) and the object storage described in sections 11 and 12. It is used without a jurisdictional restriction, so we cannot guarantee that the objects are stored within the Union.

In the case of DigitalOcean the databases themselves are operated in the Frankfurt region (Germany), so the data is stored within the Union. The company is nevertheless subject to US law, which is why the safeguards above apply to it as well.

In the case of Sentry, error reports are stored in the data region of our Sentry account, in the United States or in the Union. As the company is based in the United States, the safeguards above apply in either case.

The servers running the application (netcup) are located in Germany and are operated by a German company; no transfer to a third country takes place there. OpenFreeMap, which delivers the map background (section 4), is operated by a company in Hungary.

Sinch Mailjet (section 4) is a French company and sends our emails from data centres in the European Union. For support and operation of the service, companies of the Sinch group and service providers in the United States may access this data. Such transfers are covered by the European Commission’s Standard Contractual Clauses (Art. 46(2)(c) GDPR) in Sinch’s data processing agreement and, where the recipient is certified, by the EU–US Data Privacy Framework (Art. 45 GDPR).

Microsoft (section 4) stores our mailbox in the European Union. For support and security operations, Microsoft Corporation (USA) and other companies of the Microsoft group may access this data from outside the Union. Such transfers are covered by the European Commission’s Standard Contractual Clauses (Art. 46(2)(c) GDPR) in Microsoft’s data protection addendum and by Microsoft Corporation’s certification under the EU–US Data Privacy Framework (Art. 45 GDPR).

Notwithstanding these safeguards, a residual risk cannot be excluded that US authorities gain access to data under US surveillance law without you having a remedy equivalent to that under EU law.

Zone alerts reach the recipients you choose (§4) wherever they are; if you choose a recipient outside the Union, the alert is transferred there on your instruction. The same applies to an AI assistant you connect to our MCP server.

AIS data (section 11) reaches holders of Pelyr accounts wherever they are, including in countries for which the European Commission has made no adequacy decision. We do not conclude standard contractual clauses with these recipients. The restrictions on use set out in section 11 apply to them.

16. Data security

Connections to our websites, the dashboard and our APIs are encrypted in transit (TLS). Uploads from receiving stations are authenticated; where a station uses the UDP upload, its AIS data travels unencrypted, as it does over the radio. API keys are stored only as hashes. Access to production systems is restricted to the controller. The services run in separated containers with resource limits. How we handle IP addresses is set out in section 10.

17. Automated decision-making

We make no decision about you that is based solely on automated processing and produces legal effects concerning you or similarly significantly affects you (Art. 22 GDPR). Whether an account receives Community access is decided by a person (section 14).

Automated limits — the limits under section 6 of the Pelyr API Terms, listed on the pricing page, rate limits, a lower key limit for an account created with a GitHub account less than 30 days old, which only a paid developer plan (Fleet, Horizon or Global) lifts, and the revocation of an AI assistant’s connection when its credentials are misused — are technical protective measures and produce no legal or similarly significant effect within the meaning of Art. 22.

18. Your rights

You have the right to:

• access (Art. 15 GDPR) — what we process about you;
• rectification (Art. 16);
• erasure (Art. 17);
• restriction of processing (Art. 18);
• data portability (Art. 20);
• object (Art. 21) — see the box below;
• withdraw consent at any time with effect for the future, where processing is based on consent.

Requests go to the address in section 1. We respond within one month; where a request is complex, that period may be extended, and we will tell you.

Where you ask for erasure, section 13 sets out what is deleted, what is anonymised and what we keep, for how long and on which ground.

19. Right to lodge a complaint

You have the right to complain to a supervisory authority, in particular in the Member State of your residence, place of work or the alleged infringement. The competent authority for us is:

20. Obligation to provide data

You are under no statutory obligation to provide personal data. Some data is needed to conclude a contract: without a sign-in through GitHub or with an email address, no account and therefore no API key can be created; a first purchase of a paid plan needs a verified email address; a contributor station needs a contact email address and its position. Browsing this website requires no account.

21. Changes to this policy

We may update this policy to reflect changes to the Service or the legal position. The current version, with its date, is always published here.