Legal

Privacy

Last updated 18 August 2026

This describes the hosted deployment at appealy.app. If you self-host, none of it applies to you: your instance talks to Discord and to your own database, and the operator of that instance is the one holding the data.

What is stored

Appealy is a bot that runs applications, appeals and tickets for a Discord server. Almost everything it stores is either a Discord identifier or something a person typed into one of your forms.

What is written to the database, and why it is there.
Data	Why
Discord IDs	User, server, channel, role and message IDs. Everything the bot does is addressed by one of these.
Server name and icon hash	So the dashboard can show you which server you are looking at.
Submissions and answers	What an applicant wrote, which form, the outcome, the reviewer, and any denial reason.
Ban appeals	Same shape as a submission. Created when a server has appeals enabled and someone is banned.
Tickets	Who opened it, who claimed it, when it closed, the rating if ratings are on, and a link to the transcript if transcripts are on.
Giveaway entries, poll votes	Which user entered or voted, so the same person cannot enter twice.
Server configuration	Forms, questions, panels, DM templates, ticket types, verification, welcomer, role menus, anti-raid, quick responses, sticky messages, staff delegations.
Session	A session row, referenced by the `appealy_session` cookie.
Discord OAuth tokens	The access and refresh tokens Discord issues when you sign in, so the dashboard can list the servers you manage. Encrypted at rest.
Billing state	Which plan a server is on and the payment provider’s subscription reference. No card details, ever — see below.

What is not collected

No telemetry. This is asserted as a constant in shared/config/deployment.ts rather than promised in prose, so it would appear in a diff if it ever changed.
No message archive. The bot uses the Message Content intent to notice when a channel has been busy enough to warrant re-posting a sticky message. No message content is written to the database. The one thing that reads a channel’s history is a ticket transcript, generated when that ticket closes and posted as a plain-text file into a channel you configured — in your server, not ours. Only its URL is stored, and it is only produced if you switched transcripts on.
No card details. They never reach this service. The payment provider is the merchant of record and collects payment on its own pages.
No analytics on this website. The page you are reading contains no JavaScript at all. It requests one thing from outside this domain: the two typefaces, from Google Fonts.
No server ID lookup traffic on the status page. The shard formula is arithmetic, so it runs in your browser. Nothing is sent, which means there is nothing to log, cache or leak.

Cookies

One: appealy_session. It is httpOnly (JavaScript cannot read it), SameSite=Lax, and marked Secure in production. It holds a session identifier and nothing else — no token, no user data. Signing out clears it.

There are no analytics cookies and no third-party cookies. The dashboard is served from the same origin as the API for exactly this reason: it keeps the session cookie first-party by construction instead of relaxing it to something a browser would treat as third-party.

How long it is kept

Every server has a history retention window, and it is one of the metered caps: 30 days on the free tier, up to five years at the ceiling. Reviewed submissions — accepted, denied or withdrawn — are eligible for deletion once they pass it, and answers are deleted with the submission they belong to.

Automatic deletion is not switched on yet, and this page will not claim otherwise. The retention window is enforced everywhere it is read, and the job that removes expired submissions is written and running — but it is in reporting mode, recording what it would delete rather than deleting it. So reviewed submissions past their window are still stored today.

The reason is not oversight. The purge has never run, so the first time it does it removes every expired submission that has accumulated because it never ran — irreversibly, across every server at once. That is a decision to make having seen the numbers, not a default to leave switched on and discover afterwards. When it is enabled this paragraph goes and the sentence above stands on its own.

If you want a server’s history gone before then, /export takes a copy and a deletion request at the address below is honoured by hand.

Pending submissions are never purged, at any tier. One of those is live work sitting in a review queue, and deleting it because it aged out would silently drop an application someone is still waiting on.

Removing the bot from a server does not delete that server’s configuration. It is kept so that re-inviting restores what you had rather than making you rebuild it. If you want it gone instead of dormant, export first and then ask for deletion.

Who can see what

Applicants see their own submissions, through the DMs the bot sends them.
Reviewers see the submissions for the forms they have been given access to. Access can be delegated per person without granting Discord Administrator.
Anyone who can see your review channel sees whatever the review embed shows. A form can be set to omit the answers from that embed entirely — the reviewer sees the submission statistics in Discord and reads the answers on the dashboard instead. Worth switching on for any form that asks something personal, because a Discord channel keeps its message history indefinitely.
The server owner alone can run the full data export or a bulk import. This is deliberately stricter than every other permission in the product: some owners want the assurance that a complete dump of everything applicants wrote cannot be triggered by an admin they delegated day-to-day management to.

Taking your data with you

/export in the server produces one JSON file with every form, question, panel, submission, answer, DM template, ticket, giveaway, verification and welcomer config, role menu, anti-raid config, quick response, sticky message and staff delegation for that server. Billing and session data are deliberately excluded: those are an account concern, not portable server configuration.

The point of it is that a server which outgrows the shared bot can move to its own self-hosted instance and take everything with it. There is no lock-in step and no export fee.

Who else is involved

Third parties in the hosted deployment.
Who	What they get
Discord	Everything the bot sends and receives. They are the platform this runs on.
Tebex	The merchant of record for paid plans. They handle the payment and own sales tax and VAT registration where they sell. Card details go to them, not to us.
Google Cloud	Where the hosted deployment runs: Cloud Run, Cloud SQL, Memorystore and Secret Manager.
Google Fonts	Serves the two typefaces used by this website and the dashboard. Your browser requests them directly.

Nothing is sold, and nothing is shared with anyone not in that table.

Asking for deletion

Server owners can export everything and request deletion of their server’s data. Individual applicants should ask the staff of the server they applied to first — that server holds the submission, and its staff can act on it directly.

Email contact@creeperdiamonds.xyz. Use email rather than a public issue: a deletion request usually has to name the server, and sometimes the person, whose data is being removed, and an issue tracker publishes that to everyone who can read the repository. The GitHub repository is still the right place for bugs.

If you self-host

A self-hosted instance sends nothing to us — there is no telemetry, no licence check and no phone-home. Whoever runs that instance is responsible for the data in its database, and this page describes none of it.