Privacy Policy

Who we are

AppIn is operated by Zeisoft Yazılım Limited Şirketi, a company registered in Türkiye. We run getappin.com, this marketing site, and appin.to, the domain the links live on. Write to us at hello@getappin.com about anything on this page.

We handle personal data under the EU General Data Protection Regulation (GDPR) and Türkiye’s Personal Data Protection Law No. 6698 (KVKK).

Part one: if you tapped a link

You have no account with us and no reason to have heard of us. Someone published a link, you tapped it, and our job was to get you to the right place. Here is everything that happened.

What the worker reads from your request

Your user agent — the string every browser sends. Two things are worked out from it and nothing else: whether you are on iOS, Android or a desktop, and whether the request is coming from inside another app’s built-in browser. That second test recognises a fixed list — Instagram, TikTok, Facebook, Snapchat, Pinterest and LINE — and answers “none” for everything else. The user agent string itself is not stored.
A two-letter country code, which our content delivery network attaches to the request. Country level only. We run no location lookup and never see a town, a region or coordinates.
The referrer, if your browser sends one — the address of the page the link was on.

What one tap records

One row is then written to a click analytics store. It has eight fields, and these are the eight:

which link it was, as an internal id
the domain the link was on
the slug
the two-letter country code
the platform — iOS, Android or desktop
which of those six in-app browsers it was, or “none”
the outcome — handed to the store, shown the page that gets out of an in-app browser, shown a landing page, or the link did not exist
the referring address, cut off after the first kilobyte

The store timestamps the row. Nothing else is written.

What is not recorded, and cannot be

Your IP address is not in that list. It reaches our content delivery network, because no request on the internet can be routed without one, and it is not written to our analytics. Neither is the user agent string, any device or advertising identifier, or any cookie or id of ours. No link page sets a cookie. The one thing ever written to your browser is a single flag in sessionStorage on the page that gets a tap out of an in-app browser, so that it does not fire twice in one session; it holds no identifier, is never sent to us, and disappears with the tab.

The consequence is worth stating, because it is the point: there is no row for you, only rows for taps. The same person tapping the same link twice produces two rows with nothing linking them, and no row can be traced back to a person.

Things AppIn deliberately does not do

Unusually for this category, all of the following are absent by design, not pending: no SDK — there is nothing to install in anyone’s app; no install attribution; no deferred deep linking; no fingerprinting; no advertising identifiers; and no cross-site or cross-app tracking. No profile of you exists anywhere in this system. We do not sell personal data, and nothing recorded about a tap is shared for advertising — the marketing site’s own advertising tags are a separate matter and are set out under “This site advertises. The links do not.” below.

It is a limit as much as a principle. A customer who needs install attribution cannot get it from AppIn, and would use a measurement platform — whose link can be the destination of an AppIn link.

Where a link sends you is not us

An AppIn link’s job ends when you arrive. The App Store, Google Play or the website you land on is a third party with its own privacy policy and its own cookies, and we neither control nor monitor what it does. The same is true of a landing page’s app icon, which your browser loads directly from the app store’s own image servers.

There is a rule about where a customer’s link may point, set out under the addresses you publish. It applies to what they submitted, not to you, and nothing about your tap takes part in it.

Your rights as a visitor

The rights below apply to personal data. A click row has no identifier in it, so in practice we cannot find “your” rows to show or delete — not because we decline, but because nothing in the record points at a person. If you believe we hold something about you, write to hello@getappin.com and we will look.

Part two: if you have an AppIn account

What we hold

your name and email address
your password, stored only as a hash — never in a readable form
the links you create: slug, destinations, campaign parameters, landing page settings and any custom domain
your sign-in sessions. Each session record carries the IP address and browser it was created from, so a session can be recognised and an unexpected one acted on
your subscription status
fault records raised while you were signed in — an error our own software hit, carrying your internal account id and nothing else about you. See Diagnostics

Payments run through Dodo Payments as merchant of record: Dodo is the seller of record for your subscription and handles the payment details. Card numbers never reach us and we do not store them.

The addresses you publish

Every AppIn link shares one domain, so a destination that turns out to host phishing, malware, adult content or gambling puts every other customer’s links at risk — a platform blocks the domain, and the block lands before the click reaches us. What stands against that is a rule about the address itself, applied when you save a link and again every time you repoint it: an iOS or Android destination has to be an App Store or Google Play listing, or an https link on one of four attribution providers we allowlist by name. Only the desktop fallback takes a free-form address. It is a rule about where a link points rather than an inspection of what sits behind it: nothing is fetched from your destination in order to judge it, and no address of yours is sent to anyone else for a verdict on it. An address that does not meet the rule is refused — the link is not created, and a repoint that breaks it is not saved.

A link can also be stopped from resolving after someone reports it; what a report itself records is under If you report a link.

This is about the destination you submitted, and only that. Nothing about anyone who clicks your link takes part in it — visitors are Part one of this policy, and nothing there is used here.

Why we are allowed to process it

To perform our contract with you — your account, your links, your subscription.
Our legitimate interests — producing the click analytics the product exists to show you, keeping a shared link domain from being abused, and securing the service.
Legal obligation — accounting and tax records.

Where we rely on legitimate interests you can object; see below.

Emails we send you

Service messages — a password reset, a billing notice, a security alert — are part of having an account and cannot be turned off while it is open. Anything promotional is separate, requires your agreement, and can be unsubscribed from at any time without affecting your account.

Your rights

You can ask for a copy of your personal data, ask us to correct it, ask us to delete it, ask for it in a portable form, or restrict or object to processing. Email hello@getappin.com; we answer within one month, the period GDPR sets, and will say so if a request needs longer. What you can delete yourself, and what happens when an account is closed, is on Data protection and deletion.

You can also complain to your local supervisory authority — in Türkiye, the Personal Data Protection Authority (KVKK).

The rest, which applies to both

If you report a link

Reporting a link takes no account and no address. What you choose to send is the link, what is wrong with it, anything you want to add, and — only if you want a reply — your email, which we use to answer you about that report and for nothing else.

We also receive your IP address, your country and your browser, from the request itself rather than from anything you type. We use them to judge the report: whether it is one person or a hundred, and whether what it says is plausible. The details of a report, including the reporter’s IP address, country and browser, reach us by email and stay in our support records.

Diagnostics: when something breaks

When our own software hits a fault — a bug in our code, not an address that does not exist — it records the fault so that we can find it and fix it. It is worth naming here rather than leaving to be discovered, because it is the one thing we write that the sections above do not describe.

A fault record from the software behind your account holds exactly this, and the list is closed: the error and the point in our own code it came from; which of our services it was; the request’s method and the pattern of the address it matched — /links/:id, never the address itself, so no slug, no app id and no query string appears; and the build, the runtime and the versions of the software we had installed. Nothing about the browser or the person is attached: no IP address, no user agent string, no referrer, no cookie, and no part of any request’s body. Nor is there a trail of what happened beforehand — the parts of our error software that would have collected one are switched off rather than left at their defaults, because their defaults collect requests.

One personal datum is added, and only on a request that was signed in: your internal account id. Never your name, your email address or your session. It is there because “one account has hit this bug” and “every account has” are different faults, and nothing else in the record can tell them apart.

A refusal is not a fault — an address we decline to create, a page that does not exist, a request we answer with an error on purpose — so none of those is recorded here, and a bot probing for an address that was never ours writes nothing at all.

The software that answers appin.to links reports its own faults too, and its records are narrower than the ones above. Such a record holds the error and the point in our own code it came from; which of our services it was; the runtime and the versions of the software we had installed; and one word for the shape of the address being answered, drawn from a fixed list of six — root, robots, preview, campaign-preview, icon and link — which a visitor has no way to add to. A tap on any published link is the last of those six, so the word is the same one for every link we serve and it names none of them.

It carries no part of the request at all: no slug, no address, no query string, no method, no request body, no IP address, no user agent string, no referrer, no cookie and no timezone. That is not a list of fields we strip afterwards — the part of our error software that would attach a request is switched off, so there is nothing to strip. Nor is there any account id, because nobody is signed in on that path. If the background process that counts clicks fails, that failure is recorded, and such a record names the process and the error — never a link, a country or a row.

The dashboard you sign in to reports its own faults as well, and it reports them from inside your browser. Such a record holds the error and the point in our own code it came from; the build it happened on; and the versions of the software we had installed. One kind of report is made deliberately rather than on a crash: when the software behind your account refuses a request with a code this build of the dashboard has no sentence for, the record carries that code, the status it arrived with, and the shape of the endpoint that disagreed, drawn from a fixed list of five — POST /links, PATCH /links/:id, POST /projects, PATCH /projects/:id and POST /apps/resolve. It is the shape and never a real address, so nothing of yours is in it.

Nothing about you and nothing about the browser it happened in travels with it: no account id, no name, no email address, no session, no cookie, no IP address, no user agent string, no referrer, no timezone, no page address, no slug, no query string, no request body, no form field, no console line, no fetched address, and no record of anything you clicked. Two of those are worth saying twice. There is no account id at all — a fault here, unlike one from the software behind your account, cannot say whose it was, only that it happened. And there is no trail of what led up to it, which in a browser would be assembled out of exactly the things this list refuses; the part of our error software that would collect one is switched off rather than left at its defaults, because its defaults collect all of them. The report also instructs our error software not to fill in an address from the connection it arrives on, which on this surface is your own browser’s.

Fault records go to error-tracking software we run ourselves, on the same hosting already named under Who else is involved. No further company receives them. They are used to repair the fault and for nothing else — not analytics, not advertising, not anything about you.

How long they last is a count rather than a period: each of our services keeps its 10,000 most recent fault records, and older ones fall away automatically as new ones arrive. How much time that covers depends on how often we break something, so we do not state a number of days we cannot keep.

Finally, and separately: this marketing site sends no error reports of its own. The pages you are reading run no error-reporting client at all.

Who else is involved

Cloudflare — the edge network that resolves every link, the hosting behind this site and the dashboard, and the store that holds click analytics.
Our cloud hosting provider — the application and database behind your account. We do not publish which servers run what; we will name the provider on written request.
Dodo Payments — subscriptions and payments, as merchant of record.
Google, Meta and Reddit — the analytics and advertising tags on getappin.com and, after the same consent, on app.getappin.com. Google Analytics also receives a completed sign-up and a completed subscription from our own servers, identified by an account number. They receive nothing about a tap on an appin.to link, because none of their tags run there.

Each is bound to protect what it processes for us. We may also disclose data where the law requires it or in answer to a valid legal request.

This site advertises. The links do not.

This is the distinction that matters most on this page, so it is stated plainly rather than left to be worked out.

getappin.com — the marketing site you are reading — does measure and does advertise. It loads Google Tag Manager, and through it Google Analytics 4, to see how the site is found. The Meta Pixel, the Reddit Pixel and Google Ads are configured to load the same way — to measure our ads and to show them again to people who have visited — and will do so once we advertise on those platforms. The dashboard at app.getappin.com can load the same container after that consent, so a created link can be counted. No tag stores anything on your device until you agree, refusing is the same single click as agreeing, and the Cookie Policy names every cookie and how long it lasts.

Analytics. We measure how people find AppIn and how many go on to open an account or subscribe. Some of that is measured by our own servers rather than by a tag in your browser, so the banner does not govern it. These records are held in Google Analytics under an account number and contain no name or postal address. The typeface is still served from this domain rather than a font network.

Two things on the home page react to a link you paste, and they are not the same. The tool at the foot of the page runs entirely in your browser: what you type into it is never sent anywhere. The preview in the hero shows a real link page rendered by appin.to.

Pasting a link sends appin.to the store, the app’s id and how to render the page — never the address you pasted, which your browser reduces to that id first. So a campaign parameter or a tracking id on the end of what you pasted stays in the page.

The icon itself is loaded by your browser from Apple’s content network, which is where the App Store publishes it — so viewing the home page means your browser fetches an image from Apple, before you paste anything, because the preview starts on an example. That request carries what any image request carries and nothing we add to it. The icon is fetched from the store rather than copied onto our own servers because an icon we re-hosted would be one we could get wrong: a picture of your app that quietly went out of date is worse than no picture at all.

Three things are held, briefly. Your network address, for up to a minute at each step, only to limit how often the preview can be asked for. The app’s public name, subtitle and icon, cached for an hour at Cloudflare’s edge and for up to a day by our API. And if a store fails to answer, a line in our server log recording which app was looked up — never who looked it up.

Nothing else is kept: no account is created, no link is made, no click is recorded, and nothing is written to a database. The one exception is a fault. If the lookup behind the preview breaks, the error is recorded as set out under Diagnostics — which holds neither your network address nor the app you were looking at, only which of our services broke and where in our code. It is worth naming precisely because the rest of this paragraph is a promise.

The record of your address and the record of the app share no field, so what was looked up cannot be traced to who looked it up.

appin.to — the links themselves — does none of that, and this is not a detail of configuration. No tag, no pixel and no advertising identifier runs on a link page or a landing page. What a tap records is the eight-field aggregate row set out in Part one, with nothing in it that points at a person. Our advertising is about this marketing site; it is not wired into the product. Nothing anyone does with an AppIn link is used to target an ad, here or anywhere else.

The Cookie Policy also covers the one cookie that is outside all of this: the session cookie that keeps you signed in to the dashboard.

Where it is processed

Link resolution happens at whichever edge location is nearest the visitor, so it is global by design. The application and database run on servers we rent. Personal data may therefore be processed outside your own country, including outside the European Economic Area and Türkiye; where it is, we rely on appropriate safeguards such as Standard Contractual Clauses.

How long it is kept

Account records are kept while your account is open. Click rows are aggregate and identify nobody. How far back you can read them is set by your plan and published on the pricing page — that is a limit on what the product shows you, and it is not the same thing as a deletion schedule, which is why the two are stated apart here. We have not yet fixed a published deletion period for click analytics; when we do it will be stated here rather than left to be inferred. Fault records are kept by count rather than by time — the 10,000 most recent per service, oldest out first — as set out under Diagnostics.

Security

Everything travels over encrypted connections. Passwords are stored only as hashes. The click path — the part exposed to the whole internet — reads a read-only mirror of link settings and cannot reach the database holding accounts, so the busiest surface is not the sensitive one. Access to production systems is limited to the people who operate the service. No system is perfectly secure; these are the measures we take.

If a breach occurs that is likely to risk people’s rights, we notify the competent supervisory authority within 72 hours, as GDPR requires, and tell affected account holders directly where the risk to them is high.

Children

AppIn is a tool for people publishing their own apps, and accounts are not for under-16s; we do not knowingly hold their data. A tap on a link records nothing that identifies anyone of any age.

Changes

When the product changes, this page changes with it and the date at the top moves. Account holders are told about significant changes by email.

Contact

Zeisoft Yazılım Limited Şirketi
hello@getappin.com