Both actions live under Settings → Account, and both are owner-only. Admins and editors see a notice explaining that only the workspace owner can export or delete.

Export everything

Export my data downloads one JSON file containing what the workspace holds:

• the workspace record (name, slug, plan, subscription status, created date);
• connected Instagram accounts — without any token material;
• connected integrations — never the key itself, which nobody can read back once saved;
• contacts, tags, contact–tag assignments, and contact identities;
• messages and their attachments;
• automations;
• forms and form responses;
• short links;
• media assets.

Each section carries a truncated flag. It's false in every normal case; a workspace large enough to pass the per-table export ceiling gets an honest true rather than a silently short file.

This is the GDPR Article 20 (portability) route. It's a dashboard download — it is deliberately not reachable with a personal access token, because the file contains every contact's messages and form answers, and a leaked token must not be able to pull it.

Erase one contact

When one of your fans asks you to delete what you hold about them (a GDPR Article 17 request, where you are the controller), you can erase that one contact without touching the rest of the workspace. This takes the admin role and is available through the API, the CLI and the local MCP server:

• DELETE /api/contacts/:id
• big contact:delete <contactId>
• big_contact_delete (local MCP, requires confirm: true)

Erasing a contact deletes it together with everything that names that person: their DM history, identities (email, Instagram handle claims), tags and lead state, their form responses, any DM still queued to them, and their comments on your posts. A contact.erased entry goes in the workspace audit log with counts only, never the person's details. It cannot be undone.

One thing is kept on purpose: if the person is on your automation whitelist, that entry stays, because it is what stops your automations messaging them again.

The remote MCP server (/api/mcp) has no erase tool, as with every permanent delete.

What big records about your API tokens

Separately from the export above, big keeps a small usage record for every personal access token and remote-MCP grant, so we can see which tokens are active and which surfaces are worth investing in. Two things are stored:

• Last used. A single timestamp on the token itself, shown beside it in Settings → API tokens. It is overwritten on every call, so it tells you a token is alive, not what it has done.
• A daily call tally. One row per token per day per surface per client, holding a count. "This token made 214 calls to the contacts endpoint on 14 August, from the CLI" — nothing finer. It is a running total, not a log of individual requests, so there is no way to reconstruct one call from it.

What that tally does not hold: the token value or its hash, IP addresses, request bodies, query strings, the names of the contacts or forms you touched, or anything else about the people in your workspace. The client field is the X-Big-Client hint the caller sent — cli, mcp-local, mcp-remote, sdk, or unknown when it sent nothing.

It is kept for 200 days and then deleted automatically. It is also erased sooner in two ways: deleting a token removes its tallies with it (revoking one does not — a revoked token's history stays readable to us), and deleting the account below erases all of it along with everything else.

It is not included in the export file above, which covers workspace content rather than operational counters. Ask support if you want your workspace's tallies and we will send them.

Integration keys you give big

When a workspace admin connects an integration, big stores a credential so it can call that tool on the workspace's behalf: an API key the admin pastes (Calendly, Discord), or a sign-in token the tool issues when the admin approves big's read-only access, for an integration your workspace has been set up for. Integration security has the full detail; the parts that concern your data are:

• What is stored. The key or the sign-in tokens, encrypted; which provider it's for; the label you gave it; the account it belongs to on the tool's side, as the tool reported it when big checked it (its account id and its account name or label); for a pasted key, its last 4 characters and a short fingerprint so you can tell keys apart; and when it was connected, last checked and last used. For most tools nothing else about the tool's account is kept: big reads from the tool only when your own AI agent asks, and doesn't copy its data into big An integration your workspace has been set up for to feed client records is the exception: a meeting tool imports call transcripts, attendee names and emails, and AI summaries; a file store keeps the text of the documents in the folders shared with big; a calendar imports the times of events your clients attend and which clients are on them. Raw copies of transcript files and of file text are kept in private storage. Disconnecting the integration deletes all of it, and a file store's documents are deleted once they leave a folder shared with big
• Nobody can read a key or token back. Not you, not your admins, not big staff. No screen, API, CLI command or MCP tool returns one.
• Google Cloud is a sub-processor for pasted keys and sign-in refresh tokens only. Each pasted key, and each refresh token a tool issues when you approve big, is encrypted with its own key, and that key is itself encrypted ("wrapped") by a master key held in Google Cloud KMS hardware. To wrap and unwrap it, Google Cloud KMS receives that key itself, along with internal ids (the workspace's and the integration's, and the provider's or the connection version's) that bind it to this one connection. It never receives your API key or refresh token, nor the encrypted copy of either, nor any of your workspace content. So Google Cloud alone can't decrypt anything, and neither can big's database alone.
• Short-lived access tokens don't involve Google Cloud. They are encrypted with big's own token key, which lives only in big's production environment. Sign-in tokens of both kinds are kept in a separate table that big's application code can't read directly.
• Disconnecting deletes the credential from big's live database immediately. A small record (provider, label, account, dates, a key's fingerprint) stays for your workspace's audit history and is deleted with the workspace.
• Backups. big's database backups let us restore the database to a point in the past for a limited window, so a deleted key or token still exists, encrypted, inside those backups until that window has passed. Contact us for its current length. Only big's production service holds what it takes to decrypt it, and after the window it is gone from backups too.
• Deleting big's copy doesn't invalidate it at the tool. An API key is created and revoked in the tool that issued it, so after you disconnect or rotate, delete the old key in that tool too. Disconnecting a tool you signed in to asks the tool to revoke big's access where it can.

Delete the account

The Danger zone deletes the whole workspace. You have to type the workspace name exactly to confirm, and that's re-checked on the server, so the confirmation can't be skipped.

What happens, in order:

1. Your subscription is cancelled first. If cancelling fails, nothing is deleted — you'll be told to retry or contact support. Deleting the data while billing kept running would be the worst outcome, so it's the first step and it's allowed to abort the rest.
2. Uploaded files are purged from storage. If the purge is cut short (a very large workspace, or the storage provider fails), big records the leftover files and keeps retrying the purge in the background until they are gone. The deletion itself still goes ahead.
3. The workspace is deleted, and everything scoped to it goes with it: connections, integrations and their stored keys, contacts, messages, automations, forms, links, tokens, and memberships. Your public link pages go offline straight away, and their handles become free to claim. big can't revoke integration keys at the tool that issued them, so delete those keys there too.
4. Your login is deleted only if this was your last workspace. If you belong to other workspaces, you keep your account and your access to them. Other members' logins are never touched — only their membership of this workspace disappears.

Your Stripe customer record and past invoices are kept. Invoices are retained for tax and accounting obligations; they're no longer linked to a live workspace.

This is the GDPR Article 17 (erasure) route, it is irreversible, and — like the export — it is owner-only and unreachable with a personal access token.

One thing it does not cover: the product-update mailing list. If you're on it — you joined it through the waitlist, before sign-up opened to everyone — your address sits with Resend, the email provider big sends through, rather than in the workspace. So it is not in the export above, and deleting the account does not take it off the list. Use the unsubscribe link in any product-update email, or write to [email protected] to have the address removed. See Product updates.

Related

• Billing — cancel a subscription without deleting anything.
• Team & roles — who can do what.
• Integration security — how integration keys are stored and deleted.
• Product updates — the mailing list, and how to leave it.