Keep the verification state, not a copy of the mailbox
Ask a team what their verification tool left behind and the honest answer is usually a warehouse table with an email column and a green checkmark. That table is now a second database, with no owner, no timestamp and no expiry policy - and it will outlive the tool that produced it.
The stored copy is the liability, not the check
A check is a fact. A stored copy of a check is a claim about the present tense that was written in the past tense. The gap between those two things is measurable:
| Observation | Number | Source |
|---|---|---|
| Contacts who change jobs in a year | 23% | ZoomInfo, 2025 |
| Addresses dead within 2 years | 40% | NeverBounce |
| Advantage of fresh data over stored data | +42% | Harvard Business Review, 2024 |
Every one of those numbers is a reason the row you stored is not the row you have. And the row you stored is the one your sequence will actually use.
Three fields worth keeping
Retention is not about keeping less for its own sake. It is about keeping the part that stays true and stamping the part that does not:
- The state -
valid,invalidorunknown. Not "has email", which is a checkbox nobody can act on. - The moment it was checked. A state without a date is a rumour; with a date it is an auditable fact you can re-verify on a schedule.
- Where the address came from - the page or profile it was found on. Provenance is what lets a human sanity-check a row without re-running the whole search.
Everything else the verifier handed you is payload. A score with no scale, a "quality" flag, a provider-specific code - if your team does not branch on it, it is another field to defend in a review.
A retention policy you can write in one table
| What | Keep it? | Why |
|---|---|---|
| Verified state + check timestamp | Yes, until re-checked | It is the thing your sending logic branches on |
| Source URL / page the address came from | Yes | Makes every row auditable by a human |
| Raw provider response / payload blob | No | Nobody reads it, and it is the largest part of the copy |
| Bulk export "for the archive" | No | A stale export becomes the file people work from |
| Suppression list (invalid + unsubscribed) | Yes, indefinitely | The only data where "old" is the point |
Erasure requests land on the copy
Say a contact asks you to delete their data. If your answer is "we never stored it - we looked it up at the moment we needed it", the request takes one line of work. If your answer is "it is in the enrichment table, the CRM, the export and the sending tool", you are now doing archaeology across four systems that all disagree about what the person's address is.
How TAPAC returns a result
TAPAC verifies inside the search request. Each contact comes back with the address, the source it was found in, and its SMTP state as of that call. There is no stored mailbox on our side to go stale, and no bulk file to keep in sync - the state you receive is yours to store, stamped and dated.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status # or hosted: https://tapacapi.com/mcp # or REST: POST https://tapacapi.com/v1/contacts/search
100 free searches to start, then $0.10-0.50 per verified contact, pay-per-use. You pay for the lookups you make, not for a copy of the database you then have to look after.
← Back to TAPAC