What customer data should an integration not copy?
Anything you could not justify holding if someone asked. Names, phone numbers and service addresses are usually necessary to match customers and route work. Full payment card details, bank information and government identifiers are not, and belong in the systems built to hold them. Recordings and transcripts deserve their own retention window. Requirements vary by state, so confirm specifics with counsel.
Copy what the work requires, not what the API returns
The path of least resistance is to store the whole payload because it was already in the response. That is how a reporting database ends up holding data nobody intended to collect and nobody knows is there.
A field-level allowlist inverts the default. You name the fields the integration needs, and everything else is dropped at ingest. The list is short, it is reviewable, and it is a concrete answer when someone asks what you hold.
Categories that deserve different handling
- Operational identifiers. Record ids, job numbers, timestamps. Low sensitivity, and the backbone of every join.
- Contact and location details. Name, phone, email, service address. Necessary for matching and routing; store them, restrict access to them.
- Payment instruments. Card and bank details should never be copied into a reporting system. Keep a vendor token or a reference at most.
- Recordings and transcripts. Sensitive by nature, often subject to consent rules that differ by state, and worth an explicit retention policy of their own.
- Free-text notes. The most underestimated field on this list. Technicians and dispatchers paste anything into notes, including gate codes, health details and card numbers read over the phone.
Retention is a design decision, not an oversight
Every class of data should have a stated window and a job that enforces it. Deleting on schedule is a feature, not a gap, and it reduces what a future incident can expose.
Consent and recording requirements in particular vary meaningfully by state and by the parties on the call, and they change. Speak with your own counsel about what applies to your locations rather than assuming a vendor default is sufficient. The engineering side supports whatever policy you set, including per-state handling, in the way we configure call analysis.
Controls that make the policy real
Redact at ingest with pattern matching for things that look like card or identifier numbers, especially in free-text fields where they should never have been. Restrict access to the sensitive tables separately from the reporting tables, so an analyst can compute revenue without reading customer notes. Keep an inventory of what you store, where it came from, and why.
Minimization also improves the AI work rather than limiting it. A model summarizing job outcomes does not need a card number to be useful, and keeping unnecessary data out of the pipeline reduces both risk and noise. That is how we approach data handling on every integration engagement.
Topics: privacy · PII · retention · data governance
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.