Privacy notice
This English version is a translation provided for information. Only the Hungarian text is legally binding: the Hungarian original.
The short answer: the website has no user accounts and no tracking, and we do not write visitors' IP addresses or the text typed into the search box to the website's log. Only one thing about the use of the website goes into the system log, and we describe it honestly here. For those who request API access or receive an API key, we process only the data needed for access (section 6); addresses sent through the API are processed on behalf of the client (section 7).
1. Who is the controller
| Controller | The operator of adatka.hu, currently a private individual (natural person): the operator runs the site neither as a sole trader nor through a company. If you need the operator's name and place of residence in order to enforce a legal claim against the operator (for example, for a data protection lawsuit), we provide them in the manner described in section 9 of the Terms of service (in Hungarian). Even without knowing these, you can exercise the rights listed in section 4, and you can also turn to the NAIH (section 5). |
|---|---|
| Contact | info@adatka.hu |
| Data protection officer | None designated. Under Article 37 GDPR, this is not mandatory at this scale. |
2. What we process and what we do not
What we do NOT process
- We write the visitor's IP address neither to the application log nor to a database. The web server placed in front of the server does not keep an access log, and in the application log a hyphen stands in place of the address. We have checked this in the lines of the log; we do not assume it. The server's firewall logs only rejected connection attempts (see the table below). When the API key is mandatory, the demo's request counter keeps the IP address in the server's memory until the end of the day (section 6.2, last row).
- We do not write the text typed into the search box to the log. Only the request line
goes into the system log, without the typed text: the path (for example
/suggest), the names of the parameters and the length of their values, and the response code. We have checked this in the lines of the log; we do not assume it. - The website has no registration, no account and no password. We issue API keys on request, by email; section 6 covers this.
- There is no visitor analytics tool, no advertising identifier and no profiling.
- There is no content loaded from external providers — the fonts, too, come from our own server. When you open the page, your browser does not connect anywhere else.
- There is no automated decision-making that would produce legal effects concerning you.
What we process
| Data | Why | Legal basis | How long |
|---|---|---|---|
| The request line in the system log — the path, the names of the parameters and the length of their values, the response code; without the typed text, the coordinates or any identifier | Operation and troubleshooting: it shows how many requests arrived and which of them failed. Requests sent through the API go to the same place; section 7 applies to them | Legitimate interest — Article 6(1)(f) GDPR | At most 14 days |
| Connection attempts rejected by the server's firewall: the sender's IP address, the targeted port and the time | Protecting the server against unauthorised access and attacks | Legitimate interest — Article 6(1)(f) GDPR; network and information system security, Recital 49 GDPR | At most 5 weeks |
| Your email address, if you write to us | So that we can reply | Legitimate interest — Article 6(1)(f) GDPR | 1 year from the close of the correspondence |
| If you report an accessibility problem or request an accessible alternative (Accessibility statement, sections 5 and 7): your email address, the text of your message — for example, the description of the problem, the page, the device and the browser, the address you searched for — and our reply; if a person assisting you writes on your behalf, their name and email address as well | Fixing the problem, fulfilling the request (for example, sending the match or the text of a page) and replying; proving what we replied and when, if proceedings before an authority or a court are started in the matter | Legitimate interest — Article 6(1)(f) GDPR. Data concerning health is covered in the paragraph below the table | 1 year from the close of the correspondence; if administrative proceedings or a court are started in the matter within that time, until the decision closing them becomes final (authority) or final and binding (court) |
| If you request the operator's name and place of residence (Terms of service, section 9): your name and email address, the name of the person on whose behalf you act, the content of your message, and what we sent you and when | Fulfilling the request, and proving to whom, when and for what purpose we provided these data | Legitimate interest — Article 6(1)(f) GDPR | 5 years from receipt of the request |
Data concerning health. We do not ask for data concerning disability or health: to fix the problem and to provide the accessible alternative, it is enough to describe what does not work. Under Article 9 GDPR, such data is a special category of personal data. If you nevertheless write it down because you would like us to take it into account when fulfilling your request, we process it only with your explicit consent and only for this purpose (Article 9(2)(a) GDPR). You can give your consent with one sentence in your message, for example: “I consent to the processing of my data concerning my health, as provided in this message, for the purpose of fulfilling my request.” You can withdraw your consent at any time by sending a message to info@adatka.hu; the withdrawal of consent does not affect the lawfulness of processing before the withdrawal. If such data arrives without consent, we handle the request without taking the data into account. In both cases, we delete the message containing such data once we have fulfilled your request or once you have withdrawn your consent; we keep our reply — which does not quote this data — in accordance with the accessibility row of the table. A message deleted from the mailbox may remain for some time in the backups of the email provider (section 3), in line with the provider's backup schedule; we do not restore it from there and do not use it.
3. Who receives it
No one we do not list. We do not sell data, do not pass it on to advertisers and do not use it for other purposes.
| To whom | In what role, with access to what data | Where |
|---|---|---|
| Hetzner Online GmbH Industriestr. 25, 91710 Gunzenhausen, Germany |
Processor — hosting provider: the server on which the website and the API run, and on which we store the system log and the database of API clients; and the storage space for the backups (Storage Box) | Falkenstein, Germany (European Union) |
| Nethely Kft. 1115 Budapest, Halmi utca 29. |
Processor — provider of the info@adatka.hu mailbox: the messages arriving at and sent from this mailbox, including API access requests | Budapest, Hungary (European Union) |
We do not transfer data outside the European Economic Area. We disclose data to an authority only where we are obliged to do so by law.
4. Your rights
Under the conditions set out in the GDPR, you can request information, access, rectification, erasure, restriction of processing and — where applicable — data portability, and you can object to processing based on legitimate interest.
You can send your request to info@adatka.hu. We reply without undue delay, within one month at the latest.
If a log entry contains no identifier on the basis of which we could identify you, we may be unable to link the entry to you without additional information. The practical reason for this is that the log contains no data from which it could be established with certainty who sent a given query. This protects the visitor's identity, but it also limits our ability to link a specific entry to a particular person later, or to find it at that person's request. In such a case, the rules set out in Article 11 GDPR apply.
Where we process your data on the basis of legitimate interest, your right to object is covered separately in section 6.7. The right to data portability applies to data that you have provided and that we process by automated means on the basis of your consent or a contract (Article 20 GDPR).
Within five years after your death, your rights of access, rectification, erasure, restriction and objection (Articles 15–18 and 21 GDPR) may be exercised by the person whom you authorised to do so by a disposition recorded in the electronic administration disposition register (ügyintézési rendelkezés) or by a declaration made to us and set out in a public document or in a private document of full probative value; if you made more than one such declaration, the later one counts. In the absence of such a declaration, whichever of your close relatives within the meaning of the Civil Code (Polgári Törvénykönyv) acts first may exercise the rights to rectification and to object, and — if the processing was already unlawful during your lifetime or its purpose ceased with your death — also the rights to erasure and to restriction. A person acting in this way proves the fact and date of death with a death certificate or a court decision, and their own identity — and their status as a close relative — with a public document (Section 25 of the Infotv., Act CXII of 2011 on the Right of Informational Self-Determination and on Freedom of Information).
5. Complaints
If you believe that we are acting unlawfully, you can turn to the supervisory authority:
| Authority | Hungarian National Authority for Data Protection and Freedom of Information (Nemzeti Adatvédelmi és Információszabadság Hatóság, NAIH) |
|---|---|
| Address | 1055 Budapest, Falk Miksa utca 9–11. |
| Postal address | 1363 Budapest, Pf. 9. |
| Electronic submission | Via the e-Papír service (epapir.gov.hu) or by sending it to the NAIH's official electronic storage (hivatali tárhely; short name: NAIH, KR ID: 429616918) — the details are on the naih.hu website |
| ugyfelszolgalat@naih.hu — for questions only. A complaint cannot be submitted by email: the NAIH treats a submission sent by email that requests proceedings as not submitted | |
| Phone | +36 1 391 1400 |
| Web | naih.hu |
If you live or work in another Member State of the European Union, you can also lodge a complaint with the supervisory authority there (Article 77 GDPR).
You can also go to court. At your choice, you can also bring the data protection lawsuit before the regional court (törvényszék) competent for your place of residence or your place of stay (Section 23(3) of the Infotv.); if you live in another Member State of the European Union, also before a court there (Article 79(2) GDPR). Going to court does not require that you first turn to the NAIH or that you first write to us.
6. API access request and API key
This section applies to you if you request access to the API, if you or your organisation receive an API key, or if an organisation has named you as a contact person. The last row of the table (IP address) also applies to anyone who uses an address search that works with a browser key on the website of an Adatka client, or — when the API key is mandatory — the website's demo. Otherwise, visitors to the website are covered in section 2, and addresses sent through the API in section 7.
There is no self-service registration and no user account: you request access by email, and the operator issues the key. Data relating to a legal person — for example, a company's name — is not personal data. However, if you request a key as a private individual or as a sole trader, or you are an organisation's contact person, the data below relate to you. We apply the same rules to every client.
6.1. Where the data come from
- From you: from the API access request and the subsequent correspondence.
- From your organisation, if the organisation has named you as the contact person or as the person responsible for the key. In that case, in our first message to you we give the web address of this notice (adatka.hu/jog/adatkezeles.html), and we specifically draw your attention to your right to object (section 6.7).
- From the operation of the service: the key data, the usage counters and the operations log are generated by us.
We do not collect data about you from publicly available sources.
6.2. What data, why, on what legal basis and for how long
| Data | Why | Legal basis | How long |
|---|---|---|---|
| API access request: your email address; whether you would like to receive messages about new features; anything else you provide in the message (for example, name, organisation, phone number, intended use); the time of the message and the technical headers added by email systems (these may include the sending mail server and, with some email providers, your IP address as well) | Assessing the request, getting in touch, issuing the key; proving that we issued the key on request and upon acceptance of the Terms of service | If you request the key for yourself (as a private individual or as a sole trader): processing necessary in order to take steps at your request prior to entering into a contract — Article 6(1)(b) GDPR. If you request it on behalf of an organisation: legitimate interest — Article 6(1)(f) GDPR, see section 6.3. | If we do not issue a key: 1 year from the close of the correspondence. If we do: as set out in the “Contact and correspondence” row |
| Client and key data: the name of the client (organisation or person); the key's label (for example, “Webshop”; we do not give it a person's name); its environment (live or test); its type (server key or browser key); for a browser key, the addresses of the allowed websites; the beginning of the key (its first 12 characters, or its first 16 for a browser key); the SHA-256 hash of the key; the time of issue, revocation and last use; the limits set for the key. We do not store the key itself in the database; we recognise it only by its hash. We hand it over once, at issue, in a separate message that contains only the key; after the handover we delete this message and the file containing the key. We keep the covering message about the issue of the key in accordance with the “Contact and correspondence” row. | Authenticating requests; deciding which endpoints the key can be used for and from which websites; applying the limits; revoking the key, for example if it has been lost or leaked | If you are the contracting party: performance of the contract — Article 6(1)(b) GDPR. If the contracting party is an organisation: legitimate interest — Article 6(1)(f) GDPR, see section 6.3. | For as long as the contract is in place. When the client's last key is revoked, we delete the hash, the allowed websites, the limits and the time of last use. We keep the client's name, the key's label and beginning, and the times of its issue and revocation for a further 5 years, solely for the establishment, exercise or defence of legal claims, with restricted access (5 years is the general limitation period, Section 6:22(1) of the Ptk., Act V of 2013 on the Civil Code). After that, we delete them. |
| Usage data: the number of requests and of processed rows, per key and per day. They do not contain the content of the requests — the addresses. | Applying the limits; if we have set a monthly quota for the key, applying the quota and warning in the response headers that the quota is close to being used up; informing the client about its own usage; capacity planning; detecting abusive use | If you are the contracting party, for applying the limits and the quota: Article 6(1)(b) GDPR. For capacity planning and in all other cases: legitimate interest — Article 6(1)(f) GDPR, see section 6.3. | 13 months from the day of the usage. After that, we delete them or convert them into an aggregate that cannot be linked to a key or a client and is therefore no longer personal data |
| Operations log: what happened, when and for which client — adding a client, issuing or revoking a key, changing the limits or the allowed websites — with the key's serial number, beginning and type, and for a change, the new limits or websites | Accountability and security: it can be established afterwards who received which key and when, and when we revoked it | Legitimate interest — Article 6(1)(f) GDPR, see section 6.3. | 5 years from the revocation of the client's last key, with restricted access |
| Contact and correspondence: the contact person's name and email address; if you provide them, their phone number and job title; the correspondence with us | Handing over the key; handling questions, requests, complaints and disputes relating to the service | If you are the contracting party: Article 6(1)(b) GDPR. If the contracting party is an organisation: legitimate interest — Article 6(1)(f) GDPR, see section 6.3. | Messages connected with the contract (request, issue and revocation of the key, acceptance of the terms, complaint, dispute): 5 years from the revocation of the client's last key. All other messages: 1 year from the close of the correspondence |
| Service notices to your email address: the issue of the key and the key itself; changes to the terms (Terms of service, Data processing terms, this notice); planned downtime, outages, security incidents; restriction or revocation of the key | So that you can use the service securely and are informed of changes in good time. These messages contain no advertising | If you are the contracting party: Article 6(1)(b) GDPR. If the contracting party is an organisation: legitimate interest — Article 6(1)(f) GDPR, see section 6.3. | For as long as you have a key. You cannot unsubscribe from these, but you can ask us to send them to a different contact person |
| Messages about new features: your name and email address; the time and text of your consent | Information about new or changed features of the Adatka service (the adatka.hu website and the API) when they are ready — at most once a month. We do not send offers from other companies, and we do not pass your email address on to anyone | Your consent — Article 6(1)(a) GDPR, and prior, unambiguous and express consent under Section 6 of the Grt. (Act XLVIII of 2008 on the Essential Conditions of and Certain Limitations to Business Advertising Activity). You can withdraw it at any time, without restriction, without giving reasons and free of charge: by email to info@adatka.hu, or by replying to any such message from us; in every such message we state where you can withdraw it. The withdrawal of consent does not affect the lawfulness of processing before the withdrawal | Until withdrawal. After withdrawal, we delete the email address from the mailing list without delay; the request itself is kept in accordance with the correspondence rules above |
| IP address — only in the server's memory, not written to a log or a database: when a browser key is used, the request counter kept per key and per IP address, and — when the API key is mandatory — the request counter kept per IP address in the website's demo | Applying the per-minute and daily limits, so that one visitor or one faulty program does not use up the quota at the expense of others; fending off denial-of-service attacks | Legitimate interest — Article 6(1)(f) GDPR; network and information system security, Recital 49 GDPR | The counter expires at the end of the day in question (at midnight UTC). We delete expired entries from memory at the next request arriving for the same counter, or at the latest when the service restarts |
When a browser key is used, we use the information about which website the request came
from (the Origin or Referer header) only to check the allowed
website, and we do not store it.
There is currently no invoicing; the service is free of charge. If a paid plan is launched, we will publish in this notice beforehand the data needed for invoicing, their legal basis and the retention period under accounting and tax legislation.
6.3. The legitimate interest and the balancing of interests
Where the table refers to legitimate interest, the interest is:
- providing the service to the organisation that received the key, and keeping in contact with the person it has named — this is in the interest of both the organisation and us;
- protecting the service and the other clients against overload and against abusive use of the keys;
- proving who received what access and when, and the establishment, exercise or defence of legal claims.
We have assessed whether your interests or rights override these, and concluded that they do not: the data are processed in a business relationship and are in the nature of work contact details, the processing of which the contact person can reasonably expect; we process only strictly necessary data, we do not create profiles, we do not sell the data or use it for advertising, the retention period is limited, and you can object (section 6.7). On request, we will send you the description of the balancing.
6.4. Is providing the data mandatory
No law requires it. However, the email address and the key data are conditions of access: without them, we cannot issue a key, and we cannot notify you about matters relating to the service. Messages about new features are voluntary: if you do not request them, this has no consequences at all, and we do not make access conditional on it.
6.5. Who receives the data; backups
The data are processed on our behalf by the processors listed in section 3; we do not pass them on to anyone else, and to authorities only on the basis of a legal obligation.
The database containing the keys and the client data is included in the backup every night. We keep 3 copies of the backups on the server and 14 copies in the hosting provider's separate backup storage (Hetzner Storage Box, Falkenstein, Germany), and the hosting provider takes a daily snapshot of this storage, which it keeps for 7 days. Therefore, deleted data disappears from the backups no later than the 21st day after deletion. We use the backup only for restoration; if a restoration takes place, we delete again the data deleted since the backup before the service is restarted. Messages deleted from the mailbox may remain for some time in the backups of the email provider (section 3), in line with the provider's backup schedule.
The server encrypts the backup before sending it to the backup storage (age, with an X25519 key); the key exists only on the server and with the operator, so the provider of the backup storage cannot read the content of the backup. From 5 October 2026, the encryption covers every nightly backup; the client database is not included in any earlier backup.
6.6. Automated decisions
The system automatically rejects requests that exceed the limit, that come from a website that is not allowed, or that are sent with a revoked key. This is the application of a pre-set technical rule, not a decision within the meaning of Article 22 GDPR that produces legal effects concerning you or similarly significantly affects you; there is no profiling. If you consider the limit or a rejection unjustified, write to us: a person will examine it and, if necessary, we will change it.
6.7. Your rights in this context
In this context, the right to data portability (section 4) means that, at your request, we hand over the data that you have provided and that we process by automated means on the basis of a contract or consent — for example, the list of your keys and your usage data — in a structured, commonly used and machine-readable format (CSV or JSON) (Article 20 GDPR). If the organisation names a new contact person, we delete the previous contact person's data in accordance with the correspondence rules above.
7. Addresses sent through the API: here the client is the controller
If you send addresses or coordinates from a program — for example, your customers' delivery addresses — you (or your organisation) decide on the processing of these data. In this relationship, you are the controller and we are the processor acting on your behalf and in accordance with your instructions (Article 4(7) and (8) and Article 28 GDPR). From 2 November 2026, the relationship between us is governed by the Data processing terms (in Hungarian); from that day, they form part of the Terms of service (in Hungarian) and apply to every use of the API that involves data relating to another natural person — with or without a key. The text typed into the website's demo is covered not by this section but by section 2: there, we are the controller.
What we do with the addresses
- We process the request in the server's memory and send back the response. We do not write the addresses to a database; we do not use them to expand our own address dataset, to serve other clients, for statistics, for profiling or for any other purpose, and we do not sell them.
- The request line of
GET /suggestandGET /reverserequests goes into the system log without the typed address and the coordinates: only the path, the names of the parameters and the length of their values, and the response code — without the IP address or the API key, for at most 14 days. This is needed to operate the service, to detect and fix its errors, and for its security. - The body of a
POST /cleanrequest — the processed address list — is not written to the log. - The usage data (section 6.2) contain only counts, not addresses. The addresses you send do not go into the backups either.
What we ask of you
- Send only the data needed to process the address. Do not attach a name, email address, phone number, client or order ID, birth details or ID document number to the address (Terms of service, section 5). To clean the addresses, we do not need to know whom they belong to.
- Inform your own clients or users that the address they provide is processed by a processor for the purpose of validation, enrichment or geocoding.
- Make sure that there is a legal basis for processing the addresses — and for passing them to us for processing.
If you are a customer or user of an Adatka client
If an online shop or another provider has had your address checked with Adatka, that provider decides on the processing of the address, so you can exercise your rights primarily with that provider. If you nevertheless contact us, we forward your request to the client to whom it relates — provided that we can establish who that is. However, the log contains no IP address, no API key and no address, so we usually cannot link a log line either to a client or to a person (Article 11 GDPR); a log line is deleted automatically after at most 14 days.
8. Changes
If we were to use personal data already being processed for a new purpose, pass it on to a new recipient or processor, transfer it outside the European Economic Area or keep it for longer than before, if we were to ask for new data for continued use of the service, or if section 6 or 7 changes in a way that affects clients' rights or obligations, we will publish the amended notice at least 30 days before it takes effect, indicate this on the home page, and also notify clients who have an API key by email.
If the notice only describes processing already under way more precisely or more completely, narrows the processing in favour of data subjects, or describes new processing that applies only to those who start using a new feature after publication, we publish the amendment without delay, and it takes effect on the day of publication.
Changes to the notice appear on this page with the date on which they take effect. We keep the earlier versions. If you need one of them, write to info@adatka.hu stating the date for which you want the text that was in force, and we will send it to you by email within 8 days. In these, too, we provide the operator's name and place of residence only in the manner described in section 9 of the Terms of service (in Hungarian).
In force: 20 September 2026 · Amended: 23 September 2026 (consent to messages about new features) · Amended: 25 September 2026 (section 4: your rights; the row on the cookie setting deleted) · Amended: 30 September 2026 (the controller's legal status; requesting the operator's name and place of residence — new row in section 2; access to earlier versions) · Amended: 2 October 2026 (section 2: a hyphen goes into the log instead of the IP address) · Amended: 3 October 2026 (new section 6: API access request and API key; new section 7: processing of addresses sent through the API, Data processing terms; section 2: the firewall log, accessibility messages and data concerning health, the row on messages about new features moved to section 6; section 3: the recipients by name; section 4: data portability, rights after the data subject's death; section 5: the NAIH's contact details, complaints in another Member State, recourse to the courts; the former section 7 is now section 8, including the rules on publishing changes; the short answer, sections 2 and 7: the typed text and the coordinates do not go into the log) · Amended: 5 October 2026 (section 6.5: encryption of the backups)