How to Export a Customer’s Data

When a customer asks for a copy of everything you hold on them — under GDPR Article 15 (right of access) or Article 20 (data portability), or simply because they want a record — you can generate that export yourself from Settings → Privacy, without filing a ticket with engineering. This article walks through requesting an export, reading the scope preview and its warnings, submitting the request with a reason, tracking it through to ready, and downloading the resulting ZIP.

This is the disclosure counterpart to right to be forgotten: where erasure deletes a customer’s data, export packages it up so the customer (or you, on their behalf) can keep a copy. The two features share the same scope-resolution logic, so a customer’s export and their eventual erasure cover the same ground.

Who can do this

Requesting, cancelling, and downloading exports requires the privacy.manage permission. If you don’t see the export option in Settings → Privacy, you don’t hold this permission — ask an owner to run the request or to grant it to you.

Every export action — creating a request, downloading a part, cancelling a build, or an export being purged — is written as a privacy_export security/audit event. There is no way to touch an export request without it being logged against your account.

Step 1: Enter the subject

Unlike erasure, which always starts from an existing customer record, an export request can be started with whatever identifier you have on hand:

1. Go to Settings → Privacy → Data Export Requests.
2. Start a new export request and enter the subject: a picked contact, or a raw email address, or a raw phone number.
3. Atender resolves the subject the same way it resolves identity for erasure — a raw email or phone is matched tolerantly (case-insensitively for email, normalized for phone) against every contact address on file, so it doesn’t matter whether you have the contact record open or just the string the customer gave you.

Step 2: Review the scope preview and warnings

Once the subject resolves, Atender computes the frozen export scope — every disclosure category (conversations, messages, attachments, call recordings and metadata, CSAT responses, form submissions, order and invitation records tied to the subject, and any other linked customer data) along with a byte total for each.

Before you submit, review:

• Scope breakdown by category — confirm you’re exporting the right person, especially if the contact has multiple channels or merged identities.
• Size warnings — a large export is split into multiple parts rather than being capped or truncated, so nothing is silently dropped for being too big. A size warning tells you roughly how many parts to expect, not that anything will be left out.
• Anything the export cannot include will show up later as an exclusion on the finished request (see Step 4) — the preview does not enumerate exclusions in advance, since some of them (an already-expired recording, an unreachable attachment URL) can only be discovered while the export is being built.

Step 3: Submit with a reason

Confirming the request requires you to enter a reason — a short note on why the export is being generated (a customer’s access request, a portability request ahead of migrating providers, and so on). This reason is stored on the request and is part of what’s logged as the privacy_export audit event, so anyone reviewing the audit trail later can see not just who requested an export but why.

Once submitted, the request is queued for building and you’re returned to the export requests list, where you can track it.

Step 4: Track the request through to ready

Each export request moves through a small set of statuses:

• Pending — the request has been accepted and is waiting for a build slot.
• Building — the export is actively being assembled: categories are walked, ZIP parts are written, and any category that can’t be included is recorded as an exclusion.
• Ready — every part has been uploaded and the export is available to download. This is also the moment the export’s retention clock (its expires_at) is stamped — see Expiry and purging.
• Failed — the build could not complete after its retry attempts. A failed request leaves nothing behind in storage; any parts it had already uploaded are cleaned up as part of the failure.
• Cancelled — you (or another privacy.manage holder) stopped the request before it finished. Like a failed build, a cancelled request does not leave orphaned files behind — any partially uploaded parts are removed as part of cancelling.

If a request reaches ready with one or more exclusions, it still shows as ready — an incomplete-but-honest export is served rather than being blocked. Every request that has exclusions ships an EXCLUSIONS.md file inside the export explaining what was left out and why (an audio file already removed by retention, a recording that never finished hosting, an attachment URL that no longer resolves, or a category you switched off before submitting).

Step 5: Download the ZIP parts

Once a request is ready, its list entry exposes a download action per part. Downloads are served through an authenticated API route: you never receive a raw storage link, and each part is streamed to you rather than staged anywhere you could re-share it. For a large export, expect multiple parts rather than one giant archive — the split follows the plan you saw hinted at during the size warning in Step 2.

Every download is itself logged as a privacy_export audit event, so there’s a record of exactly who pulled which part and when.

Cancelling a request

You can cancel a request while it is pending or building. Cancelling stops the build, removes any parts already uploaded for that request, and marks the request cancelled. A cancelled request cannot be resumed — if the customer still needs the data, start a new request.

Expiry and purging

A ready export does not stay downloadable forever. Its expires_at is set the moment it becomes ready, and once that window passes, a purge pass removes the uploaded parts from storage and marks the request purged. If you still need the data after that point, request a new export rather than looking for the old one — an expired request has nothing left to download.

What gets logged

Because every export request touches customer data, each of the following is recorded as a privacy_export security/audit event: creating a request, the build reaching ready, a build failing, cancelling a request, downloading a part, and a request being purged. If you need to demonstrate to an auditor exactly who accessed a customer’s exported data and when, this is the trail to pull.