Handle personal and health data

Almost everything this API reads is somebody's personal data. A name, a phone number, an email address, the time a person is due at one of your locations. Chile's personal-data law, Ley 21.719, governs that processing and has been in force since December 2026. This page says which part of it is ours and which part is yours.

This is not legal advice

It is a description of what the system does and of what using it brings with it. Your organisation's concrete obligations depend on what you do with the data, and only you know that.

The two roles

The workspace is the responsable, the controller of the processing. The customers are the workspace's, so is the database, and so are the decisions about what to do with them. Vitrina is the encargado, the processor: it handles that data on the workspace's behalf, under its instructions, to provide it the service.

When your integration reads the API with a credential of the workspace, it acts inside that processing. You aren't a third party receiving a database: you're one more tool of the controller.

What you take out of the API and carry to another system does leave our perimeter. There the obligations travel with you: security, retention, people's rights.

What is marked sensitive

Ley 21.719 singles out sensitive personal data in its artículo 2 g) and holds it to a stricter regime. Health data and the biological profile are in there, with rules of their own in artículo 16 bis.

The contract says so operation by operation. Every operation in the openapi.json we publish carries the x-vitrina-sensitive: true extension when what it returns or receives is sensitive data:

{
  "x-vitrina-tier": "interna",
  "x-vitrina-sensitive": true
}

An ordinary contact detail is not marked. A whole contact arrives like this:

{
  "data": {
    "id": "5f3a9c1e-2b7d-4e8a-9c0f-1d2e3f4a5b6c",
    "external_id": null,
    "name": "María González",
    "email": "[email protected]",
    "phone": "+56912345678",
    "lifecycle_stage": "prospect",
    "job_title": "Gerente de operaciones",
    "company_id": "9a1b2c3d-4e5f-4a6b-8c7d-8e9f0a1b2c3d",
    "origin_channel": "manual",
    "email_consent": false,
    "email_status": "subscribed",
    "merged_into_contact_id": null,
    "created_at": "2026-09-21T14:03:11.000Z",
    "display_name": "María González",
    "named": true,
    "channels": ["whatsapp"],
    "lead_sources": ["website"]
  }
}

Name, email, phone and comuna are personal data, with every obligation that brings, but they aren't sensitive. What is depends on your vertical:

No operation is marked sensitive. A car isn't a person, and what the API returns about one (make, year, mileage, price) is nobody's personal data.

The exception to watch is in the files. A unit's vehicle file holds identity documents of real people: a consignor's ID card, a signed contract. And the filename somebody typed usually carries somebody else's name:

{
  "data": [
    {
      "id": "b0f998b5-eb80-42ea-be16-8356dbbd0643",
      "tenant_id": "00000000-0000-4000-8000-000000000001",
      "vehicle_id": "5d00f5cf-ebe3-4e8b-a456-8d783daed0be",
      "kind": "cedula",
      "storage_bucket": "vehicle-registry",
      "storage_path": "00000000-…/5d00f5cf-…/1fee60f8-…-cedula_consignante.pdf",
      "filename": "cedula_consignante.pdf",
      "mime_type": "application/pdf",
      "byte_size": 610,
      "subject_contact_id": "01a0c68e-4a0c-7bb4-888d-2cd0c3b5ff25",
      "uploaded_by": "20000000-0000-4000-8000-000000000001",
      "uploaded_at": "2026-09-22T00:40:34.958Z",
      "created_at": "2026-09-22T00:40:34.958Z"
    },
    {
      "id": "44173198-bd20-40ea-b08d-8f36dbf5c5df",
      "tenant_id": "00000000-0000-4000-8000-000000000001",
      "vehicle_id": "5d00f5cf-ebe3-4e8b-a456-8d783daed0be",
      "kind": "padron",
      "storage_bucket": "vehicle-registry",
      "storage_path": "00000000-…/5d00f5cf-…/a0d1a414-…-padron_RJKL48.pdf",
      "filename": "padron_RJKL48.pdf",
      "mime_type": "application/pdf",
      "byte_size": 610,
      "subject_contact_id": null,
      "uploaded_by": "20000000-0000-4000-8000-000000000001",
      "uploaded_at": "2026-09-22T00:37:29.063Z",
      "created_at": "2026-09-22T00:37:29.063Z"
    }
  ]
}

subject_contact_id says whose document it is. The contract doesn't mark these operations, and they're personal data all the same, with every obligation on this page. Vehicle file warns about it.

What the system does on its own

An event never carries sensitive data in its body. Even when the subscription asks for "Incluir datos del recurso", an event about sensitive data always arrives as the notice, with data_omitted: "sensitive". Reading it means calling the API with a credential. That call goes through the permissions, the visibility and the access log (Webhooks).
The permission that opens the sensitive layer is its own, and it isn't inherited. The permission for the outer layer doesn't open the inner one; it has to be asked for separately. And a credential can't hand itself one it doesn't hold (Authentication, Scopes).
Every read of sensitive data is logged, with who did it and when. That log is what makes it possible to tell a person what was done with their data.
A connected application doesn't reach the sensitive layer, over MCP or over the API. The connector profile includes none of those tools: it isn't that they answer no, it's that they don't exist (MCP).

And if the same credential calls the operation directly, it gets 403 CONNECTED_APP_SENSITIVE_DATA:

{ "error": { "code": "CONNECTED_APP_SENSITIVE_DATA", "message": "Esta operación entrega datos personales sensibles (…). Una aplicación conectada no puede leerlos: úsala con una API key o un token personal del workspace, emitido para este fin. …", "requestId": "7d0b3c2e-5a41-4f7e-9c11-2b8e6f0a4d93" } }

The contract's mark is what decides. A marked operation is closed to a connected application from the day it exists, published or not.

What is on you

If your integration takes personal data out of this API and stores it in another system:

Have a reason. The processing needs a lawful basis. For sensitive data the bar is higher: express consent, save for the exceptions in artículo 16 bis.
Take only what you need. Ask for the smallest set of permissions that does the job.
Store the id rather than the whole copy. The default mode for events is the notice with a url, and it exists for this. Your system keeps the reference and reads the data when it needs it, instead of accumulating a second copy of the database.
Have a retention period and keep to it. Data you no longer need is risk with nothing on the other side.
Have a way to delete. When a person exercises their right to erasure against the workspace, the workspace has to be able to honour it in your system too.
Encrypt at rest and in transit. Don't leave personal data in debug logs or in error messages that go off to a third party.
Raise the alarm quickly if something leaks. Breach notification runs to deadlines, and the workspace can't meet them if it hears late.

How a connected application sees people

A connected application is an assistant or a client somebody in the workspace authorised through OAuth. It isn't the workspace: it's a third party the workspace opened a door to. What it sees of people depends on the vertical:

It sees contacts as the member who authorised it sees them, within its scopes: name, phone, email. That's ordinary personal data, and the obligations in "What is on you" travel with it all the same.

A workspace API key or a personal token goes through none of this: they act inside the workspace's processing, as one more of its tools.

Which permissions touch sensitive data, and who carries them, is in Scopes.