---
title: "Data Handling: the complete lifecycle of your list | Refresh List"
description: "Refresh List explains what happens from upload to download in plain language. Your account data supports authentication and billing; your uploaded list supports the verification workflow you selected. Uploaded addresses are not sold or repackaged as an advertising audience."
url: https://refreshlist.net/data-handling
last_updated: 2026-10-09
---

[Refresh List](/) › Guide

FIELD GUIDE / LAST UPDATED 2026-09-14 

# Data Handling: the complete lifecycle of your list

Refresh List explains what happens from upload to download in plain language. Your account data supports authentication and billing; your uploaded list supports the verification workflow you selected. Uploaded addresses are not sold or repackaged as an advertising audience.

Last updated 2026-09-14. Read the scope and limitations before applying a result.

ON THIS PAGE [Key points](#points) [Detailed explanation](#detail) [Example](#example) [How Refresh List handles it](#handling) [Limitations](#limits) 

## Key points

- Choose the input carefully.

- Keep the provider handoff visible.

- Delete stored files when finished.

- Scheduled deletion eligibility.

## Detailed explanation

Before processing, your browser can inspect structure and duplicates locally. When you start a verification run, the selected input and job metadata are stored so the workspace can show progress, preserve File IDs, reconcile credits, and provide downloads. Eligible unique addresses are sent to the configured verification provider; surrounding spreadsheet columns are not required for that provider request. Returned statuses are mapped back to the original rows so you can reconcile the result with your source file.

## Example

A typical workflow is: upload a CSV, review the free preflight assessment, start verification, monitor progress, download the categorized results, and delete stored files after your team has the exports it needs. Duplicate rows remain connected to their original source rows, while completed valid, invalid, and unknown outcomes remain distinguishable.

## How Refresh List handles it

Uploaded drafts and completed, partial and failed lists become eligible for scheduled deletion 30 days after upload or their last update. Download results before then. You can delete stored files earlier after processing stops. Deletion removes app-held list objects and results; it does not automatically control a separate provider’s retention schedule. Account, payment, invoice, security, and support records may need to be retained for operational, accounting, fraud-prevention, or legal reasons.

## Limitations

Do not upload data you are not allowed to process. Keep passwords, API keys, card details, and complete lists out of support tickets. Use suppression and consent controls in your own sending workflow. Review the Privacy Policy for the complete legal description and contact support for a privacy or deletion request.

## Related topics

[Don’t ask for trust. Show the evidence.](/trust) [Security: controls and data boundaries](/security) [How Refresh List verifies—and its limits](/verification-methodology) [policies/privacy](/policies/privacy)

## Methodology and sources

Product behavior is described from the current Refresh List implementation and provider contract. Protocol context should be checked against the applicable standards and provider documentation. This page does not create a benchmark or certification.

## Sitemap

- [All Public Pages](https://refreshlist.net/sitemap.md)
- [Email Glossary](https://refreshlist.net/glossary)
- [Read This Page And Use Interactive Features](https://refreshlist.net/data-handling)