> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Enregistrement des identifiants d'expéditeur (Sender ID) > Enregistrez des Sender ID alphanumériques par pays sur Orbit, suivez le statut d'approbation et comprenez pourquoi certaines destinations bloquent les expéditeurs non enregistrés. # Enregistrement des identifiants d'expéditeur (Sender ID) Un **Sender ID alphanumérique** est un court nom de marque (par exemple `MyBrand`) qui apparaît comme expéditeur d'un SMS à la place d'un numéro de téléphone. De nombreux pays exigent que vous **enregistriez** un Sender ID auprès du régulateur local ou des opérateurs avant que le trafic l'utilisant ne soit livré — et certains bloquent carrément les expéditeurs alphanumériques non enregistrés. Orbit vous permet de consigner vos enregistrements de Sender ID par pays, d'y joindre les documents KYC justificatifs et de suivre le statut d'approbation de chaque pays. Les portes au moment de l'envoi garantissent ensuite que le trafic ne passe que là où un Sender ID est approuvé. Tous les endpoints ci-dessous sont racinés sous `https://api.orbit.devotel.io/api/v1/compliance`. Enregistrer un Sender ID dans Orbit le soumet à notre workflow de conformité ; **l'approbation finale est accordée par le régulateur/l'opérateur de chaque pays**, pas instantanément par la plateforme. Prévoyez un délai — certains marchés prennent de quelques jours à plusieurs semaines. *** ## Règles de format des Sender ID | Règle | Valeur | | -------------------- | -------------------------------------------------------- | | Longueur | 3–11 caractères | | Caractères autorisés | lettres, chiffres, espace, tiret (`-`), underscore (`_`) | Le plafond de 11 caractères est la limite stricte du GSM 7-bit ; des régulateurs comme l'ANATEL (Brésil), l'OFCOM (Royaume-Uni), l'AGCOM (Italie) et le BTRC (Bangladesh) rejettent les Sender ID de moins de 3 caractères. *** ## Enregistrer ou mettre à jour un Sender ID `POST /compliance/sender-id-registrations` (admin/propriétaire) soumet un Sender ID pour un ou plusieurs pays. Chaque entrée de pays référence des documents de conformité préalablement téléversés par leurs IDs `doc_…` — vous ne téléversez pas de fichiers ici. ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/sender-id-registrations \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "sender_id": "MyBrand", "countries": [ { "country": "BR", "document_refs": ["doc_abc123def456"], "notes": "Retail brand, transactional + OTP use case" } ] }' ``` | Champ | Type | Remarques | | -------------------------------------- | --------- | ----------------------------------------------------------------------------------- | | `sender_id` | string | 3–11 caractères, voir les règles de format ci-dessus. | | `countries` | array | 1–20 entrées. | | `countries[].country` | string | ISO-3166-1 alpha-2 (majuscules). | | `countries[].document_refs` | string\[] | 1–20 IDs de la forme `doc_…` référençant des documents KYC précédemment téléversés. | | `countries[].registration_provider_id` | string | Référence aval/opérateur optionnelle (≤ 200). | | `countries[].notes` | string | Texte libre optionnel, p. ex. cas d'usage (≤ 2000). | Renvoie la vue de l'enregistrement avec le `status` de chaque pays : ```json theme={null} { "data": { "id": "sidreg_xyz", "sender_id": "MyBrand", "countries": [ { "country": "BR", "status": "pending", "document_refs": ["doc_abc123def456"], "registered_at": null, "expires_at": null, "registration_provider_id": null, "notes": "Retail brand, transactional + OTP use case" } ] }, "meta": { "request_id": "…", "timestamp": "2026-06-08T12:00:00.000Z" } } ``` La soumission est un **upsert idempotent** indexé sur `(organization, sender_id)`. Une nouvelle soumission : * ajoute de nouveaux pays avec `status: pending` ; * pour un pays déjà `approved`, **conserve l'approbation** tout en rafraîchissant ses documents, sa référence opérateur et ses notes ; * pour un pays qui était `rejected` ou `expired`, **le remet à `pending`** afin qu'il soit réexaminé. Cela vous permet d'ajouter en toute sécurité des pays à un Sender ID existant sans perdre les approbations déjà obtenues. *** ## Lister vos enregistrements `GET /compliance/sender-id-registrations` renvoie chaque Sender ID et son statut par pays. Accessible à tout utilisateur authentifié. ```json theme={null} { "data": { "entries": [ { "id": "sidreg_xyz", "sender_id": "MyBrand", "countries": [ { "country": "BR", "status": "approved", "document_refs": ["doc_abc123def456"], "registered_at": "2026-06-05T00:00:00.000Z", "expires_at": "2027-06-05T00:00:00.000Z" } ] } ], "total": 1 }, "meta": { "request_id": "…", "timestamp": "2026-06-08T12:00:00.000Z" } } ``` *** ## Cycle de vie des statuts | Statut | Signification | | ---------- | ------------------------------------------------------------------------------------------- | | `pending` | Soumis, en attente d'examen/d'approbation. | | `approved` | Validé — le trafic avec ce Sender ID est autorisé pour le pays. | | `rejected` | Refusé ; corrigez le problème et soumettez à nouveau pour repasser à `pending`. | | `expired` | La fenêtre de validité de l'enregistrement est close ; soumettez à nouveau pour renouveler. | Lorsqu'une entrée de pays est `approved`, elle porte `registered_at` et `expires_at`. Renouvelez avant `expires_at` pour éviter une interruption. Les portes au moment de l'envoi appliquent l'enregistrement : un SMS A2P vers un pays exigeant un Sender ID enregistré est **bloqué** tant que l'entrée de ce pays n'est pas `approved`. Enregistrez-vous et obtenez l'approbation avant de lancer du trafic vers un nouveau marché. Sur les organisations créées avant la migration des Sender ID, le endpoint de liste renvoie un ensemble vide et `POST` renvoie `409 TENANT_NOT_MIGRATED` — contactez le support pour activer la fonctionnalité. *** ## L'Inde est un cas particulier L'Inde n'utilise **pas** ce flux générique de Sender ID. Les Sender ID SMS indiens (« Headers ») sont enregistrés via le système DLT/TRAI — voir [Onboarding DLT-India](/compliance/dlt-india). *** ## Références associées * [Documents KYC et cycle de vie du profil de conformité](/compliance/documents-kyc) — comment téléverser les IDs `doc_…` que vous référencez ici, les réutiliser entre profils et les renouveler avant leur expiration. * [Exigences de conformité par pays](/compliance/country-requirements) — quels types d'expéditeurs chaque pays accepte et si l'enregistrement est obligatoire, ainsi que les documents à fournir. * [Résoudre les rejets du mode strict des Sender ID](/troubleshooting/strict-sender-id-invalid-destination) — la porte optionnelle de format d'expéditeur et les codes de règle qu'elle renvoie pour un expéditeur non conforme. * [Onboarding DLT-India](/compliance/dlt-india) — enregistrement des Sender ID (« Headers ») pour l'Inde. * [Send Gates](/compliance/send-gates) — les règles par pays et les portes qui appliquent l'enregistrement au moment de l'envoi. * [Gestion du consentement](/compliance/consent-management) — la couche de consentement qui complète la conformité des Sender ID. * [Référence API → Conformité](/api-reference/endpoints/compliance) — schémas complets de requêtes/réponses (régénérés depuis l'API en direct).