---
id: KB-IN-012
url: https://app.codecontract.io/help/integrations/what-data-leaves-when-you-integrate
idioma: en
categoria: integraciones
audiencia: administrador
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-003, KB-IN-011]
citadoPor: [KB-IN-015]
---

# What data leaves when you integrate

_An integration opens a door. Worth knowing what fits through before opening it._

**Responde a:** what data does an integration share · security of an integration with another system · limiting what an access key can read · risks of connecting two platforms

An integration is not just a convenience: it is a route by which information leaves here and enters somewhere else with its own rules, its own access controls and its own backups. Decide deliberately what goes through it.

## The three questions before connecting

1. **What can that connection read?** — The minimum its case needs, not everything for convenience.
2. **Where does what leaves end up?** — If the other system is in another country or run by a third party, your obligations change.
3. **Who can use that key?** — A key circulating in a team chat is no longer a key.

> [!IMPORTANT]
> The second is most often forgotten and has consequences beyond the technical. Personal data leaving for another system remains your responsibility, even if the problem happens there.

## What is better left in

| Data | Why |
| --- | --- |
| Full documents, when status suffices | Almost no ERP needs the PDF: it needs to know whether it is current |
| Personal data the other system does not use | If it does not use it, it only adds risk |
| The whole history, when only live matters | Closed material is rarely consulted from outside |

> [!WARNING]
> The first row prevents half of all integration problems. "This supplier is current / is missing insurance" is a sentence; sending the insurance PDF is exporting documentation to a system that may not protect it the same way.

## How to look after an access key

**En corto**

- One key per integration, not one shared for everything.
- With the lowest permission that works.
- Stored where passwords are stored, not in a document or a chat.
- And revocable in a minute, knowing who was using it.

That last point is what you need on the bad day. If you do not know which integration uses which key, revoking as a precaution breaks something and nobody knows what.

> [!NOTE]
> Everything an integration does lands in the activity log just like what a person does. If something leaves here, you can find out when and by which route.

**Can it be limited to read-only?**

Yes, and for most cases that is the right choice.

**What if the other platform's vendor changes?**

Revoke and issue a new key; hence one per integration.

**Do we need a contract with the other vendor?**

If they will process your personal data, yes. Not optional.

## Ejemplos

**A company wants to dump all supplier documentation into its ERP.**

- Sends only document status and expiry date
- Issues a read-only key for that integration

→ The ERP shows what purchasing needs and no document leaves the platform.

**Integration goes live and more data leaves than was needed.**

- Limits the integration to the fields that get used

→ What travels is only what is necessary.

**A client asks what data of theirs goes to another system.**

- Checks which fields the integration includes

→ The answer is specific and verifiable.

**Personal data leaves without anyone deciding it.**

- Reviews the content with the adviser before enabling

→ The decision is taken beforehand rather than after.

**The data lands in a system with weaker access control.**

- Checks who will see that data on the other side

→ Protection does not drop along the way.

**Nobody knows what went out last month.**

- Checks the call log

→ What was sent is auditable.