Data, Privacy and Uninstall

A help desk collects names, email addresses, order questions and the occasional screenshot with a license key in it. Sooner or later someone asks where that data sits, who can read it, how long you keep it and what happens if you remove the plugin.

Core Support keeps tickets, customers and mail on your own site, and it sends no usage statistics or telemetry. The only call home is the license and update check. Anything else leaves the site only through a service you connect yourself.

What Leaves Your Site

The license and update check. When you activate a license, Core Support sends the license key, the product ID, your site address and the plugin, WordPress and PHP versions to the store at gauravtiwari.org. It calls again when you deactivate the license and when WordPress checks for updates. Nothing is sent before you enter a key, and update packages download over HTTPS from the store or its Cloudflare R2 storage. The store’s privacy policy covers that data.

Services you connect. Each one stays off until an administrator sets it up:

• AI providers (OpenAI, Anthropic, xAI, DeepSeek, and Voyage AI for search) receive Chat questions with the doc passages used to answer them, unanswered questions when summaries are on, and a ticket’s public conversation when an agent uses Draft with AI. Private notes never go to them. A daily check reads each provider’s model list with your key.
• OpenAI’s moderation check receives visitor messages when Screen messages for abuse is on and an OpenAI key is saved.
• Your mail provider (Emailit, Resend, Brevo or SendGrid) or WordPress mail receives the emails it delivers, team emails included. Your IMAP mailbox is read for replies.
• Team alerts (Telegram, Pushover, Discord, Slack or a webhook) receive the ticket number and subject with the customer’s name and email, and a roadmap suggestion’s title. With previews on, they also get the first 280 characters of the message, a webhook gets all of it, and suggestions add the suggester’s name, email and details.
• An AI assistant you connect through Site Agent receives what it asks for, as the account you connect with: new tickets, customer replies and feature requests with their names and email addresses, plus message text when previews are on. Reading a single ticket returns its latest messages and internal notes.
• File storage (Cloudflare R2, Amazon S3 or another S3-compatible service, or Bunny Storage) receives ticket attachments.
• Akismet receives the name, email, subject and message of each ticket from the form for visitors without an account, when the Akismet plugin is active with a key.
• Changelog sync and the docs importer read from GitHub, GitLab, Bitbucket, Gitea or Forgejo, and from addresses an administrator enters. They send nothing about your customers.
• Help desk imports read from Zendesk, Freshdesk or Intercom with the credentials a manager saves on Core Support → Import. They call those services only while a connection check or an import the manager started runs, and send nothing but those read requests. Attachments and inline images are downloaded from the addresses those services give, and a CSV tickets file’s attachments from the https:// addresses in the file.

WordPress adds your site address and WordPress version to the user-agent of every outbound request, so each service can see which site is calling.

Where the Data Lives

Core Support uses its own database tables, all starting with your table prefix and csp_:

• Tickets: csp_tickets, csp_messages, csp_attachments, csp_outbox (customer email queue) and csp_reply_tokens
• Incoming mail: csp_receipts and csp_inbound_deliveries
• Chat: csp_chat_threads, csp_chat_messages, csp_chat_chunks (learned passages) and csp_chat_faqs
• Docs reader signals: csp_doc_signals
• Customers: csp_customers, csp_customer_emails, csp_customer_sources (what each source said), csp_customer_meta (custom field values), csp_customer_orders, csp_ticket_orders and csp_customer_erasures
• Background jobs and imports: csp_jobs and csp_import_map (which local record each imported record became)

Customer records are read from FluentCart, WooCommerce, Easy Digital Downloads and FluentCRM on the same site, and from imports. Nothing is written back to those plugins.

It also keeps:

• Options starting with core_support_, plus csp_license for the license and short-lived sign-in and rate-limit records starting with csp_.
• Posts: docs (csp_doc) in collections (csp_collection), and changelogs (csp_changelog). Learned Chat state sits in post meta starting with _csp_chat_.
• User meta for per-person state: the newest ticket each agent has seen (core_support_tickets_seen) and an account’s confirmed email address (core_support_verified_email). Versions 1.1.1 to 1.1.4 also stored core_support_docs_guide_hidden for people who hid the Docs list guide; the guide is gone, and uninstall removes it.
• Roles and capabilities: the Support Agent (core_support_agent) and Support Manager (core_support_manager) roles and the core_support_work_tickets and core_support_manage capabilities.
• Cookies: one for each roadmap visitor’s reactions, and one for demo sessions while demo mode is on.
• Files, when you move them out of the database: wp-content/uploads/core-support-private, or your R2, S3 or Bunny bucket under the core-support/site-<blog-id>/ folder by default.

What Is Encrypted

Core Support encrypts with the PHP sodium extension, using keys derived from the site’s AUTH_KEY and AUTH_SALT.

• Saved credentials: the license key, IMAP passwords, relay secrets, automation tokens, storage keys, mail provider and Chat API keys, alert tokens and webhooks. Zendesk, Freshdesk and Intercom import credentials are encrypted the same way.
• Uploaded CSV files: kept in wp-content/uploads/core-support-private until their import finishes, then deleted.
• Email originals: the full raw copy of every incoming email.
• Attachments and inline images: always in the database and in private local files. In a bucket or Bunny zone too, unless you turn off Encrypt files before upload.

Ticket conversations themselves are ordinary database rows. Subjects, message text, customer names and email addresses are readable by anyone with database access, and they are in every database backup.

What Is Stored Only as a Hash

These values are never stored in readable form, so a database copy can’t be used to sign in or post as someone:

• Reply tokens in customer emails, which also expire after 90 days.
• Connected site keys.
• Portal sign-in codes and sessions on connected sites. Codes last 15 minutes and sessions 30 days.
• Chat conversation tokens. A visitor’s conversation belongs to whoever holds the token.
• Docs readers: “Was this helpful?” votes and failed searches are tied to a hash of the visitor’s address that changes every day. The address itself is never stored.

Your Site Salts Are Part of the Data

The encryption keys and most of these hashes come from AUTH_KEY and AUTH_SALT. If those change, for example after a security plugin rotates them or a migration writes new ones:

• saved credentials can’t be decrypted, so each connection needs its password, key or token entered again
• email originals and encrypted attachments can no longer be opened
• reply links in emails already sent stop matching their tickets, so replies wait in Incoming mail
• connected site keys stop working and need to be issued again
• portal sessions on connected sites end

I’d treat wp-config.php as part of the support backup. A database backup restored next to new salts brings back tickets you can read and attachments you can’t.

What Core Support Deletes on Its Own

• Chat conversations: after the retention period, 180 days by default. Keep conversations for accepts 0 to 3650 days, and 0 keeps them until deleted. A daily job removes up to 200 expired conversations each run.
• Docs reader signals: votes, comments and failed searches older than 365 days.
• Expired security records: portal sign-in codes and rate-limit counters.

Tickets, messages, incoming mail receipts, attachments and customer records are kept with no automatic deletion. Discard on Incoming mail marks a message as Discarded and keeps the row.

Privacy Export and Erase

Core Support registers with WordPress’s own tools under Tools → Export Personal Data and Tools → Erase Personal Data:

• Support tickets: the export lists every ticket opened with the address, with its number, subject, status, opening date and public conversation. Private notes stay out. Email received from the address follows under “Support email received”.
• Support chat conversations: a conversation handed to a person with an email address is included in the export, and the erase removes it.
• Roadmap feature requests: suggestions sent with the address are exported. The erase removes the sender’s name and address, so each request stays on the roadmap as an idea, and removes their reactions when they have an account.
• Support customer record: the export lists the customer ID, every address and the details and custom field values. It also lists what each source said, with when it last updated, and each linked order with its number, status, total and date. The erase deletes the customer record with its addresses, sources, custom fields and order links.

The erase keeps each ticket and the team’s replies, including replies imported from another help desk, so the history still reads. It removes the customer’s side:

• their name, which becomes “Deleted customer”, and their email address, so the ticket leaves their portal
• the subject, which becomes “Ticket #” and the ticket number
• their own messages, replaced with “[Removed at the customer’s request]”, and the files attached to them
• email they sent to the help desk, including the original and its attachments
• reply links and queued emails addressed to them

Anonymous Chat visitors are not tied to any email address until they hand off, so there’s nothing to export for them.

After erasing a customer, Core Support keeps a SHA-256 hash of each address they had, with the time of the erasure. A sync or import of data from before that time never adds the person again. A new ticket or order after it makes them a customer again.

Deactivating Core Support

Deactivating keeps every ticket, setting and file. It only stops the scheduled jobs: mail processing, changelog sync, the Chat checks, refreshes and cleanup, the hourly customer sync and any running sync or import. Activate the plugin again and everything continues, unfinished jobs included.

Deleting Core Support

By default, deleting Core Support from Plugins removes only its files. Every table, setting, post, role and stored file stays in place, so a reinstall picks up where you left off.

One setting changes that:

• Delete all Core Support data when the plugin is deleted: under Core Support → Settings → Data. Off by default. When on, deleting the plugin from Plugins removes its data on this site.

With the setting on, deletion removes:

• every Core Support table listed above
• its settings and saved state: options and transients starting with core_support_, and csp_license
• docs and changelogs with their revisions and comments, and the collections
• what Chat learned about other posts, and other Core Support post meta starting with _csp_
• attachments in wp-content/uploads/core-support-private
• the Support Agent and Support Manager roles, and Core Support’s capabilities on the administrator and editor roles
• its scheduled tasks

If Use the support page as the site homepage is still on, the previous homepage comes back. The Support page itself stays as an ordinary page, which you can delete under Pages.

To remove everything for good:

1. Export any docs and changelogs you want to keep. They are your content.
2. Give Support Agents and Support Managers another role, because removing the roles leaves them with none.
3. Take a full backup of the database and wp-content/uploads.
4. Turn on Delete all Core Support data when the plugin is deleted and choose Save settings.
5. Deactivate and delete Core Support from Plugins.

Files in an R2, S3 or Bunny bucket stay there, under the core-support/site-<blog-id>/ folder by default. Delete them in the provider’s dashboard. On multisite, each site’s own Data setting decides what happens to that site’s data.

wp-config Constants shows how to keep credentials out of the database in the first place.