VitrinaAPI

Tratar datos personales y de salud

Qué datos de esta API son sensibles y qué obligaciones trae recibirlos.

Casi todo lo que lee esta API es un dato personal de alguien. Un nombre, un teléfono, un correo, la hora a la que alguien va a pasar por una sucursal. La ley chilena 21.719 regula ese tratamiento y rige desde diciembre de 2026. Esta página dice qué parte nos toca a nosotros y qué parte te toca a ti.

Esto no es asesoría legal

Es la descripción de lo que hace el sistema y de lo que trae aparejado usarlo. Las obligaciones concretas de tu organización dependen de qué hagas con los datos, y eso solo lo sabes tú.

Los dos papeles

El workspace es el responsable del tratamiento: son sus clientes, su base y sus decisiones sobre qué hacer con ellos. Vitrina es el encargado: trata esos datos por cuenta del workspace, bajo sus instrucciones y para prestarle el servicio.

Cuando tu integración lee la API con una credencial del workspace, actúa dentro de ese tratamiento. No eres un tercero que recibe una base de datos: eres una herramienta más del responsable.

Lo que saques de la API y lleves a otro sistema sí sale de nuestro perímetro. Ahí las obligaciones viajan contigo: seguridad, retención, derechos de las personas.

Qué está marcado como sensible

La ley 21.719 distingue los datos personales sensibles (artículo 2 g) y les pone un régimen más estricto. Los datos de salud y el perfil biológico están ahí, con reglas propias en el artículo 16 bis.

El contrato lo dice por operación. Cada operación del openapi.json que publicamos lleva la extensión x-vitrina-sensitive: true cuando lo que devuelve o recibe es un dato sensible:

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

Un dato de contacto ordinario no está marcado. Un contacto entero llega así:

{
  "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"]
  }
}

Nombre, correo, teléfono y comuna son datos personales, con todas las obligaciones que eso trae, pero no son sensibles. Qué sí lo está depende de tu vertical:

Ninguna operación está marcada como sensible. Un auto no es una persona, y lo que la API devuelve sobre él (marca, año, kilometraje, precio) no es un dato personal de nadie.

La excepción a vigilar está en los archivos. El expediente de una unidad guarda documentos de identidad de personas reales: la cédula de un consignante, un contrato firmado. Y el filename que alguien escribió suele traer el nombre de otra persona:

{
  "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 dice de quién es ese documento. El contrato no marca estas operaciones, y aun así son datos personales con todas las obligaciones de esta página. Está advertido en Expediente.

Qué hace el sistema por su cuenta

  • Un evento nunca lleva un dato sensible en el cuerpo. Aunque la suscripción pida «Incluir datos del recurso», un evento sobre un dato sensible llega siempre como aviso, con data_omitted: "sensitive". Para leerlo hay que llamar a la API con una credencial. Esa llamada pasa por los permisos, la visibilidad y el registro de accesos (Webhooks).
  • El permiso que abre la capa sensible es propio y no se hereda. El permiso de la capa de afuera no abre la de adentro; hay que pedirlo aparte. Y una credencial no puede repartirse a sí misma uno que no tenga (Autenticación, Scopes).
  • Cada lectura de un dato sensible queda registrada, con quién la hizo y cuándo. Ese registro es el que permite responder a una persona qué se hizo con sus datos.
  • Una aplicación conectada no alcanza la capa sensible, ni por MCP ni por la API. El perfil del conector no incluye ninguna de esas herramientas: no es que respondan que no, es que no existen (MCP).

Y si la misma credencial llama la operación directamente, recibe 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" } }

La marca del contrato es la que decide. Una operación marcada queda cerrada para una aplicación conectada desde el día en que existe, esté publicada o no.

Qué te toca a ti

Si tu integración saca datos personales de esta API y los guarda en otro sistema:

  1. Ten una razón. El tratamiento necesita una base de licitud. Para un dato sensible el estándar es más alto: consentimiento expreso, salvo las excepciones del artículo 16 bis.
  2. Saca solo lo que necesitas. Pide los permisos mínimos que alcancen para el trabajo.
  3. Guarda el id y no la copia entera. El modo por defecto de los eventos es el aviso con una url, y existe para esto. Tu sistema guarda la referencia y lee el dato cuando lo necesita, en vez de acumular una segunda copia de la base.
  4. Ten un plazo de retención y cúmplelo. Un dato que ya no necesitas es riesgo sin contraparte.
  5. Ten cómo borrar. Cuando una persona ejerce su derecho de supresión frente al workspace, el workspace tiene que poder cumplirlo también en tu sistema.
  6. Cifra en reposo y en tránsito. No dejes datos personales en los logs de depuración ni en mensajes de error que se van a un tercero.
  7. Avisa rápido si algo se filtra. La notificación de brechas tiene plazos, y el workspace no puede cumplirlos si se entera tarde.

Cómo ve a las personas una aplicación conectada

Una aplicación conectada es un asistente o un cliente que alguien del workspace autorizó por OAuth. No es el workspace: es un tercero al que el workspace le abrió una puerta. Qué ve de las personas depende de la vertical:

Ve los contactos como los ve el miembro que la autorizó, dentro de sus scopes: nombre, teléfono, correo. Son datos personales ordinarios, y las obligaciones de «Qué te toca a ti» viajan con ellos igual.

Una API key del workspace o un token personal no pasan por esto: actúan dentro del tratamiento del workspace, como una herramienta más suya.

Qué permisos tocan datos sensibles y quién los lleva está en Scopes.

En esta página