Privacy Policy

This policy applies to the Tibia Claims website, backend, and Discord bot. The independent Tibia Claims project operator determines how application data described here is used. Tibia Claims is a fan project and is not operated by or affiliated with CipSoft GmbH.

Discord, Supabase, Vercel, and game-server community services also process information under their own terms and privacy policies. This policy describes Tibia Claims' handling of data; it does not replace those services' notices.

You can browse the claim board without signing in. The Tibia Claims backend currently retrieves Nevia's public area, spawn, claimant, Tibia character, reservation identifier, and reservation-time data. It briefly caches that feed and sends the normalized current and future claims to the frontend. The frontend does not contact the Nevia source directly.

Claimant names, character names, and reservation times displayed on public boards are visible to anyone. The Nevia community service remains the source of truth and controls its original copy of that data. Tibia Claims does not create, change, or cancel Nevia claims unless a separate external-authority integration is explicitly enabled.

For a native Tibia Claims server whose claim controls are enabled, the backend may create, merge, list, and cancel reservations itself. A private server board and its reservations are available only to authorized users for that server. If a native server is later made public, its current and future claimant character names, hunting grounds, and reservation times may be shown on its public board.

Discord sign-in is optional and is handled through Supabase Auth using an OAuth PKCE flow. Supabase creates an authentication user and session and may store authentication fields supplied by Discord, including an email address if Discord returns one. The Super Administrator may privately search the Discord display name, username, and email held by Supabase when selecting a registered user for Server Administrator access. The email is not an authorization key and is not shown to Server Administrators, other users, or the public.

For a signed-in profile, the backend may store the Supabase user identifier, the immutable numeric Discord user ID, Discord username and display-name snapshots, an optional Discord avatar URL, and creation and update times. The numeric Discord ID is the identity key; mutable names are used only for presentation.

When you agree to the Terms through the website or Discord bot, Tibia Claims stores your internal Supabase account identifier, the exact legal-release identifier and Terms and Privacy versions, whether acceptance came from the website or Discord, and the server-recorded acceptance time. This evidence is used to determine whether authenticated features are available and to demonstrate which release the account accepted. It does not store the text of a checkbox, an IP address, or a Discord message in the acceptance row.

The Terms allow one Tibia Claims account per person. Tibia Claims may compare immutable Discord IDs, account status, successful character verification, and public same-account character relationships to detect duplicate accounts and ownership conflicts. The service does not collect government identity for this purpose and cannot guarantee that one Discord identity corresponds to one natural person.

Ordinary website sign-in does not persist or use the Discord provider access token. It keeps the Supabase access and refresh tokens needed for the session in essential browser cookies. A separate Discord-claim verification link uses an essential HttpOnly cookie for up to one minute to reference only the original pending command; it does not require another Discord authorization or create a website account. Anyone holding that private link could complete only the original claim, so it should not be shared. To remove the expired private reply, the bot briefly stores its Discord interaction token encrypted in the backend; the token is deleted after use or when the retry window ends. Signing out clears the active browser session but does not delete the Supabase authentication user or Tibia Claims profile.

Tibia Claims uses the immutable numeric Discord user ID to designate the project Super Administrator and to assign Server Administrators to specific supported servers. To make an assignment, the Super Administrator can search a bounded private directory of current Discord sign-ups by display name, username, or Supabase-held email. Search results are used only to select the intended account; the backend resolves the immutable Discord identity and records the server-scoped assignment. A Server Administrator cannot access this directory or another user's email.

An administrator assignment may store the Discord ID, status, revision, assigned servers, timestamps, and—after that person signs in—limited Discord display-name and avatar snapshots. The application does not copy directory-search emails into the administrator assignment or its audit history. Administrator access is private and is checked by the backend on each protected request.

Administrator designation, server-scope changes, suspension, reactivation, revocation, Super Administrator break-glass recovery, native scheduled-allowance resets, and exact-claim cancellation-and-refund actions create security or operational audit records when those features are enabled. A record may include the action, actor and affected-user Discord ID snapshots, affected server and claim day, selected public character-name snapshot, claim identifier and revision, refundable scheduled minutes, before-and-after allowance accounting and revision, operation and request identifiers, the stated or command-generated administrative reason, outcome, and time. Test-server actions may identify a synthetic Test Character instead of a player account. These records are not part of the public claim board. Administrators must not put passwords, tokens, private conversations, or unrelated personal information in an administrative reason.

Administrative audit records are append-only for application roles and may be retained after an assignment is suspended or revoked, or after an account-deletion request, where reasonably necessary to prove authorization history, investigate abuse, resolve a dispute, secure the service, or comply with law. Access to the emergency Super Administrator recovery operation is reserved for the database operator and is also audited.

An authorized administrator may manage one account-scoped access group, timed strikes, and the reserved BLACKLIST only for an assigned server. The administration interface shows the Tibia Claims username and its verified characters on that server world. It does not show email addresses, Discord IDs, or Supabase identifiers.

Tibia Claims stores a server/account group or restriction head, immutable group-setting versions, scope and expiry where applicable, limited character-assignment and ownership-version projections needed for enforcement and claim attribution, and append-only administrative events. The account choice applies to every current and future verified character owned by that account on the server world.

BLACKLIST is a reserved deny-only group and overrules the account's ordinary group. Group and restriction changes may affect eligibility for future server actions and may cancel matching native claims while preserving immutable history.

For a native server with this feature enabled, an authorized administrator may designate one actively bound Discord guild as the server's role source, load its role catalogue, select ordinary roles, and assign an explicit app-owned priority. Tibia Claims stores the source guild and selected role identifiers as backend-private keys, bounded guild and role name snapshots, mapping and priority revisions, the linked app group and rulebook, the last successful manual-sync revision and time, and append-only administrator audit. Role names and Discord role position never grant administrator authority or silently define claim policy.

A website synchronization or guild-scoped /sync_groups command reads Discord member roles only for linked Tibia Claims accounts that accepted the current authorizing legal release. It asks Discord for those exact members in the designated guild; it does not import the guild roster, messages, channels, role permissions, unrelated roles, or accounts that have not accepted this release. If a member holds several selected roles, Tibia Claims retains only the highest-priority selected app-group association needed to display the signed-up group member and apply that same group to a character later verified on the server's Tibia world. It does not retain a reusable list of all roles held by the account.

Before a synchronization changes membership, a private five-minute preview records a bounded role-fact and effect plan, source and revision fences, digests, affected account references, and the account, character, and claim effects shown to the administrator. A failed, incomplete, changed, expired, dismissed, or unconfirmed read changes nothing. Consumed and expired previews are removed by bounded routine cleanup; durable synchronization history retains app-owned mapping, group, aggregate result, and digests rather than a reusable per-account Discord role list. The current winning app-group association is retained until a later confirmed sync replaces or removes it, the source or group is removed, or the account is deleted. Account deletion invalidates every pending preview that references that account and deletes that current association before it can be applied. If the administrator who configured a role source later deletes the account, Tibia Claims removes the live Supabase actor link while retaining the bounded Discord actor and rank, reason, app mapping snapshot, and time needed to prove that administrative action; the server configuration remains operable.

A timed strike or indefinite BLACKLIST first uses a private five-minute, one-use effect preview that is removed after consumption or expiry. A confirmed restriction stores the affected account and server, its verified server-world character projections, backend claim-capability scope, computed expiry where applicable, non-sensitive administrator reason, matching claim effects, actor and operation evidence, and audit time. Public boards do not disclose blacklist or strike status, administrator reasons, the linked Discord account, or selected role facts.

When you search for a character, the frontend sends the name to the Tibia Claims backend. The backend asks TibiaData for public Tibia.com character information, including the current canonical name and world, traded and deletion indicators, and other characters voluntarily visible on the same public account. The discovery response may contain the public Comment field, but Tibia Claims does not return that field to the browser or retain it. Hidden characters are not discovered or inferred, and the visible list may be incomplete or delayed.

You choose which available public characters to add. Tibia Claims stores selected character names and current worlds, normalized values used for matching, an optional supported claim-server mapping, the linked account, assignment source and verification status, a verification time when applicable, and creation, update, or removal times. Characters on worlds without a Tibia Claims board may still be kept in your account library. No legacy character-assignment import is used.

To verify an added character, Tibia Claims generates a code with an exact 60-minute active window and asks you to place it in the selected character's public Tibia.com Comment. Reopening the account page, using another tab, or requesting the challenge again during that window returns the same code and expiry; it does not rotate or extend before expiry, and a replacement is available only afterward. The backend stores a random challenge nonce, derivation version, and limited creation, expiry, attempt, and consumption metadata, and uses a server-only HMAC secret to derive the displayable code. The plaintext code is not stored or logged. The backend then asks TibiaData for the latest available public character information and checks the Comment. TibiaData caching may delay recognition of a newly saved code for a few minutes. The raw Comment is processed only for that check and is not returned, logged, or stored.

The code is publicly visible while it remains in your Tibia.com comment. You may remove it after the check succeeds; an expired or consumed code cannot be reused by Tibia Claims as a new proof.

A successful current check stores a VERIFIED status and verification time for the code-bearing character and selected saved siblings returned in the same public Tibia account response. Every observed visible sibling participates in conflict reconciliation. If another Tibia Claims account has an active verified or unverified assignment for an observed sibling, that conflicting assignment is made inactive and limited reassignment evidence is retained without identifying the other user in a consumer-facing response.

Verification is point-in-time evidence that someone able to edit the selected character's public Comment completed the check and that the visible siblings appeared in the same successful response. It does not establish civil identity, guarantee continuing control, grant Discord rank, establish eligibility under a server's rules, or approve a claim. Nevia, Karmeya, and other server authorities may make separate character and claim decisions.

Removing a character currently marks its association inactive so that integrity history can be preserved. Under the planned full reconciliation controls, superseding a character will also mark the former association inactive while preserving the limited dispute and claim history described here; neither action immediately erases the association history or shared character record.

Active monitoring is not enabled today. The source, scheduling, restricted-worker, and successor-legal-copy foundations exist, but lifecycle collection, active-claim presence collection, policy consequences, and monitoring Discord messages remain off pending deployment and enforcement of that release, focused validation, retention and account-deletion checks, reacceptance, and staged canary activation. Database structures, contract versions, or future-facing text do not mean that a character is currently being monitored.

If lifecycle monitoring is activated, a successful public-character lookup may create a limited point-in-time observation containing the queried verified character, returned visible characters, direct-target or visible-sibling evidence type, relationship fingerprint, source observation time, and bounded outcome. If a previously observed sibling disappears, the backend may check that character individually. Disappearance, failure, or inconclusive data alone does not prove a transfer and does not automatically reassign, remove, or downgrade it.

If active-claim presence monitoring is activated, it is limited to a real VERIFIED assignment attached to that claimant's currently active native Tibia Claims reservation. Future reservations before their start, unrelated saved characters, Nevia claims, unverified or stale assignments, and synthetic Test Characters are excluded. TibiaWorker may fetch a public world roster outside a database transaction, evaluate only the bounded eligible targets in memory, return sanitized online, offline, or unknown results, and immediately discard the full roster. Raw provider payloads, full rosters, unrelated names, public Comments, account profiles, emails, Discord IDs, and authentication data are not stored in monitoring observations or logs.

Presence absence is an inference from independently fresh, complete public world data. A duplicate source response cannot advance it. A timeout, failure, stale or partial result, ambiguity, maintenance condition, online result, or any other unknown state breaks the absence interval. Only at least 600 seconds, or 10 minutes, of uninterrupted confirmed absence may ask the backend to recheck and cancel that active claim through the ordinary authoritative cancellation and accounting path. The collector cannot cancel a claim. After a committed cancellation, Tibia Claims may queue one private Discord direct message identifying the claim, threshold, and resulting accounting or claim-now cooldown; a delivery failure does not undo the cancellation.

For an active verified character most recently reported as recently traded, the planned backend may search Tibia.com's current auctions using only the exact public character name, once for that auction publication cycle and distributed after the expected publication window. It will not routinely search completed auctions or crawl the full character library. A matching active listing may place the character on an auction hold and require fresh direct verification before protected claim actions. The hold is not cleared merely because the listing later disappears, and failed or inconclusive checks are not treated as proof that no auction exists. These searches send no Discord ID, Supabase identifier or session, email address, or account-profile information.

A cross-Discord ownership conflict without a supporting recent trade signal may create a private integrity flag. Repeated transfers, suspected duplicate accounts, or shared-account conflicts may additionally create a manual-review hold. The service may retain the involved identifiers, verification events, times, and reasons needed to resolve the conflict, but it does not expose one user's Discord or Supabase identity to another.

When you are signed in, favourite-spawn preferences are stored with your Tibia Claims account separately for each claim server so that the same choices can be used by the website and Discord bot. The browser may temporarily cache this information for presentation, but clearing browser data does not remove the account preference. You can remove a favourite or change its alert setting through a supported interface.

Vercel hosts the frontend and backend and provides firewall, delivery, and Web Analytics services. Hosting and security systems may process an IP address, request time and route, referrer, browser or device information, network and diagnostic data, and approximate location. Tibia Claims uses Vercel Web Analytics for aggregate usage information and does not use it for advertising profiles. Vercel states that Web Analytics does not use third-party cookies.

Tibia Claims' application logs are designed to record operational details such as request identifiers, fixed routes, status, duration, and aggregate outcomes without recording authentication tokens, cookies, claim contents, character names, public character comments, or raw verification codes. Infrastructure providers may maintain their own security and access logs.

The same Tibia Claims Discord bot may be installed in more than one approved Discord guild. Discord sends the bot the application, interaction, guild, channel, and invoking-user identifiers together with the selected command and bounded command options. The bot verifies Discord's request, rejects direct-message and unbound-guild use, and sends a signed request to the Tibia Claims backend. The backend maps the immutable guild ID to one active claim-server binding and the immutable Discord user ID to the signed-in Tibia Claims profile before returning a result.

A guild binding may store the Discord guild ID and display-name snapshot, the assigned Tibia Claims server, status and revision, setup or revocation reason, the authorizing Super Administrator, and timestamps. Binding, rebinding, and revocation create audit records. More than one guild may be assigned to the same Tibia Claims server, but a guild has no access while it is unbound or revoked.

For replay protection, reliable retries, and security audit, Tibia Claims may retain a request fingerprint, short-lived service nonce, interaction, guild, channel, and invoking-user identifiers, command type, processing status, bounded result or safe error response, and timestamps. A completed interaction receipt is automatically eligible for routine deletion 30 days after completion; that cleanup never deletes an interaction still marked as processing. Service nonces are accepted for only 10 minutes and expired rows are removed during routine command cleanup. Service signing secrets, Discord bot tokens, interaction tokens, authorization headers, and raw signatures are not stored in these receipts or application logs. Player-specific and administrator command replies use private delivery rather than a guild-channel post; depending on Discord and the transport, this may use an ephemeral response or a private direct-message fallback. Discord independently processes interactions under its own policy.

The Discord bot is a transport and does not connect directly to the Tibia Claims database or own claim rules. Character registration may return the requesting user's selected public character, world, temporary verification code and expiry, and currently visible public sibling names so the bot can display its private result; it does not receive another account holder's identity. A real native claim command, when enabled for the bound server, uses the same backend operation and produces the same validation, reservation, allowance, conflict, cancellation, and audit result as the corresponding website action. Enabled administrator role-sync, strike, blacklist, allowance-reset, and exact-claim refund commands send only the bounded selected character, operation options, reason, and immutable interaction context to the backend, which privately resolves and authorizes the target before showing a confirmation. The bot does not receive the target's email or Supabase identifier. Favourite and notification features use the account and server resolved by the backend; moderation and external-server claim commands apply only after their corresponding backend capabilities are separately enabled.

When you create or cancel a reservation on a native Tibia Claims server, the backend may store the claim-server and global hunting-ground identifiers, authenticated account and Discord-identity snapshots, selected verified character assignment and ownership version, requested and accepted claim mode and times, an optional reminder choice, claim-day state, applicable server-rule and character-group revisions, status, merge or cancellation history, and creation and update times.

Mutation records may also contain an idempotency key, request fingerprint, bounded result, claim revision, append-only event evidence, and the current scheduled-allowance epoch. A confirmed general allowance reset appends a new server-and-claim-day allowance epoch while preserving earlier claims, charges, and penalty evidence. A confirmed exact-claim refund cancels only the selected current claim and returns only the scheduled minutes currently charged by that claim. Its record may retain the performing administrator, privately resolved affected account or synthetic Test Character, public character-name snapshot, selected claim and expected revision, refundable segment and minutes, reason, before-and-after accounting, and confirmation outcome. This information is used to prevent duplicate or overlapping reservations, preserve fair conflict handling across the website and Discord bot, calculate remaining claim allowance, investigate disputes, and prove how a claim or administrative action was handled. Authentication credentials, Discord bot tokens, and raw character verification comments are not stored in claim records.

For each signed-in account and claim server, Tibia Claims may store favourite hunting-ground identifiers, whether availability messages are enabled for each favourite, and creation or update times. These preferences are account-scoped and server-scoped: saving a favourite for one server does not save it for another account or server.

When an optional scheduled-claim reminder is enabled, Tibia Claims stores that choice with the claim and may prepare a Discord message for the linked Discord user. Availability alerts are generated only for servers and claim sources that explicitly support reliable availability changes. Saving a favourite does not by itself mean that availability alerts are supported for an externally managed source such as Nevia.

To deliver an enabled Discord notification reliably, Tibia Claims may retain the recipient's numeric Discord ID, notification type, bounded message content, related server, claim, or hunting-ground identifiers, scheduled delivery time, processing lease, attempt count, delivery status, limited failure information, and timestamps. Delivery may be retried after a temporary failure and stopped after a permanent failure or when the related claim becomes stale. Discord processes the direct message under its own policy. Disabling a preference stops future applicable messages but cannot recall a message that Discord has already accepted or that is already being processed.

For team hunts, the Party Hunt Analyzer supplies member character names and financial totals. Names are imported read-only, including members not requesting points, and stored separately from anonymous metrics. The party export's outgoing damage and healing totals are retained privately as supplemental evidence, never as incoming-damage evidence or public rankings. Each teammate's Input Analyzer is optional; when supplied, explicit resistances are required. Selecting Credit this teammate requests matching to a current verified account owner for that member only, and requires their complete Input/resistance evidence. Only authorized reviewers see matching and reward decisions. Acceptance may award one point to each distinct eligible opted-in matched teammate, and one point to the contributor or two total when at least one teammate supplies complete evidence, subject to existing point limits. Names and normalized submitted evidence are visible in your own history, but reviewer comparisons, screenshots, matching/reward decisions and enforcement data are excluded. Names are self-reported, not proof of participation, and never enter public statistics or another contributor's history. Preview identities expire with the preview; retained identities follow the contribution lifecycle and are cleared on contribution deletion, submitting-account detachment/deletion, or relevant character-assignment or credited-account deletion. Anonymous accepted metrics and existing reward-ledger deletion rules remain unchanged.

For a contribution, Tibia Claims stores the normalized values and context the user confirms, the selected global hunting ground, submission method and state, field provenance, timestamps, revision, and moderation outcome. The original Hunt and Input Analyzer reports are parsed in memory and are not stored. Tibia Claims may temporarily retain only recognized normalized evidence after removing player names, timestamps, and unrelated rows, together with a non-reversible keyed digest used for duplicate detection. Analyzer previews expire after 15 minutes. Ordinary players and Catalogue Editors must also provide one screenshot of the full Tibia game window showing the selected character, equipment, Hunt Analyzer, and Input Analyzer; exact review-authorized contributors may omit it. JPEG, PNG, and WebP screenshots are limited to 7 MiB, stored in a separate private Vercel Blob store, protected by a file digest against exact duplicate submission, and scheduled for removal 20 days after submission.

The contributor can privately see the state and safe decision reason for their own submission, but cannot retrieve the screenshot from submission history. Authorized Catalogue Reviewers can inspect normalized detail, up to 100 recent submissions from the same contributor account, and retained screenshot evidence through an authenticated no-store backend response while needed for moderation, together with the contributor's Discord display name and username and the selected verified character name and world so submitted work can be assessed and attributed. Screenshot download addresses and storage credentials are not disclosed. Your browser receives a short-lived, upload-only link to send your selected screenshot directly to our private storage; this link cannot read screenshots. Those identity details, account-wide history, and screenshots are not shown to other contributors or on public spawn pages. Catalogue Reviewers and other actors with the same exact review authority can accept, deny, or withdraw a global observation. Separately authorized Platform and Super Administrators may suspend claim and contribution access, lift a suspension, or terminate an account. Moderation stores the decision, a bounded reason or reviewer note where applicable, revision, timestamps, cancellation count, and an append-only audit event. Application logs do not record either pasted Analyzer report, retained evidence, contribution contents, account email, or authentication credentials.

Accepted observations may be published as reviewed normalized values, hunt context, sources, sample counts, review recency, and derived ranges without identifying the contributor. The public projection does not display the submission identifier, source server, Discord identity, email, Supabase account identifier, IP address, field provenance, raw or redacted Analyzer evidence, reviewer identity, or pending, denied, and withdrawn values.

We process information to deliver claim boards and enabled native reservations, authenticate users, provide account and character features, keep server-scoped favourite and notification preferences, deliver enabled Discord reminders or alerts, assign and enforce scoped administrator access, manually synchronize selected Discord roles into app-owned server groups, administer account-scoped server strikes and blacklists, preserve authorization and reservation accountability, authenticate and replay-protect Discord bot requests, apply the contractual one-account rule, protect the service, diagnose failures, measure aggregate usage, respond to requests, and comply with legal obligations. If the rollout-pending character-integrity controls are enabled after its validation and activation gates complete, we may additionally process the described minimized data to reconcile current character control, detect ownership conflicts, remove stale associations, preserve rename/world history, and determine whether the verified claimant of an active native reservation has been continuously absent for the guarded threshold.

Where European data-protection law applies, the legal bases may include performing these Terms or taking steps you request to provide account features; legitimate interests in operating, securing, and improving a community service; compliance with legal obligations; and consent where applicable law requires it. When processing relies on consent, you may withdraw it for future processing.

If server management enables message cleanup in its saved registration or claiming text channels, a separate self-hosted TibiaWorker container periodically reads message identifiers, authorship and bot/webhook flags, timestamps, message type and pin state. Bounded per-author Discord member-role lookups identify explicitly exempt staff roles. This is channel hygiene, not character ownership, claim adjudication or a retained conversation archive. Message text, attachments, display names and reusable member-role lists are not stored for cleanup; Discord may return text fields that the worker immediately discards.

Recurring cleanup applies only to eligible ordinary-user posts made after activation, on the next scheduled check without an additional age delay. It preserves pinned posts, bot/webhook posts, protected guide messages and selected exempt users or roles, and remains independent of history cleanup. A separately and explicitly confirmed initial cleanup may delete existing Discord-deletable history in small batches without first counting every message, including pinned, staff and other-bot messages; it preserves only messages authored by the authenticated TibiaClaims bot. Deleted Discord messages cannot normally be recovered. The operator must publish this notice and channel-specific guidance before live deletion is enabled.

The worker stores only bounded local message-ID checkpoints and pending IDs for restart safety, and sends the backend aggregate counts and fixed status codes rather than messages or authors. The backend retains channel settings, selected exemption IDs, an administrator reason and actor reference, bounded run metadata and approval evidence. Cleanup audit events and completed/cancelled run records become eligible for bounded deletion after 30 days, through configuration refreshes or later administrator changes; cleanup actor references detach on account deletion. Local checkpoints are not an archive and are limited to 100 retained checkpoint records; an operator removes the isolated volume when decommissioning cleanup. Discord processes deletions under its own terms and retention practices.

We do not sell personal information, use it for third-party advertising, offer paid features, or collect payment-card details. Information is processed by Vercel for hosting, analytics, security, and the separately deployed bot endpoint; Supabase for authentication, database, and scheduled-delivery services; and Discord for sign-in, enabled bot interactions, direct-message delivery, and bounded designated-guild role and member-role lookups requested by an administrator. For character discovery and ownership verification, the backend sends only the requested or selected public character name to TibiaData. If monitoring is later activated, TibiaWorker sends TibiaData only the public character or world lookup needed for the bounded leased targets; it does not send Discord IDs, Supabase sessions or identifiers, email, account profiles, claims, or notification preferences. The backend contacts Nevia only to retrieve its public board feed and does not currently send signed-in account, favourite, notification, or character-profile data to Nevia or Karmeya.

Information may also be disclosed where reasonably necessary to comply with law, protect users or the service, investigate abuse, or establish and defend legal claims. Clicking a Tibia.com character link or another third-party link takes you to that service, whose own policy then applies.

These providers operate internationally, so information may be processed outside your country. Their policies describe their processing locations and transfer mechanisms. Tibia Claims will update this notice if its own transfer arrangements materially change.

• Discord Privacy Policy
• Supabase Privacy Policy
• Vercel Privacy Notice
• TibiaData Terms

External rank lookup and reservation submission to independently operated server authorities are not active today. If enabled, Tibia Claims may send the relevant server authority the minimum account, character, spawn, time, and request identifiers needed to evaluate a request, and may store the returned result and related operational history. Discord OAuth tokens, Supabase session credentials, and unrelated profile information will not be sent for that purpose.

Each server will publish its own rules separately. This policy will be updated before a new integration is enabled if its recipients, information, retention, or decision process differs materially from what is described here.

Account favourites remain until you remove them or the account data is deleted. Reminder choices remain with the related claim history. Pending or denied community contributions and their retained normalized evidence remain while needed for moderation and account status, while Analyzer previews expire after 15 minutes. A contribution screenshot is scheduled for removal after 20 days regardless of its decision; deletion of its contribution queues earlier removal of the exact private object. A non-image digest and bounded purge metadata may remain for duplicate prevention and audit. An accepted normalized observation and its moderation audit may remain as anonymous spawn evidence after the contributor link is removed. Notification-delivery rows may remain after delivery or permanent failure so the service can prevent duplicate processing, diagnose errors, and preserve operational accountability; routine cleanup may remove them later. Public board snapshots are cached briefly for live delivery and resilience. Session cookies remain until they expire, are replaced, or you sign out. Provider logs and analytics are retained under the applicable provider configuration and policy.

While an account is active, its profile, character associations and verification state, favourites, notification choices, ordinary group memberships, administrator access, native reservations, contribution state, and related security records may be kept as needed to provide and protect the service. Account-enforcement records retain the bounded actor and target snapshots, action, reason, affected-claim count, revision, and time for 30 days; rejected and rate-limited activity does not use a shorter period. If an account is permanently terminated for abuse, Tibia Claims retains only a backend-keyed cryptographic digest of its Discord ID and the termination time without expiry so the same Discord identity cannot register another website or Discord-only account. This tombstone contains no raw Discord ID, account profile, character, contribution, screenshot, or moderation reason. Final notification jobs and completed Discord interaction receipts are routinely eligible for deletion after 30 days, while processing rows are preserved until they reach a safe final state. Raw verification codes, public Comments, raw provider responses, full auction pages, service signing secrets, and Discord bot or interaction tokens are not retained in these records.

A fresh Discord role-catalogue observation is usable for no more than 10 minutes. Expired unmapped observations are removed by bounded cleanup; a selected mapping may retain its stable guild and role identity and bounded label history while the app group, configuration, or audit remains needed. A role-sync preview expires after five minutes and is removed after expiry or consumption. Tibia Claims does not retain Discord's raw member response, a full guild roster, or the account's complete role list. The current winning app-group association remains until a later confirmed sync replaces or removes it, the source/group is removed, or account deletion removes the live account link; minimized group, claim-decision, restriction, and administrator audit can remain where needed to explain prior actions.

If monitoring is enabled, raw provider responses and full world rosters are discarded immediately after the bounded target page is evaluated and are never persisted. Lease snapshots are cleared at completion or failure and abandoned snapshots only survive until lease expiry and safe cleanup. Current target and absence state is removed within 24 hours after the last eligible active claim ends. Routine sanitized observations and bounded attempt/failure metadata are kept for no more than 30 days; worker heartbeats and lag samples for no more than 14 days; and final no-show notification-outbox rows or future lifecycle/hold message intents for no more than 30 days. A pending item may remain only through its bounded delivery or finalization policy. Minimized evidence explaining a completed cancellation follows native claim-history retention and does not preserve a roster or presence timeline.

When self-service account deletion completes, Tibia Claims removes the Supabase login and current Discord profile association; active verified and unverified character assignments and challenges; favourites and alert choices; unsent reminders; current server-group memberships, strikes, BLACKLIST state, and unconsumed restriction previews; the current winning app-group association; every pending role-sync preview that references the account; Server Administrator access; and pending or denied community contributions with their private retained evidence. A retained role-source, mapping-audit, or still-retained account-enforcement row has its live account or actor link removed where applicable and cannot prevent deletion. Before monitoring can be activated, deletion must also disable and remove the account's current monitoring targets, presence state, routine observations, recipient identifiers, and pending monitoring messages. Active and future native claims are cancelled before access is removed, and no new notification is sent to the deleted account. Voluntary deletion does not create a terminated-identity tombstone; permanent abuse termination follows the separate security-retention rule above.

Deletion does not erase a global public Tibia character. Live account/server groups, strikes, and BLACKLIST are removed after affected native claims are reconciled. Previous accepted or cancelled claims retain a minimized public claim-time snapshot, and necessary detached security, administrator, restriction, ownership, and dispute evidence may remain where reasonably required; it is not retained as an active login profile.

Signing out is not account deletion, and removing one character is not account deletion. Deleting a Tibia Claims account does not delete data held independently by Discord, Tibia.com, the source game-server service, or another external authority. Backup, provider, and security-log copies may also take time to expire under their applicable retention schedules.

Depending on where you live, you may have rights to be informed; access and receive a copy of your personal information; correct it; request deletion or restriction; object to certain processing; receive portable data; withdraw consent; and complain to a data-protection authority. These rights can have lawful exceptions, and we may need to verify that a request concerns your account.

A signed-in user can use the Delete account section in Account info to review what will be removed, type the displayed confirmation phrase, and permanently delete the Tibia Claims account. A sufficiently recent verified session is required. The designated Super Administrator must first transfer platform control; ordinary Server Administrator access is revoked by deletion. Account deletion remains available even if you do not accept a newer Terms release.

For another privacy request or help with an account that cannot use self-service deletion, contact an administrator through the official Tibia Claims Discord server. Do not share passwords, character-verification codes, session tokens, or other secrets in a public Discord channel. Requests about data independently controlled by Discord or a game-server authority must also be directed to that service.

• Tibia Claims Discord support

We use access controls, encrypted network connections, input validation, firewall controls, traffic monitoring, and data minimization intended to protect the service. No online service can guarantee absolute security. Do not send credentials, OAuth tokens, session cookies, or other secrets through support channels.

We may update this policy as the service develops or legal and operational requirements change. Material new account, rank, claim, bot, partner, or database processing will be described before it is enabled. The effective date and version at the top identify the release. When a material change is included in a new legal release, authenticated website and Discord features may ask you to review the documents and expressly accept that release before continuing.