​

Portail DSAR en libre-service de bout en bout

​

1. Deux chemins d’intake, une file

​

2. Parcours du portail

​

Publier le lien

https://orbit.devotel.io/<locale>/dsar

​

Le prérequis d’e-mail expéditeur

​

Ce que voit la personne concernée

1. Begin — e-mail, téléphone (E.164), type de demande. Un OTP e-mail part immédiatement.
2. Verify email — un code e-mail à 6 chiffres (TTL 10 minutes, 3 tentatives, refroidissement de renvoi de 60 secondes).
3. Send phone code — un OTP SMS au même téléphone (refroidissement de 60 secondes entre envois).
4. Verify phone — un code SMS à 6 chiffres.
5. Submit — la demande n’entre dans votre file qu’avec les deux preuves. La revendication entière a un TTL de bout en bout de 30 minutes.

​

La juridiction détermine l’horloge SLA

​

3. Ce que voient les opérateurs après un dépôt

• Statut et échéance. La ligne porte le statut de cycle de vie habituel et un badge SLA Day X of N ancré à la fenêtre de la juridiction ; toute violation lève la bannière SLA au niveau workspace. GET /compliance/dsar/sla donne la même vue par l’API.
• Dépôts de classe effacement. Une personne qui a choisi « delete » apparaît dans la section portail de l’onglet Erasure requests (Art. 17), badge SLA à côté, en amont du refroidissement par défaut de 7 jours.
• Exécution. Un dépôt d’accès ou de portabilité court jusqu’à Completed avec une export_url signée ; l’action Download decrypted construit l’export en clair pour un opérateur. Un effacement, une fois exécuté, offre le certificat Proof of deletion et Propagate vers vos destinations connectées.
• Chaîne d’audit. Begin, les deux vérifications et submit écrivent des lignes avec des identifiants hashés (jamais bruts), IP source et user agent — l’enregistrement dans lequel puise votre evidence binder quand un régulateur demande comment l’identité a été établie.

​

4. Ce qu’Orbit ne fait pas

• Orbit ne décide jamais de la validité. Il n’accepte ni ne rejette jamais une demande pour des motifs légaux. Les lignes en attente de vérification attendent votre approuver/rejeter ; les lignes vérifiées s’exécutent parce que vous l’avez permis, pas parce que la plateforme a jugé la revendication.
• Orbit n’exécute jamais automatiquement un verdict opérateur. Pour une demande déposée par un opérateur, aucun export n’est produit et rien n’est effacé tant que verification_status: pending. Un dépôt portail ne saute la porte que parce que son OTP a déjà prouvé l’identité.
• L’effacement honore votre posture de refroidissement. Le défaut de 7 jours (redéfinissable par tenant) vous donne la fenêtre pour rejeter, tenir ou exempter avant destruction.
• Vous dire quelle loi s’applique reste le travail de votre conseil. Orbit ancre l’horloge SLA à la juridiction que la personne a choisie et que vous avez confirmée.
• Le portail expose le sous-ensemble de droits convivial consommateur — une personne qui a besoin d’un droit réservé aux opérateurs (rectifier, limiter les PI sensibles, non-discrimination) dépose via votre équipe.

​

Boucle de revendication du portail — échantillons de requêtes exécutables

​

1. Commencer la revendication

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/public/dsar/begin \
  -H "Content-Type: application/json" \
  -d '{
    "email": "customer@example.com",
    "phone": "+4915112345678",
    "request_type": "access",
    "turnstile_token": "…token from the hosted page…"
  }'

{
  "data": {
    "claim_id": "dsar_proof_01JZQV8K2W4P3N7M9T",
    "email_sent": true,
    "expires_in": 600
  }
}

​

2. Vérifier le code e-mail

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/public/dsar/verify-email \
  -H "Content-Type: application/json" \
  -d '{ "claim_id": "dsar_proof_01JZQV8K2W4P3N7M9T", "code": "582917" }'

{
  "data": { "state": "email_verified", "next_step": "phone_send" }
}

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid verification code.",
    "status": 422
  }
}

​

3. Envoyer et vérifier le code téléphone

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/public/dsar/send-phone \
  -H "Content-Type: application/json" \
  -d '{ "claim_id": "dsar_proof_01JZQV8K2W4P3N7M9T", "phone": "+4915112345678" }'

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/public/dsar/verify-phone \
  -H "Content-Type: application/json" \
  -d '{ "claim_id": "dsar_proof_01JZQV8K2W4P3N7M9T", "code": "034861" }'

{
  "data": { "state": "phone_verified", "next_step": "submit" }
}

​

4. Soumettre avec les deux preuves au dossier

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/public/dsar/submit \
  -H "Content-Type: application/json" \
  -d '{ "claim_id": "dsar_proof_01JZQV8K2W4P3N7M9T" }'

{
  "data": {
    "reference_id": "dsar_pub_01JZW4KC7F2H8R1Y5A",
    "queued": true
  }
}

​

5. Le relire dans la file opérateurs

curl https://api.orbit.devotel.io/api/v1/compliance/dsar?status=processing \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": {
    "items": [
      {
        "id": "dsar_01JZW4M0BXK7Q3P9VN",
        "requester_email": "customer@example.com",
        "request_type": "know",
        "applicable_jurisdiction": "gdpr",
        "verification_method": "email_phone",
        "verification_status": "verified",
        "status": "processing",
        "requested_at": "2026-09-27T09:41:12.104Z"
      }
    ],
    "total": 1
  }
}

curl https://api.orbit.devotel.io/api/v1/compliance/dsar/sla \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": {
    "items": [
      {
        "id": "dsar_01JZW4M0BXK7Q3P9VN",
        "kind": "export",
        "sla_days": 30,
        "days_elapsed": 1,
        "days_remaining": 29,
        "severity": "green",
        "sla_deadline_at": "2026-10-27T09:41:12.104Z",
        "approaching": false,
        "breach": false
      }
    ],
    "breach_count": 0
  }
}

​

5. Exemple déroulé — une demande d’accès GDPR de bout en bout

1. Begin. Elle saisit son e-mail, son téléphone en E.164 (+4915…), choisit access et franchit le contrôle Turnstile. Le portail rend un claim id ; l’OTP e-mail est déjà en route.
2. Verify email. Elle lit le code à 6 chiffres (TTL 10 minutes, jusqu’à 3 tentatives) et passe le premier facteur.
3. Send phone code, verify phone. Le second facteur se répète par SMS — 60 secondes de refroidissement entre envois — et les deux preuves sont désormais au dossier.
4. Submit. Le portail dépose la demande. Parce que son e-mail et son téléphone correspondent à un contact de votre workspace, la ligne entre en file en know sous gdpr et rend une référence dsar_pub_….
5. Dans votre file. La ligne affiche Day 1 of 30 — verification_status: verified — et le worker d’export l’a déjà. Personne dans votre équipe ne touche le tri.
6. Exécuter. Le worker compile l’export et marque la ligne Completed avec export_url et tables_exported. Un opérateur remet le lien de téléchargement (une copie en clair réservée aux opérateurs est à un clic de Download decrypted).
7. Au-delà de la ligne SLA. Si la ligne est encore ouverte quand la fenêtre GDPR de 30 jours s’écoule, la bannière SLA du workspace la signale — et si elle avait mal choisi une juridiction à l’intake, votre reclassification depuis la file corrige l’horloge rétroactivement.

​

Références connexes

• Référence DSAR — les surfaces d’endpoints complètes opérateur et publique, les limites de défense contre l’abus et les niveaux de sévérité SLA.
• Désignation DPO et représentant UE/UK — les désignations Art.37/Art.27 qu’un avis de confidentialité doit nommer.
• Registre des traitements GDPR (ROPA + DPIA) — l’inventaire Art.30 tenu avant qu’une demande n’arrive.
• Evidence binder de conformité — assembler les lignes d’audit que laisse un dépôt portail.
• Exécuter une DSAR et tenir le registre des incidents de violation — le parcours opérateur de la file que votre portail alimente.
• Assembler une posture GDPR de bout en bout — où l’intake portail s’insère dans la séquence complète.