Data controller
- Name
- Dominic Blaß
- Address
- Ludwig-Thoma-Str. 11, 95233 Helmbrechts, Deutschland
- Contact
- [email protected]
General
I run the database myself and do not sell or share your data with third parties. I don't use any analytics or tracking tools on this site.
Server and delivery
The server is hosted by Netcup GmbH in Germany; the database and every uploaded and generated file live there. The site is reachable through Cloudflare, Inc. (USA): every request passes through their network, which processes your IP address, the address requested, your browser user agent and the content transferred, provides the transport encryption, and keeps automated attacks away. The server itself is not reachable from the internet directly, only along that path. On the server itself, all your request leaves behind is which address was requested, when, with what answer and how long it took — no IP address of yours, no browser identifier, and not the page you came from. For pages whose address is itself a credential — the password reset link, the link that confirms your email address — no line is written at all. While a page or a program connected through the API waits for me to finish reading your specification or building your package, it keeps a websocket connection to my server open along the same path. All that comes through it is the news that something changed; nothing about it is stored, and the connection ends as soon as the answer is there. Legal basis: legitimate interest in operating the service securely and keeping it reachable (Art. 6(1)(f) GDPR).
Transfers to the United States
Two of the recipients named here are based in the United States. There is a data processing agreement with Cloudflare, Inc. whose annex contains the European Commission's standard contractual clauses (Art. 46(2)(c) GDPR); alongside them, Cloudflare declares its own certification under the EU-U.S. Data Privacy Framework in that agreement (Art. 45 GDPR). The clauses carry the transfer even if that certification were to fall away. Nothing reaches GitHub, Inc. at all unless you sign in there or have a generated package committed there — you start both yourself. GitHub is certified under the EU-U.S. Data Privacy Framework, for which the European Commission has found an adequate level of protection (Art. 45 GDPR). GitHub is not a processor acting for me in this; it is itself responsible for what happens in your own GitHub account. You can request a copy of the standard contractual clauses through the contact form.
Account data
If you create an account, I store your name and email address. Create it through the form and a hashed password comes with it; create it through GitHub and no password is stored at all — you can set one later, but you do not have to. If you accept the terms of service, I record when that was and which version you accepted — I need that to be able to show the terms were included in the contract (§305 Abs. 2 BGB); the legal bases are performance of the contract (Art. 6(1)(b) GDPR) and my legitimate interest in that evidence (Art. 6(1)(f)). Both are deleted with your account. If you enable two-factor authentication, I also store the related secret and recovery codes. Only a limited number of packages can be generated here per day; if I record a different number for your account, it sits in your account record and you can see it in your data export — with nothing recorded, the same limit applies to you as to everyone. The legal basis for that is my legitimate interest in keeping a free service usable for everybody (Art. 6(1)(f) GDPR). The messages the account needs go to your email address: confirming the address, resetting the password, confirming a changed address. They are sent through Heinlein Hosting GmbH in Berlin, which runs mailbox.org — the same place as the contact form further down. Otherwise, legal basis: performance of a contract (Art. 6(1)(b) GDPR).
Blocked accounts
If somebody breaches the terms of use, I may block the account; the terms say so under "Review, blocking and complaints". Two things are then stored: when the block was set and the reason for it. The reason is written for you — you are shown it when you try to sign in, and you find it again in your data export. Both sit in your account record, stay as long as the account does and are deleted with it; I keep no list of blocked addresses that outlives a deleted account. The legal bases are performance of a contract (Art. 6(1)(b) GDPR) and my legitimate interest in protecting the service against abuse (Art. 6(1)(f) GDPR).
Signing in with GitHub
If you choose to sign in through GitHub, you are sent to GitHub, Inc. (USA), which tells GitHub that you use this service. When you come back, I read your identifier, your username, your name and your verified primary email address there, once. Of those I store the identifier and the username, plus the name and email address as your account details. The access token that request is made with is discarded immediately afterwards — it is neither stored nor refreshed. Because GitHub has already verified the address, my own confirmation email is not needed. This sign-in is optional and replaces nothing: the account stays reachable by email and password without it. Legal basis: performance of a contract (Art. 6(1)(b) GDPR).
Sessions and cookies
I use a session cookie to keep you signed in; it only contains a session identifier, not your data directly. The session record itself (stored on my server) includes your IP address and browser user agent while the session is active. I also set small functional cookies to remember your language and theme preference, and whether the dashboard sidebar is collapsed — none of these are used for tracking or advertising, so no consent banner is shown. Your browser additionally remembers, in its own local storage and without any of it reaching my server, your theme preference and whether this site's messages should appear as desktop notifications. Both are there because you set them, both stay on your device, and clearing the site data removes them. Legal basis: legitimate interest in providing the service securely (Art. 6(1)(f) GDPR).
API access
If you connect a program rather than a browser — a script of your own, for example — it authenticates with an API token. I store the name you gave it, which abilities it carries, when it expires, when it was last used, and a hash of the token; the token itself is never stored, which is also why it can only be shown to you once. There is deliberately no IP address and no browser user agent on a token: the last-use timestamp is there so you can spot a credential you have forgotten about, not so that anybody can be traced. A token you revoke is deleted outright, and an expired one is deleted automatically within a day. Such a program sends the OpenAPI specification you give it to my server, exactly as uploading it in the browser would, and what happens to it then is described above. Legal basis: performance of a contract (Art. 6(1)(b) GDPR).
Contact form
If you use the contact form, I process the name, email address, subject and message you provide so that I can reply. On the way the text is checked automatically for the marks of unsolicited advertising; a message that shows them is flagged and delivered to me like any other. The message is not stored in my database but delivered straight to me as email: sending and the mailbox itself run through Heinlein Hosting GmbH in Berlin, which operates mailbox.org. It then sits in my inbox until I remove it there; answered enquiries are deleted after six months at the latest. Legal basis: legitimate interest in dealing with your enquiry (Art. 6(1)(f) GDPR).
Code generation requests
If you upload an OpenAPI specification to generate code, I store it on my own server to process your request. From it a PHP package is generated and kept as a ZIP archive on the same server so you can download it. The archive is deleted one day after you first downloaded it — kept that long so a download that broke off can be tried again — and deleted anyway if you have not collected it within seven days. Your specification stays either way, so you can generate the package again at any time. Alongside it I keep the title the document gives itself, so I can warn you when a file you upload later looks like a different API. If you have it committed instead, I also store the repository and branch you picked, plus the address of the resulting release. For each release I keep a record of the version numbers involved, what the compatibility check found, and which files changed, so you can be shown what you are about to publish. I do not send this data to any external AI or third-party service — as of today, no such integration exists. For each attempt I also record when it ran, how long it took, how much memory it needed and how large your document was, so the limits of the service can be sized properly. These measurements are deleted after 90 days, or sooner if you delete the request they belong to. Before you start a generation at all, the form shows you a preview of what your document contains. For that, the document is briefly stored on the same server and read by a separate worker process — separate because a document written by someone else should not be read inside the part of the program that serves the website. It is deleted as soon as the reading is over; if it is left behind for any reason, it is removed automatically within an hour. Legal basis: performance of a contract (Art. 6(1)(b) GDPR).
Checking specifications
When you have an OpenAPI specification checked, it is briefly stored on my own server and read by a separate worker process — separate for the same reason as the preview: a document written by someone else should not be read inside the part of the program that serves the website. The document is deleted as soon as the reading is over; if it is left behind for any reason, it is removed automatically within an hour. The result — the document’s title, version and size, and the places that stood out while reading it — sits in a temporary store for ten minutes so that the page can show it to you, and then expires by itself. It is not stored permanently, and there is no list of your earlier checks. That you submitted a document is recorded as described under “Submitted specifications”. Legal basis: performance of a contract (Art. 6(1)(b) GDPR).
Submitted specifications
For every specification you submit I record, separately from the generation itself: when it arrived, how large it was, what file extension it carried, a checksum of the document, whether it cost you a day of your allowance, which generation it became, through which offering it came — the generator or the API spec checker — and whether it was accepted, rejected or unreadable. If it was read, I also record where its references ($ref) point — including at other people’s addresses, which are never fetched — and what the check noted. This serves secure operation: without it a rejected file leaves no trace at all, and I could not tell that the same file is arriving from several accounts, or that one account keeps submitting things that are not specifications. That is also why the entry outlives the deletion of the generation it belonged to — otherwise it could be removed by the very person it is about. It is deleted after 90 days, and immediately with your account. Legal basis: legitimate interest in the security of processing (Art. 6(1)(f), Art. 32 GDPR). The entry appears in full in your data export.
Statistics
For every package generated, which OpenAPI version the document used is counted — the version and the month only, with no reference to you, your account or your request. No one can be recognised from a figure like that, so it is not personal data, and it therefore stays as it is when you delete your account. I use it to decide which OpenAPI versions the generator still has to support.
GitHub connection
Connecting GitHub is optional. If you do, I store your GitHub account name, whether it is a personal account or an organisation, and the identifier of the app installation you created — nothing else, and no access tokens: a short-lived one is obtained from GitHub each time it is needed and discarded afterwards. I ask GitHub which repositories you granted access to in order to show you that list. If you then choose to have a generated package committed rather than downloaded, that generated code is transmitted to GitHub, Inc. (United States) and written into the repository you picked. That code carries the name you entered in the form as the copyright holder — prefilled with your account name — in the composer.json and in the licence file; if the repository is public, so is that name. Disconnecting, or deleting your account, removes my record and uninstalls the app from your GitHub account, ending my access — repositories and everything already committed stay as they are, since they are yours. Legal basis: performance of a contract (Art. 6(1)(b) GDPR).
External resources
This site loads nothing from third parties. The fonts live on my own server and are served from there; there is no content delivery network, no embedded maps, videos or social media buttons, and no analytics tooling. Loading this page therefore discloses your IP address to no further provider.
Backups
So that a broken server does not mean your data is gone, the database is backed up once a day. The backup is encrypted on the server before it leaves it and is then stored with Cloudflare, Inc. in their R2 storage service in the European Union; the server itself cannot decrypt its own backups. They are deleted automatically after 90 days. A backup holds the same records as the database, including your account details and your generation requests; uploaded specifications and generated packages are not included. When you delete something it disappears from the database immediately, but it may still appear in an older backup until those 90 days are up — a backup cannot be edited after the fact without destroying it. If I ever do have to restore one, I re-apply your deletion afterwards. Legal basis: legitimate interest in resilient operation (Art. 6(1)(f) GDPR) and the obligation to take appropriate technical measures (Art. 32(1)(c) GDPR).
Retention
I keep account and generation-request data for as long as your account exists — with two exceptions: the generated ZIP archive is deleted 24 hours after your first download, and no later than seven days after it was built, and the measurements of a generation attempt after 90 days. You can delete an individual generation request at any time, which immediately removes it together with the specification you provided, the generated package and the release records belonging to it. When you delete your account, I delete your account record, all your generation requests with their release records and any files belonging to them, your GitHub connection — uninstalling the app from your GitHub account — and your active sessions immediately. Whatever merely running the service produces is deleted automatically: sessions expire after two hours, expired password reset tokens and the abuse-throttle counters — including the one for your daily allowance, which expires after 24 hours anyway — are removed daily, and the application log and failed background jobs after 14 days. Expired API tokens are deleted daily. A document you uploaded only for the preview or to have it checked is deleted as soon as it has been read — and every hour a sweep checks whether one has been left behind for longer than an hour.
Your rights
You have the right to access, rectify, erase, or restrict the processing of your personal data, and the right to data portability and to object to processing, under Art. 15–21 GDPR. You can self-service export or delete your account data at any time from your account settings.
Right to object
You have the right to object at any time, on grounds relating to your particular situation, to processing that rests on a legitimate interest (Art. 6(1)(f) GDPR). Here that covers running the server and its logs, the sessions and the functional cookies, handling your message from the contact form, the record of submitted specifications, the blocking of an account, and the backups. If you object, I will stop processing that data unless I can demonstrate compelling legitimate grounds that override your interests. An objection needs no particular form — the contact form, or an email to the address above.
Automated decisions
There is no automated decision-making within the meaning of Art. 22 GDPR, and no profiling either. The generator runs automatically, but it decides nothing about you: it reads a document you hand it and writes code from it.
Data protection officer
As a private individual with no employees, I am not required to appoint a data protection officer (§38 BDSG). For any privacy-related questions, please contact me directly.
Right to lodge a complaint
You have the right to lodge a complaint with a data protection supervisory authority. The responsible authority is:
Bayerisches Landesamt für Datenschutzaufsicht (BayLDA)
Promenade 18
91522 Ansbach
[email protected]
Changes to this policy
This policy was last updated on 2026-10-12.