Privacy Policy

1. Two very different modes – read this first#

In a self-hosted deployment, you run the entire bot – Discord identity, guild settings, ticket content, ratings, and any AI or remote-action credentials you configure – on your own server and your own database. TicketSmith (the company behind this website) has no server that receives, stores, or can access any of it. Sections 3 through 12 below describe TicketSmith Cloud, our hosted service, where we do run the bot and its database for you – if you self-host, they do not apply to your deployment. See Section 11 for that contrast again in one place.

2. What we collect, at a glance#

This is the short version, for TicketSmith Cloud only. Sections 3 through 10 below go into full detail on each row.

3. Signing in (TicketSmith Cloud)#

Logging into the dashboard uses Discord's own OAuth login (the identify, guilds, and guilds.members.read scopes). We use your Discord access token once, to read your user profile and the servers you belong to or manage, then immediately revoke it – it is never stored. What does get stored, in a signed cookie in your browser, is your Discord user id, display name, avatar hash, your role on the dashboard (staff or viewer), and, in hosted mode, the list of servers you own or manage on Discord. That cookie is cryptographically signed so it can't be tampered with, but it is not encrypted – it holds no password or token, only those identifiers. See Section 13 for the full detail on that cookie.

4. Your server's configuration (TicketSmith Cloud)#

Once you install and provision a server through the hosted signup flow, we store a configuration row for it: its status (active, trial, or suspended), any staff/viewer Discord role ids you've configured for dashboard access, your branding customizations, and the feature toggles you've set. This is what lets the bot behave correctly for your server specifically.

5. Ticket content (TicketSmith Cloud)#

The messages inside a ticket channel live in Discord's own infrastructure, the same as any other channel on your server – we do not keep a running second copy of everything said in a ticket. What we do store in our hosted database is:

• Ticket metadata: category, subject, status, priority, who opened and claimed it, and timestamps.
• Whatever a player typed into your ticket-opening form fields, if your server uses custom forms.
• If you turn on transcript export: a point-in-time HTML, text, or JSON export of the channel's messages, generated when the ticket closes and saved to our storage, posted to your log channel, and/or DMed to the ticket opener, according to how you've configured it. You can also turn on an automatic redaction pass (email addresses, IPv4-shaped addresses, card-number-shaped digit runs, and any custom pattern you define) that strips likely personal data before that file is written – this is a best-effort filter, not a guarantee that no personal data survives it.
• If you use the AI ticket-summary feature: the generated summary, resolution note, and tags for that ticket, plus which model produced them.

6. Ratings (TicketSmith Cloud)#

If your server uses post-close satisfaction ratings, we store the score, an optional comment (up to 900 characters), who left it, and which staff member handled the ticket.

7. AI features – opt-in, and what leaves our servers#

TicketSmith can use an AI provider – Anthropic, OpenAI, or Google Gemini, whichever one this deployment is configured to use – to draft replies, summarize tickets, answer routine questions from a knowledge base, or propose a remote action. When any of those features runs, the relevant ticket text (messages, subject, category) is sent to that provider's API to generate a response. We do not control, and are not responsible for, that provider's own handling of the data once it's sent – see their own privacy policy for that.

Two of these features – the dashboard's "AI Assist" reply drafting, and AI-proposed remote actions (Section 8) – are gated by an explicit, staff-only, per-server switch that defaults to off. No ticket text reaches an AI provider through either path until an administrator turns it on for that specific server. The bot's other AI capabilities (automatic ticket summaries, the knowledge-base auto-answer, and the pre-ticket FAQ responder) are controlled by this deployment's overall AI configuration, which is off by default and requires an operator to explicitly enable each one – and, for auto-answer and the FAQ responder, to list the specific ticket categories or channels it's allowed to run in, so nothing is ever answered by AI "everywhere" by accident.

A server can also supply its own AI provider API key instead of using ours, with /ai key set. That key is encrypted at rest (AES-256-GCM) in our database; we never log it or display it back to you in full.

8. Remote actions and the Local Agent – what we never see#

Some servers let staff ask AI to propose a remote action from a ticket's context – kicking a player over RCON, restarting a service, and similar – which a staff member must then explicitly confirm before anything runs. How that action is actually carried out depends on your deployment:

• Self-hosted: the integration (RCON, SSH, SFTP, a generic API, or GitHub/GitLab) is configured and executed directly inside your own bot process, on your own infrastructure. If you choose to let the bot store a credential instead of reading it from an environment variable, it's encrypted at rest in your own database – this never involves TicketSmith's servers at all.
• TicketSmith Cloud: the equivalent is the Local Agent, a small process you run on your own infrastructure. It holds your RCON, SSH, API, and GitHub credentials locally and makes one outbound encrypted connection to our dashboard, authenticated with a pairing token you can revoke or rotate at any time. When staff confirm a proposed action, our dashboard sends the Local Agent a bounded instruction (which integration, which template, which parameters) – never a free-form command – and the agent runs it and reports the result back. Your actual RCON passwords, SSH keys, API tokens, and GitHub tokens are never transmitted to or stored by TicketSmith's hosted servers – only the pairing token crosses that connection, and only to authenticate it.

9. Billing (TicketSmith Cloud)#

Checkout and card processing happen directly through Stripe. We never receive or store your card number, CVC, or bank details – Stripe handles that. What we do store, linked to your server's id, is your Stripe customer id, subscription id, plan id, subscription status, current billing period end date, and whether you've scheduled a cancellation.

10. The public template gallery#

If you choose to publish a ticket category, form, or panel to the public gallery, it goes through an automated scrubbing step first: every Discord role id, channel id, and your server's own id and name are stripped or replaced with generic placeholders (like "Staff role #1") before the listing is ever made public, and the result is independently re-checked to confirm nothing identifying survived. A published listing describes the shape of a template – labels, field types, button layout – never which server it came from.

11. Self-hosted, one more time#

To restate Section 1 plainly: everything in Sections 2 through 12 describes what TicketSmith Cloud, our hosted service, stores. If you instead run TicketSmith yourself – on your own server, with your own database, your own AI provider key if you choose to enable AI features, and your own remote-action credentials – none of that data ever reaches us. We have no server, dashboard, or database that receives it, and this website's own infrastructure has no visibility into a self-hosted deployment at all.

12. Who we share data with#

Discord, necessarily, to operate the bot and dashboard login. Your configured AI provider, only for the specific requests covered in Section 7, and only for servers that have opted into that feature. Stripe, for billing. We do not sell personal data or share it for advertising – no such mechanism exists anywhere in TicketSmith's code.

13. Cookies#

TicketSmith Cloud's dashboard sets one cookie for authentication, by default named ticketbot_session (the exact name is configurable per deployment). It's cryptographically signed with HMAC-SHA256 – if it's tampered with, the signature check fails and the session is rejected – but it is not encrypted, so treat it like a login session, not a place we hide secrets. It holds your Discord user id, display name, avatar hash, and your role on the dashboard (staff or viewer); in hosted mode, it also carries the list of servers you're allowed to manage. It is strictly necessary for authentication and is never used for tracking, analytics, or advertising.

During login, a second, short-lived cookie (the same name with an _oauth_state suffix) is set for a few minutes to protect against cross-site request forgery. It holds a random value, not your identity, and is deleted as soon as login completes.

Both cookies are strictly necessary for the dashboard to function – you can't stay logged in without them – so they're exempt from cookie-consent requirements, and TicketSmith doesn't show a consent banner for them. The marketing pages you're reading right now, including this one, set no cookies at all; the theme switch in the header is remembered in your browser's local storage instead, which never leaves your device.

14. Retention and deletion#

Today, tickets and their rendered transcripts are retained until the ticket or the guild (server) they belong to is deleted – TicketSmith Cloud has no automatic expiry or purge job that removes them on a timer. This isn't a policy choice dressed up as a technical limitation: it's a real gap, and we'd rather tell you plainly than invent a retention period that isn't actually enforced anywhere in the product.

There's also no self-serve "export or delete my data" tool built into the product yet. Until one ships, contact us (Section 16) and we will handle an export or deletion request by hand.

15. Your rights#

Depending on where you're located, data protection law (such as the GDPR) gives you rights over the personal data described on this page. TicketSmith honors these on request, regardless of your location:

• Access – ask what personal data we hold about you.
• Correction – ask us to fix data that's inaccurate or incomplete.
• Erasure – ask us to delete your data, subject to the honest limits in Section 14 (we handle this by hand today).
• Portability – ask for a copy of your data in a machine-readable format.
• Restriction – ask us to limit how we use your data while a request is being resolved.
• Objection – object to processing that relies on our legitimate interest as its legal basis.
• Withdrawal of consent – for anything that relies on consent rather than one of the other legal bases in Section 2, withdraw it at any time; this has no effect on the essential cookies in Section 13, which never relied on consent in the first place.

To exercise any of these, contact us via Section 16. We may need to verify it's really you asking – for a Discord-based service, that usually just means confirming from the Discord account associated with the request.

16. Contact and changes#

These addresses are being provisioned as ticketsmith.net comes online, so we can't yet promise they're live and monitored around the clock – please bear with us if a reply takes a little while. In the meantime, the fastest way to reach us is via Discord, through whichever server you're using TicketSmith in.

We may update this page as the service changes; continued use after an update means you accept the revised version.