Your list has a lifecycle. Know the boundaries.

RefreshList uses uploaded content to assess records and map outcomes to original rows. The intended retention window is up to 30 days, with early deletion after processing stops. Automatic production enforcement is not yet activated in this private review. Provider retention is separate and is not controlled by the public demonstration timer.

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

Key points

Local files stay in your browser.
Workspace uploads are stored.
Delete stored files removes app-held objects.

Detailed explanation

Existing manual maintenance expires drafts and terminal jobs but does not establish an all-job maximum from upload time. Do not rely on that deadline here; delete real files after processing. Operational accounting is separate from stored list content.

Example

Deleting the homepage demonstration only clears its sample. A real list must be removed in the authenticated workspace after processing stops.

How RefreshList handles it

Eligible addresses go to the provider without surrounding columns. Deleting app-held input/results does not assert provider-side deletion.

Limitations

Sensitive production lists should wait for retention enforcement, provider terms, and access-control review.

Methodology and sources

Product behavior is described from the current RefreshList 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.