Gestion du consentement et reçus

Avant de contacter un destinataire sur un canal réglementé, vous avez généralement besoin d’un fondement licite — le plus souvent le consentement. L’API de consentement d’Orbit est le système de référence pour savoir qui a opté pour l’adhésion ou la désinscription, sur quel canal, quand, et sous quel fondement juridique. Chaque écriture se propage vers les surfaces contre lesquelles vos envois sont bloqués, de sorte qu’enregistrer le consentement ici est ce qui débloque (ou bloque) réellement un message. Vous pouvez aussi exporter la piste complète sous forme de fichier CSV ou JSON prêt pour l’audit. Tous les points d’entrée ci-dessous sont racinés sur https://api.orbit.devotel.io/api/v1/compliance.

L’enregistrement du consentement dans Orbit crée une piste auditable, mais ne rend pas par lui-même un envoi licite. Vous restez responsable de l’obtention d’un consentement valide et du contenu que vous envoyez. Cette page n’est pas un avis juridique.

Canaux et états

Le consentement est suivi par canal. L’ensemble des canaux pris en charge est : email, fax, instagram, line, messenger, push, rcs, sms, viber, voice, whatsapp. Une paire (contact, canal) se résout en l’un des trois états :

État	Signification
`opted_in`	Consentement accordé et non révoqué.
`opted_out`	Consentement révoqué, ou une désinscription explicite enregistrée.
`unknown`	Aucun enregistrement de consentement n’existe pour la paire — votre porte d’envoi décide de la valeur par défaut.

Enregistrement du consentement

POST /compliance/consent enregistre une adhésion ou une désinscription sur un ou plusieurs canaux en un seul appel. Identifiez le contact par contact_id ou par identifier (un e-mail, un téléphone E.164 ou un identifiant WhatsApp — Orbit résout le type automatiquement).

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier": "jordan@example.com",
    "channels": ["email", "sms"],
    "opt_in": true,
    "source": "web_form",
    "consent_type": "marketing",
    "lawful_basis": "consent",
    "purpose": "Weekly product newsletter and order updates",
    "consent_text_version": "tos-2026-04",
    "consent_proof_url": "https://example.com/proofs/abc123.png"
  }'

Renvoie 201 Created :

{
  "contact_id": "cnt_9f…",
  "consent_record_ids": ["cr_a1…", "cr_b2…"],
  "channels": ["email", "sms"],
  "state": "opted_in",
  "valid_until": null
}

Champ	Type	Notes
`contact_id` / `identifier`	string	Fournissez l’un des deux.
`channels`	string[]	Un ou plusieurs canaux de l’ensemble ; dédupliqués et triés.
`opt_in`	boolean	Requis. `true` = adhésion, `false` = désinscription.
`source`	string	Comment le consentement a été capturé (p. ex. `web_form`, `import`, `double_opt_in`). Défaut `consent_api`.
`consent_type`	string	Catégorie de finalité, p. ex. `marketing`, `transactional`. Défaut `messaging`.
`lawful_basis`	enum	Fondement RGPD Art 6 : `consent`, `contract`, `legal_obligation`, `vital_interests`, `public_task`, `legitimate_interests`.
`purpose`	string	Texte libre décrivant l’utilisation (≤ 500).
`consent_text_version`	string	Version de la notice acceptée par la personne.
`consent_proof_url`	string (url)	Lien vers une capture d’écran ou un document signé.
`valid_until`	string (ISO-8601 UTC)	Instant absolu auquel le consentement expire. Adhésion uniquement — ignoré lors d’une désinscription. Mutuellement exclusif avec `expires_in_days`.
`expires_in_days`	integer	Fenêtre de validité relative (1–3650 jours à partir de maintenant). Adhésion uniquement. Mutuellement exclusif avec `valid_until`.
`metadata`	object	Paires clé/valeur arbitraires.

Fournir à la fois valid_until et expires_in_days est ambigu et rejeté avec 422 VALIDATION_ERROR. Lorsque vous définissez une fenêtre, la réponse 201 renvoie le valid_until résolu (l’instant d’expiration absolu) ; il vaut null pour une autorisation sans expiration ou une désinscription. Ré-enregistrer une adhésion avec une nouvelle fenêtre prolonge la validité — le granted_at original est conservé, mais l’expiration est mise à jour. Ce qu’une écriture fait. Chaque canal enregistré met à jour quatre surfaces synchronisées : la table d’audit consent_records, le miroir channel_preferences du contact (le chemin rapide en lecture que vos envois consultent), la suppression_list (lors d’une désinscription), et une barrière STOP Redis de courte durée pour que les lots de campagne en cours honorent le changement en ~10 minutes.

Les écritures sont partiellement sûres : si un canal échoue, les autres s’appliquent quand même. Comparez consent_record_ids.length au nombre de canaux demandés pour détecter une écriture partielle. Ré-enregistrer une adhésion pour un canal déjà adhéré actualise les métadonnées/preuves mais conserve le granted_at original.

Recherche du consentement

GET /compliance/consent/lookup renvoie l’état actuel d’une paire (contact, canal) — utilisez-le comme porte pré-envoi.

curl "https://api.orbit.devotel.io/api/v1/compliance/consent/lookup?identifier=jordan@example.com&channel=sms" \
  -H "Authorization: Bearer $ORBIT_API_KEY"

{
  "contact_id": "cnt_9f…",
  "channel": "sms",
  "state": "opted_in",
  "source": "web_form",
  "granted_at": "2026-04-02T10:11:00.000Z",
  "revoked_at": null,
  "lawful_basis": "consent",
  "purpose": "Weekly product newsletter and order updates",
  "consent_text_version": "tos-2026-04",
  "consent_proof_url": "https://example.com/proofs/abc123.png",
  "valid_until": null,
  "expired": false,
  "requires_reconfirmation": false
}

Un state de unknown signifie qu’aucun enregistrement n’existe pour la paire — votre application décide si cela implique un consentement (certain flux transactionnels) ou bloque l’envoi (la plupart des flux marketing). Les trois derniers champs rapportent le consentement borné dans le temps et sont toujours présents :

Champ	Type	Notes
`valid_until`	string \| null	L’instant d’expiration de l’autorisation, ou `null` lorsque le consentement n’expire jamais (ou la paire est désinscrite).
`expired`	boolean	`true` lorsque l’autorisation est adhérée mais que son `valid_until` est désormais dans le passé. Traitez une autorisation expirée comme non consentie à votre porte d’envoi.
`requires_reconfirmation`	boolean	Miroir de `expired` — un indice pour déclencher un flux de re-permission. Effacez-le en enregistrant une nouvelle adhésion (éventuellement avec une nouvelle fenêtre).

Trouver les consentements qui expirent

GET /compliance/consent/expiring balaie le tenant pour les adhésions dont la fenêtre de validité a expiré ou est sur le point de l’être — l’entrée d’une campagne de re-permission (re-confirmation). Seules les autorisations portant un valid_until sont renvoyées ; le consentement sans expiration n’apparaît jamais.

curl "https://api.orbit.devotel.io/api/v1/compliance/consent/expiring?within_days=30&status=all" \
  -H "Authorization: Bearer $ORBIT_API_KEY"

Paramètres de requête :

Paramètre	Type	Notes
`within_days`	integer	Horizon de prévision (0–3650, défaut 30). Renvoie les autorisations dont le `valid_until` est inférieur ou égal à maintenant + `within_days` ; les autorisations déjà expirées sont toujours incluses.
`channel`	enum	Optionnel — limiter à un seul canal.
`status`	enum	`all` (défaut), `expired` (déjà passé `valid_until`), ou `expiring` (toujours valide mais dans l’horizon).
`limit`	integer	Taille de page (1–100, défaut 50).
`cursor`	string	Curseur de pagination opaque — renvoyez-le tel quel.

{
  "within_days": 30,
  "channel": null,
  "status": "all",
  "as_of": "2026-05-01T09:00:00.000Z",
  "items": [
    {
      "id": "cr_b2…",
      "contact_id": "cnt_9f…",
      "channel": "sms",
      "consent_type": "marketing",
      "source": "web_form",
      "lawful_basis": "consent",
      "granted_at": "2025-05-02T10:11:00.000Z",
      "valid_until": "2026-04-20T00:00:00.000Z",
      "expired": true,
      "status": "expired",
      "requires_reconfirmation": true
    }
  ],
  "next_cursor": null
}

Les éléments sont ordonnés de la plus ancienne expiration d’abord. Chacun porte un status (expired ou expiring) afin que vous puissiez séparer « doit re-confirmer maintenant » de « avertir avant la fermeture de la fenêtre ». La re-confirmation est une adhésion ordinaire POST /compliance/consent — éventuellement avec un nouveau valid_until ou expires_in_days.

Traitez next_cursor comme opaque et renvoyez-le tel quel ; une valeur null signifie la dernière page. Un curseur invalide ou périmé est traité comme une première page neuve plutôt qu’une erreur.

Poignées de main du consentement confirmé (double opt-in)

Un simple POST /compliance/consent affirme l’autorisation — c’est le système de référence une fois que votre propre surface a obtenu le consentement. Lorsque le niveau de preuve exige une réponse du destinataire enregistrée (consentement écrit exprès TCPA, opt-in confirmé UE, revue de campagne 10DLC), pilotez plutôt la poignée de main de double opt-in gérée :

POST /compliance/consent/double-opt-in — begin : enregistre une ligne en attente (pas encore une autorisation de consentement) et renvoie le texte de l’invite de confirmation pour la paire.
Le destinataire répond ; relayez le texte vers POST /compliance/consent/double-opt-in/confirm — confirm : un mot-clé affirmatif correspondant à l’invite en attente convertit la paire en une autorisation opted_in confirmée.
GET /compliance/consent/double-opt-in/status — read : l’état actuel (opted_in | opted_out | pending | none) plus les drapeaux confirmed / awaiting_reply, sans effet de bord.

Les poignées de main confirmées atterrissent dans le même registre de consentement que cette page documente — /lookup, /history et l’export les lisent identiquement. Tant qu’elle n’est pas confirmée, une poignée de main en attente n’est pas une autorisation de consentement. Tenant-owned : rien ne démarre une poignée de main pour le compte de la plateforme. Mécanique complète sur Confirmed Consent (Double Opt-In) Handshakes.

Historique du consentement

GET /compliance/consent/history renvoie la piste d’audit complète et paginée d’un contact — chaque autorisation et révocation, la plus récente d’abord. Paramètres de requête : contact_id ou identifier (un requis), un filtre channel optionnel, limit (≤ 100, défaut 50), et un cursor opaque.

{
  "contact_id": "cnt_9f…",
  "channel": null,
  "items": [
    {
      "id": "cr_b2…",
      "channel": "sms",
      "consent_state": "opted_in",
      "granted": true,
      "source": "web_form",
      "granted_at": "2026-04-02T10:11:00.000Z",
      "revoked_at": null,
      "lawful_basis": "consent",
      "created_at": "2026-04-02T10:11:00.000Z"
    }
  ],
  "next_cursor": "eyJ0…"
}

Traitez next_cursor comme opaque — renvoyez-le tel quel pour récupérer la page suivante. Un curseur invalide ou périmé est traité comme une première page neuve plutôt qu’une erreur.

Exporter la preuve de référence du consentement

GET /compliance/consent/export télécharge la piste de consentement de l’ensemble de votre tenant en un seul fichier — la réponse à un audit TCPA, au fardeau de preuve RGPD Art 7(1), ou à une demande de découverte (« montrez qui a opté pour l’adhésion ou la désinscription, quand, sur quel canal, depuis quelle source »). C’est la contrepartie en masse de /lookup et /history.

curl "https://api.orbit.devotel.io/api/v1/compliance/consent/export?format=csv&state=opted_out" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -o consent-proof-of-record.csv

Paramètres de requête :

Paramètre	Type	Notes
`format`	enum	`csv` (défaut — RFC-4180, s’ouvre dans un tableur) ou `json`.
`channel`	enum	Limiter à un seul canal.
`state`	enum	`all` (défaut), `opted_in`, `opted_out`, ou `unknown`.
`contact_id`	string	Limiter l’export à un seul contact — la forme d’une demande de découverte.
`from` / `to`	string	Plage de dates sur le `created_at` de l’enregistrement. Accepte une date nue `YYYY-MM-DD` ou un datetime RFC-3339.
`limit`	integer	Lignes à inclure (1–50 000, défaut 50 000).

Chaque ligne porte un événement de consentement joint aux identifiants du contact — record_id, contact_id, email, phone, whatsapp_id, channel, consent_state, granted, consent_type, source, plus les colonnes de fardeau de preuve RGPD lawful_basis, purpose, policy_template, consent_text_version, consent_proof_url, ip_address, valid_until, et les horodatages d’autorisation/révocation/mise à jour. Les téléchargements CSV arrivent avec un nom de fichier daté (consent-proof-of-record-YYYY-MM-DD.csv) et ne croisent jamais un cache de lecture (Cache-Control: no-store). Demandez format=json et la réponse renvoie plutôt une enveloppe columns / items / count — les mêmes données pour les consommateurs programmatiques. L’accès est limité aux clés owner et admin — la charge expose les identifiants bruts des destinataires à l’échelle du tenant, le même niveau de confiance que l’import de suppression. Chaque exécution d’export est elle-même écrite dans le journal d’audit avec ses filtres et son nombre de lignes.

Lorsque votre registre dépasse 50 000 lignes, l’export est tronqué au plafond : les réponses CSV portent un en-tête X-Export-Truncated: true et l’enveloppe JSON définit truncated: true. Réduisez par canal ou par état, ou paginez en exportant des fenêtres de dates consécutives avec from/to.

Le Digital Personal Data Protection Act (DPDP) de l’Inde introduit le concept de Consent Manager — un intermédiaire enregistré et responsable qui émet des reçus de consentement cryptographiquement signés pour le compte d’une personne concernée. Orbit peut enregistrer les gestionnaires par lesquels passent vos utilisateurs et vérifier les reçus qu’ils émettent. POST /compliance/consent/managers (admin/owner) enregistre un gestionnaire et stocke sa clé publique (un PEM SPKI ECDSA P-256) utilisée pour vérifier chaque reçu qu’il signe.

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent/managers \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Consent Manager",
    "manager_id": "acme-cm-001",
    "manager_url": "https://cm.acme.example",
    "public_key": "-----BEGIN PUBLIC KEY-----\n…\n-----END PUBLIC KEY-----",
    "country_code": "IN"
  }'

GET /compliance/consent/managers énumère les gestionnaires enregistrés (actifs d’abord).
PUT /compliance/consent/managers/{id} met à jour ou désactive l’un d’eux (mise à jour partielle ; tous les champs optionnels).

Stocker un reçu signé

POST /compliance/consent/receipts vérifie un reçu signé par un gestionnaire et le persiste comme consentement. La signature (ECDSA P-256 / SHA-256, IEEE-P1363, base64url) est vérifiée contre la clé publique du gestionnaire enregistré sur une canonicalisation JSON à clés triées inspirée de JCS de la charge avant que quoi que ce soit soit stocké. Cette canonicalisation trie les clés d’objet par ordre croissant d’unité de code UTF-16 et supprime les espaces insignifiants, mais ce n’est pas une implémentation complète de RFC 8785 — en particulier elle n’applique pas les règles de sérialisation des nombres mandatées par JCS. Signez les reçus avec la même forme à clés triées qu’Orbit utilise plutôt que de supposer qu’un vérificateur RFC 8785 complet produira un hash correspondant.

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent/receipts \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contact_id": "cnt_9f…",
    "consent_manager_id": "acme-cm-001",
    "channel": "sms",
    "consent_type": "marketing",
    "receipt": {
      "receipt_id": "rcpt_77…",
      "issued_at": "2026-05-01T09:00:00.000Z",
      "purpose": "Promotional SMS",
      "fiduciary_id": "fid_acme",
      "signature": "MEUCIQ…",
      "payload": { "…": "…" }
    }
  }'

Renvoie 201 avec { "id": …, "receipt_id": …, "verified": true }. Une mauvaise signature, ou un gestionnaire non enregistré/inactif, renvoie 422 CONSENT_RECEIPT_INVALID — le détail note que la charge a pu être altérée ou que le gestionnaire a pu effectuer une rotation de clés.

Re-vérifier un reçu stocké

POST /compliance/consent/receipts/{id}/verify re-vérifie un reçu précédemment stocké contre la clé actuelle du gestionnaire — utilisez-le lors d’un audit pour confirmer qu’un reçu se valide toujours et si son gestionnaire reste actif. {id} accepte soit l’identifiant de l’enregistrement de consentement, soit le receipt_id.

Les reçus de consentement exigent la migration tenant consent_managers. Sur les tenants qui la précèdent, les chemins de lecture se dégradent avec grâce : la liste des gestionnaires renvoie une liste vide et le point de re-vérification renvoie 404. L’émission d’un reçu est fail-closed, donc POST /compliance/consent/receipts renvoie 422 CONSENT_RECEIPT_INVALID sur les tenants pré-migration plutôt que de se dégrader — exécutez la migration avant d’émettre des reçus.

Références associées

Assembling a GDPR Posture End to End — la séquence que cette couche de consentement alimente.
Confirmed Consent (Double Opt-In) Handshakes — le flux begin/confirm/status au-dessus d’un enregistrement de consentement simple.
Consent Posture: The Unknown-Consent Policies — les réglages au niveau de l’organisation qui décident ce que les contacts sans ligne au registre peuvent recevoir (envois marketing vs fanout CDP).
Opt-Out & Suppression Lists — import en masse des désinscriptions et comment la liste de suppression bloque les envois.
DSAR — honorer les demandes d’accès/suppression sur l’enregistrement de consentement.
DLT-India Onboarding — la couche d’enregistrement qui s’associe au consentement DPDP sur les SMS indiens.
API Reference → Compliance — schémas complets de requêtes/réponses (régénérés depuis l’API en direct).

Getting Started

Channels

Channels (Voice)

AI Agents

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Changelog

Gestion du consentement et reçus

Gestion du consentement et reçus

Canaux et états

Enregistrement du consentement

Recherche du consentement

Trouver les consentements qui expirent

Poignées de main du consentement confirmé (double opt-in)

Historique du consentement

Exporter la preuve de référence du consentement

Stocker un reçu signé

Re-vérifier un reçu stocké

Références associées

​Gestion du consentement et reçus

​Canaux et états

​Enregistrement du consentement

​Recherche du consentement

​Trouver les consentements qui expirent

​Poignées de main du consentement confirmé (double opt-in)

​Historique du consentement

​Exporter la preuve de référence du consentement

​Enregistrer un Consent Manager

​Stocker un reçu signé

​Re-vérifier un reçu stocké

​Références associées

Gestion du consentement et reçus

Canaux et états

Enregistrement du consentement

Recherche du consentement

Trouver les consentements qui expirent

Poignées de main du consentement confirmé (double opt-in)

Historique du consentement

Exporter la preuve de référence du consentement

Enregistrer un Consent Manager

Stocker un reçu signé

Re-vérifier un reçu stocké

Références associées