Ticket History and Data Protection: What to Keep, What to Delete, What to Ask

Ticket History and Data Protection: What to Keep, What to Delete, What to Ask

This is not legal advice. GDPR and its equivalents apply to a Telegram bot the same way they apply to anything else that stores customer conversations. Data protection obligations depend on where you are established, where your users are, what you collect and what you do with it. What follows describes how the data actually moves through a Telegram support bot, so you can have a useful conversation with someone qualified instead of an expensive one.

Have that conversation before you have a deletion request, not after.

Where the data actually lives

The thing most people get wrong: a support conversation on Telegram exists in at least three places, and deleting it from one does not touch the others.

1. Telegram's servers. Every message, held under Telegram's own terms and retention. You do not control this and cannot delete it on a user's behalf beyond what the API allows.

2. Your Telegram-side artefacts. The supergroup, the forum topic, the messages in it. You control these through the Bot API.

3. Your own storage. Whatever your bot or platform wrote to a database — user IDs, names, ticket metadata, message text, attachments, analytics events. This is the part you are most responsible for and the part people forget exists.

A user asking you to delete their data is usually thinking about the chat they can see. Your obligations, whatever they turn out to be, attach to all three.

What the API gives you

deleteForumTopic — "delete a forum topic along with all its messages" — requires the can_delete_messages admin right.

That is a genuinely useful erasure primitive: one call removes an entire ticket thread and its contents from the supergroup. If your ticketing is built on forum topics, you have a clean mechanism for removing a conversation on request.

What it does not do:

Deleting the topic and calling it done is the mistake to avoid.

Collect less

The most effective data protection measure is not having the data.

Support bots accumulate personal information without anyone deciding to collect it — customers paste order numbers, email addresses, screenshots containing full names, occasionally card details or passwords they should never have sent.

Practical steps:

Audit what you store. Not what you designed to store — what is actually in the database. Most teams find fields nobody remembers adding.

Set a retention period and enforce it automatically. Tickets closed more than N months ago get purged on a schedule. Pick N with advice; enforce it with a cron job, not intentions.

Never log message bodies in analytics. Ticket counts, categories and timings are enough for the metrics that matter. Message text in an analytics pipeline turns every dashboard into a copy of your support archive.

Handle credentials immediately. Customers will send passwords and card numbers. Have a documented response: delete the message, tell them what happened, tell them to change it. Do not leave it sitting in a topic your whole team can read.

Redact attachments. Screenshots are the biggest unmanaged source of personal data in support. If you keep them, keep them deliberately and briefly.

Questions for your lawyer

Bring these specifically:

Roles. Am I a controller for this data? What is Telegram's role in my setup, and do I need anything documented with them?

Legal basis. What am I relying on to process support conversations, and does it cover the analytics I run on them?

Retention. How long may I keep closed tickets? Does the answer change for payment-related ones, which I may need for tax or dispute records?

Erasure. When someone asks me to delete their data, what exactly must go, and what may I keep — for example a record that a refund was issued?

Backups. Erasure obligations against backups are a genuinely hard problem. What is acceptable in practice?

Cross-border. My agents are in several countries and my users are worldwide. What does that require?

Notice. Do I need a privacy notice for a support bot, and where must users see it?

A workable erasure procedure

Whatever the specifics turn out to be, the shape is consistent. Write it down before you need it:

  1. Verify the requester is the account holder — the Telegram user ID is your identifier
  2. Delete the forum topic with deleteForumTopic (removes thread and messages)
  3. Purge database records — tickets, message text, attachments, analytics rows
  4. Handle backups according to whatever your advice says is acceptable
  5. Keep the minimum you are permitted to keep, such as a financial record, and document why
  6. Confirm to the user what was deleted and what was retained, with the reason
  7. Log the request and the actions taken — the record that you complied

Test it once on a dummy ticket. A procedure nobody has run is a procedure that fails under pressure.

The Telegram-specific catch

You can only partly delete the user's own copy. deleteMessage removes incoming and outgoing messages in the private chat with your bot, but only within 48 hours of them being sent. Past that window their history is theirs. deleteForumTopic removes your side.

This surprises people and it is worth stating plainly if someone asks. It is also worth noting that they can delete it themselves — and, depending on settings, that deletion may not remove your side either. The two copies are independent.

The short version

Collect as little as you can. Know all three places the data lives. Set a retention period and automate it. Write the erasure procedure before the first request. Ask a professional the questions above rather than guessing from a blog post — including this one.

Not legal advice. API behaviour quoted from Telegram's Bot API documentation, verified September 2026. Data protection requirements vary by jurisdiction and change; consult a qualified professional.