Skip to main content

Requisitos de cumplimiento por país

Las reglas de mensajería y voz se fijan país por país. Antes de enviar a un mercado nuevo necesita conocer cuatro cosas: qué tipos de remitente acepta ese país (¿un código largo? ¿un Sender ID alfanumérico? ¿un código corto?), si el registro es obligatorio, qué documentos debe aportar y qué contenido está restringido. Equivocarse en esto es la razón más común de que los primeros envíos a un país nuevo no se entreguen silenciosamente. Orbit mantiene una referencia regulatoria curada, por país, para que no tenga que armarla usted mismo. Esta página explica cómo leerla.
Esta referencia es una guía para ayudarle a planificar, no una garantía de entrega ni asesoría legal. La aprobación final de un Sender ID o de un registro la concede el regulador o el operador de cada país, no Orbit. La cobertura se habilita por inquilino: que un país aparezca aquí no significa que esté habilitado en su cuenta.

Consulte las reglas de un país

GET /compliance/country-rules es la referencia regulatoria de solo lectura que respalda las puertas de envío de Orbit. Cualquier usuario autenticado puede llamarla. Filtre por channel (por defecto, sms) y, opcionalmente, por region:
Cada fila describe un país × canal:
El filtro channel acepta sms, whatsapp, rcs, voice, email y viber. El mismo país tiene filas separadas por canal porque canales distintos responden a reguladores distintos — por ejemplo, las reglas WABA de Meta rigen WhatsApp en Brasil mientras que las reglas de Anatel rigen el SMS.

Cómo leer cada campo

Tipos de remitente


Los niveles de registration

El campo registration es el valor más importante que debe leer antes de lanzar. Alimenta la puerta de envío de Orbit:
No se requiere registro de Sender ID. Puede comenzar a enviar una vez que el canal y el país estén habilitados en su cuenta.
El tráfico está bloqueado hasta que tenga un registro de Sender ID aprobado para el país. El SMS A2P hacia un país required sin una entrada aprobada queda retenido por la puerta de envío. Registre y obtenga la aprobación antes del lanzamiento — vea Registro de Sender ID.

Documentación que cada país espera

Cuando un país exige (o recomienda) registro, usted envía los documentos de respaldo una vez y luego los referencia por sus IDs doc_… al registrar un Sender ID. El conjunto exacto varía según el mercado, pero la mayoría de los reguladores piden alguna combinación de:
  • Prueba de registro mercantil — certificado de constitución, licencia comercial o equivalente.
  • Una descripción del caso de uso — qué envía (transaccional, OTP, marketing) y a quién.
  • Propiedad de la marca / autorización — prueba de que tiene derecho al Sender ID / nombre de marca que está registrando.
  • ID fiscal o de regulador local — para mercados que vinculan el registro a un identificador nacional.
Lea los campos sender_rules y content_restrictions del país de destino en la respuesta de country-rules para conocer los detalles, y adjunte los documentos correspondientes al enviar el registro. Algunos mercados operan su propio régimen de registro dedicado en lugar del flujo genérico de Sender ID:
  • India — Los Sender ID (“Headers”), las plantillas de contenido y las plantillas de consentimiento se registran a través del portal TRAI DLT. Vea Onboarding de DLT-India.
  • Estados Unidos — Los remitentes de SMS A2P registran una marca y una campaña vía 10DLC. Vea la guía de registro 10DLC.

Una lista de verificación de lanzamiento para un país nuevo

1

Consulte las reglas

Llame a GET /compliance/country-rules?channel=<channel> para el destino y lea sender_types, registration y content_restrictions.
2

Elija un tipo de remitente aceptado

Elija una identidad de remitente de entre los sender_types de ese país — un Sender ID alfanumérico, un código largo, un código corto o un remitente nativo del canal (WABA / agente RCS).
3

Registre si es obligatorio

Si registration es required (o recommended), cargue sus documentos y envíe el Sender ID para aprobación. Prevea el plazo — algunos mercados tardan de días a semanas.
4

Verifique las restricciones de contenido

Confirme que su caso de uso está permitido según content_restrictions y Industrias restringidas y prohibidas, y añada la palabra clave de opt-out requerida si stop_requirement la exige.
5

Lance

Una vez que el país está habilitado, el tipo de remitente es aceptado y cualquier registro requerido está aprobado, comience a enviar.

Mantenimiento de la fuente de reglas (operadores de plataforma)

Esta sección es para operadores de plataforma y despliegues autoalojados. Los clientes SaaS en api.orbit.devotel.io pueden detenerse aquí — Devotel mantiene las reglas por país actualizadas para usted, y los endpoints siguientes están limitados a administradores de plataforma.
La referencia de reglas por país se alimenta de sincronizaciones programadas con fuentes externas más ediciones manuales del operador. Esta sección cubre cómo mantenerla al día y cómo editar un solo país de forma segura. Los endpoints que escriben en la tabla de reglas son solo para administradores de plataforma — los propietarios y administradores de inquilinos reciben un 403, porque la tabla de reglas es global para todos los inquilinos, no datos por inquilino.

Fuentes de alimentación

El sync_source de cada fila registra qué fuente la actualizó por última vez. Seis proveedores se conectan al endpoint de sincronización: Dos feeds adyacentes alimentan sus propias tablas:
  • Cobertura de Telnyx para la matriz heredada de Sender ID — los endpoints de lectura detrás de la matriz de cumplimiento de Sender ID se alimentan de una tabla heredada separada. Actualícela con POST /api/v1/compliance/admin/sync (solo admin; el mismo programador semanal también la actualiza automáticamente).
  • Reassigned Numbers Database (RND) — la puerta de números desconectados de EE. UU. documentada en Escrutinio de desactivación. Los inquilinos la habilitan por inquilino vía PUT /api/v1/compliance/rnd/settings con { "enabled": true }; el interruptor se niega a activarse hasta que un operador haya cargado una instantánea de RND en el despliegue, de modo que los inquilinos no puedan optar por una puerta vacía.

Ejecute una sincronización con la fuente externa

POST /api/v1/compliance/country-rules/sync actualiza desde un proveedor. Elija el feed con ?provider= (por defecto, telnyx) y, opcionalmente, límite a un solo ?channel=.
La respuesta reporta upstreamCount, updated, createdNew y un array errors. Una sincronización nunca sobrescribe la prosa curada por el operador — solo se actualizan los campos estructurales (nombre del país, código de llamada, región, tipos de remitente, nivel de registro); los campos de texto libre (sender_rules, content_restrictions, notes) conservan lo que un operador escribió por última vez.

Cadencia de los feeds

Dos caminos mantienen la tabla actualizada:
  • Programador semanal — el tick de compliance-sync del webhook-worker ejecuta los feeds de Telnyx, MEF y GSMA automáticamente. También se ejecuta una vez al arrancar el worker, de modo que un despliegue nuevo se siembra en el primer arranque.
  • Bajo demanda — la acción de administración “Refresh from upstream” llama al endpoint de sincronización anterior para una extracción inmediata (útil justo después de aprovisionar una credencial de feed nueva).
La desactualización se comprueba contra last_synced_at, que el endpoint de lectura devuelve junto a las filas. Las ediciones manuales estampan last_reviewed_at en su lugar, de modo que el panel puede mostrar la procedencia (“Sincronizado desde MEF hace 3 días; revisado por operaciones ayer”) en lugar de una única marca de tiempo ambigua.

Manejo de fallos

Cada conector es opcional y fail-open: cuando su variable de entorno de credencial no está configurada, la sincronización registra un mensaje de omisión y devuelve una entrada en errors, y las filas existentes permanecen en su lugar. Lo mismo aplica ante una caída de la fuente externa — la respuesta lleva el texto del error mientras los datos previamente sincronizados siguen siendo legibles. Estos son feeds de metadatos de solo lectura en una ruta de consulta; la mensajería saliente sigue enrutándose a través de su remitente normal mientras un feed está caído.
Los proveedores de sincronización tocan solo metadatos de cobertura. Nunca son una ruta de transporte — no intente enrutar mensajería saliente a través de ninguno de los feeds de cobertura aquí enumerados.

Edite un solo país

PUT /api/v1/compliance/country-rules/:channel/:country_code inserta o actualiza una fila de país × canal. Úselo para aportar detalles que ningún feed lleva — por ejemplo, la redacción de la palabra clave STOP o límites de rendimiento tomados del texto del regulador. Se requieren credenciales de administrador de plataforma; los administradores de inquilino reciben un 403.
Campos editables: sender_types, registration (none / recommended / required), sender_rules, content_restrictions, stop_requirement, two_way, dlr_support, default_tps, notes y sources (una lista [{ label, url }] de enlaces de atribución). El upsert estampa last_reviewed_at y marca la fila como sync_source: manual, de modo que una sincronización automática posterior solo actualiza los campos estructurales y deja su prosa intacta.

Lista de verificación antes de activar un país

Antes de activar un país para el envío, confirme:
1

Sello de sincronización reciente

last_synced_at (o, para la matriz heredada, last_verified_at) es reciente — de lo contrario, ejecute la sincronización bajo demanda del proveedor relevante antes de habilitar.
2

Nivel de registro correcto

registration está configurado (none / recommended / required). Un país required bloquea el tráfico no registrado en el momento del envío, por lo que una revisión de registro omitida significa envíos fallidos, no retrasados.
3

Campos de prosa revisados

stop_requirement y content_restrictions dicen lo que deben decir — los feeds solo actualizan la estructura, por lo que la prosa debe ser establecida por un operador.
4

Tipo de remitente aceptado

Al menos uno de los sender_types del país coincide con aquel desde el que planea enviar.
5

Puertas relacionadas cargadas

Si el destino tiene una puerta RND o DLT (RND de EE. UU., DLT de India), confirme que ese feed también está cargado — vea Escrutinio de desactivación y Onboarding de DLT-India.

Referencias relacionadas