Skip to main content

Solicitudes de acceso del interesado (DSAR)

Una solicitud de acceso del interesado (también llamada solicitud de privacidad o solicitud de derechos del consumidor) es el mecanismo formal que una persona utiliza para ejercer sus derechos sobre los datos personales que usted conserva sobre ella: el derecho de acceso, supresión, corrección, portabilidad u oposición a la venta de esos datos. La mayoría de las leyes de privacidad le imponen un plazo estricto para responder (30 días según el GDPR, 45 según CCPA/CPRA). Orbit le ofrece dos vías de entrada y una canalización de cumplimiento:
  • DSAR presentada por el operador — su equipo de soporte o cumplimiento presenta una solicitud en nombre de un cliente a través de la API autenticada o del panel.
  • Portal público de autoservicio — el interesado presenta su propia solicitud mediante un flujo público y no autenticado que verifica su identidad con un OTP de dos factores por correo electrónico + SMS antes de poner nada en cola.
Esta página describe los controles de plataforma de Orbit. No es asesoramiento legal. Sus obligaciones — qué leyes se aplican, qué debe divulgar y cuánto tiempo tiene — dependen de dónde residan sus interesados y de qué datos procese. Confírmelo con asesoría legal cualificada.
Todos los endpoints siguientes tienen su raíz en https://api.orbit.devotel.io/api/v1/compliance.

Jurisdicciones admitidas y plazos

El campo applicable_jurisdiction de una solicitud controla qué reloj legal aplica el rastreador de SLA de Orbit. Los operadores pueden reclasificar una solicitud tras la entrada.

Tipos de solicitud

request_type describe lo que solicita el interesado. El conjunto completo de verbos de CCPA/CPRA está disponible para los operadores; el portal público expone un subconjunto más sencillo que se corresponde con él. Para las solicitudes de acceso CCPA también puede adjuntar consumer_categories: las categorías de CCPA §1798.100(b) sobre las que pregunta el interesado: identifiers, customer_records, protected_classifications, commercial, biometric, internet_activity, geolocation, sensory, professional, education, inferences, sensitive_pi.

Solicitudes presentadas por operadores

Crear una solicitud

POST /compliance/dsar — requiere una clave de API de administrador o propietario. Proporcione al menos un identificador del interesado (contact_id, subject_email o subject_phone) además del requester_email que debe recibir la correspondencia.
Devuelve 202 Accepted:
Notaapplicable_jurisdiction solo adopta el valor predeterminado gdpr para derechos que existen bajo el GDPR. Los tipos de solicitud opt_out_sale y limit_sensitive_pi son exclusivos de CCPA/CPRA y no tienen equivalente en el GDPR, por lo que debe establecer applicable_jurisdiction en ccpa o cpra explícitamente para ellos. Omitirlo (o dejar el valor predeterminado gdpr) se rechaza con 422 VALIDATION_ERROR.

Ciclo de vida del estado

Una solicitud atraviesa: receivedprocessingcompleted con las ramas terminales failed, expired y cancelled. El subestado de verificación se rastrea de forma independiente: pendingverified (el trabajador continúa) o rejected (el trabajador se detiene). Las filas presentadas por administradores/GDPR tienen el valor predeterminado not_required.

Verificar o rechazar la identidad

Las solicitudes de mayor garantía (delete, opt-out, limit-sensitive) requieren una decisión del operador antes de que prosiga el cumplimiento:
decision es verified o rejected; notes es opcional (≤ 2048 caracteres). Devuelve el nuevo verification_status y verified_at.

Cancelar una solicitud

POST /compliance/dsar/{id}/cancel retira una solicitud en curso (GDPR Art. 7(3)). Solo funciona mientras la solicitud está en received o processing; una solicitud terminal devuelve 409 Conflict.

Listar y leer solicitudes

  • GET /compliance/dsar — lista paginada. Consulta: page (≥ 1), page_size (≤ 100, valor predeterminado 25) y un filtro status opcional.
  • GET /compliance/dsar/{id} — obtiene una solicitud. La respuesta incluye la export_url firmada (y su export_expires_at) una vez producida una exportación de acceso/portabilidad, además de tables_exported, que describe los recuentos de filas por tabla.

Solicitudes de supresión

Las supresiones del GDPR Art. 17 se rastrean como un recurso propio, de modo que pueda auditar e intervenir antes de que se destruyan los datos:
  • GET /compliance/dsar/erasure-requests — lista. Consulta: status (pending, cancelled, executing, executed, failed) y limit (≤ 500).
  • POST /compliance/dsar/erasure-requests/{id}/cancel — cancela una supresión pendiente antes de que se ejecute. reason opcional (≤ 500 caracteres). Devuelve 409 si ya se está ejecutando o ha finalizado.

Panel de SLA

GET /compliance/dsar/sla devuelve una instantánea combinada del SLA de exportación + supresión para que nunca pierda un plazo legal:
Los niveles de severidad escalan proporcionalmente con la ventana de SLA de cada jurisdicción: los umbrales de días se anclan al caso GDPR de 30 días y se multiplican por la razón slaDays / 30, por lo que una solicitud siempre pasa a ámbar y rojo en la misma fracción de su propio plazo. escalation_due se activa 5 días antes del plazo legal (slaDays − 5). Para GDPR (sla_days: 30): verde (< 20 días transcurridos), ámbar (20–25), rojo (26–30), rojo + incumplimiento (> 30); escalation_due en el día 25. Para CCPA/CPRA (sla_days: 45) las mismas razones dan verde (< 30), ámbar (30–38), rojo (39–45), rojo + incumplimiento (> 45); escalation_due en el día 40. Lea siempre los límites de nivel contra el sla_days devuelto para esa solicitud, no contra los números fijos 20/25/30.

Portal público de autoservicio

El flujo público permite a un interesado presentar una solicitud sin una cuenta. La identidad se verifica con un OTP de dos factores — un código por correo electrónico y un código por SMS — antes de poner en cola cualquier solicitud. Los endpoints se encuentran bajo /compliance/public/dsar y no están autenticados, pero están protegidos por Cloudflare Turnstile, límites de tasa por IP y por identificador, y una forma de respuesta que preserva la privacidad y nunca revela si un par correo electrónico/teléfono coincide con un contacto real.
Los códigos de verificación por SMS se entregan a través del softswitch de Devotel (la única ruta de SMS saliente de la plataforma). Son OTP de plataforma, no tráfico facturable al tenant, y no conservan recibos de entrega.

Resumen del flujo

1

Inicio

POST /compliance/public/dsar/begin con email, phone (E.164), request_type (access | delete | portability | opt_out) y un turnstile_token de Cloudflare (obligatorio en producción). Devuelve un claim_id opaco, email_sent: true y expires_in: 600. Un OTP por correo electrónico se envía de inmediato.
2

Verificar correo electrónico

POST /compliance/public/dsar/verify-email con claim_id y el code de 6 dígitos. Devuelve el estado email_verified y el siguiente paso phone_send. Los códigos caducan a los 10 minutos; máximo 3 intentos. POST …/resend-email (con claim_id + email) emite un nuevo código, sujeto a un enfriamiento de 60 segundos.
3

Enviar código al teléfono

POST /compliance/public/dsar/send-phone con claim_id y el phone que coincide con el indicado en begin. Envía un OTP por SMS (expires_in: 600). Se aplica un enfriamiento de 60 segundos entre envíos; un reintento prematuro devuelve 429 con Retry-After.
4

Verificar teléfono

POST /compliance/public/dsar/verify-phone con claim_id y el code de 6 dígitos. Devuelve el estado phone_verified y el siguiente paso submit.
5

Enviar

POST /compliance/public/dsar/submit con claim_id. Persiste una fila de auditoría y — solo si el correo electrónico + teléfono verificados coinciden con un contacto de su tenant — pone en cola un DSAR real (premarcado como verification_status: verified, ya que el OTP ya probó la identidad). Devuelve un reference_id (p. ej., dsar_pub_…) y un booleano queued.

Configurar los remitentes de la prueba de identidad

Los dos OTP se envían desde remitentes de nivel de plataforma que usted configura una vez en su entorno de API. Establézcalos antes de publicar el portal: un remitente SMS sin configurar y sin fallback hace que el paso del teléfono falle en modo cerrado (fail-closed). Si DEVOTEL_DSAR_PROOF_SMS_FROM y DEVOTEL_PLATFORM_DEFAULT_FROM están ambos sin configurar, el paso send-phone falla en modo cerrado (fail-closed) con un 503 — el portal devuelve un mensaje de “no disponible temporalmente” y el fallo se emite bajo la métrica dsar.proof.sms_send_failed para que aparezca en sus paneles en lugar de omitir silenciosamente el segundo factor. Del mismo modo, el paso del correo electrónico devuelve 503 cuando DEVOTEL_RESEND_API_KEY no está configurada. Configure ambos remitentes antes de enlazar el portal públicamente.

Defensas contra abuso

La forma de respuesta es idéntica se cumpla o no la coincidencia de los identificadores con un contacto real: el portal nunca confirma ni niega que alguien esté en su base de datos. Cuando Redis no está disponible, las puertas de límite de tasa fallan en modo abierto (fail-open) para preservar la disponibilidad.

Habilitar la protección de Turnstile

La puerta de Turnstile se configura con dos variables de entorno.
La puerta es fail-open cuando DEVOTEL_TURNSTILE_SECRET_KEY no está configurada: begin acepta solicitudes sin token y registra una única advertencia. Establezca el secreto en producción, o el portal quedará desprotegido por Turnstile aunque todas las demás defensas contra abuso anteriores sigan aplicándose. Genere ambas claves en el panel de Cloudflare (Turnstile → Add site) y establézcalas en los despliegues de API y web respectivamente.

Alojar el enlace del portal

Publique el portal público en su política de privacidad como el enlace “Enviar una solicitud de privacidad”. Como el flujo se verifica automáticamente mediante OTP, las solicitudes que llegan por él ya tienen la identidad probada: llegan a su cola de operador listas para su cumplimiento y aparecen en GET /compliance/dsar junto a las solicitudes presentadas por operadores.

Referencias relacionadas