> ## 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. # Documentos KYC y el ciclo de vida del perfil de cumplimiento > Suba los documentos KYC una sola vez, refiéralos por su ID doc_… en perfiles de cumplimiento y registros de Sender ID, y renuévelos antes de que caduquen y bloqueen sus números. # Documentos KYC y el ciclo de vida del perfil de cumplimiento Los mercados regulados no aceptan un simple «confíe en mí»: un operador o regulador exige una prueba de quién es usted antes de permitir que un número de teléfono se active o que un Sender ID transporte tráfico. Orbit modela esa prueba como dos cosas que usted posee: una **biblioteca de documentos** (los archivos en sí) y **perfiles de cumplimiento** (la identidad estructurada que los documentos respaldan). Esta página explica qué captura un perfil, cómo los documentos pasan de la carga a la reutilización y a la renovación, dónde se referencia el mismo documento y cómo detectar una caducidad próxima antes de que le cueste un número. Todos los endpoints siguientes tienen como raíz `https://api.orbit.devotel.io/api/v1/compliance`. Orbit almacena sus documentos, los transmite al operador y muestra su estado de revisión, pero **la aprobación final siempre la concede el operador o el regulador de cada país**, no la plataforma. El suministro y la renovación de los propios documentos queda a su cargo. *** ## Qué es un perfil de cumplimiento Un **perfil de cumplimiento** (`cprof_…`) es un paquete de identidad regulatoria: quién es el usuario final, para qué caso de uso y en qué país. Los operadores revisan el perfil como una unidad: una vez aprobado, cada número o remitente que el perfil cubre puede usarlo. | Campo | Qué captura | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Su etiqueta para el perfil, p. ej. «Números locales de Alemania — Acme GmbH». | | `use_case` | Para qué sirve la identidad: `phone_number_purchase`, `sms_sender_id_alphanumeric`, `sms_10dlc_brand_us`, `sms_10dlc_campaign_us`, `sms_tfv_us`, `whatsapp_business_verification`, `rcs_brand_verification`, `email_domain_verification`, `voice_carrier_kyc`, `other`. | | `country_code` / `countries` | El mercado o los mercados a los que responde el perfil. Obligatorio para los casos de uso de números de teléfono y Sender ID; opcional para los casos independientes del país (WhatsApp, RCS, correo electrónico). | | `end_user_type` | `business` o `individual`: los reguladores aplican reglas de documentación distintas a cada tipo. | | datos estructurados | Los campos tipados que el país solicita (nombre comercial registrado, dirección, identificador fiscal, …), definidos mediante `PUT /compliance-profiles/:id/data`. Compruebe exactamente qué campos requiere un país con el [endpoint de regulatory-preview](/numbers/regulatory-preview) antes de empezar a rellenar. | El estado del propio perfil pasa de `draft` → `pending_review` → `approved` (o `rejected` / `partially_rejected`), y a `expired` cuando se cierra su ventana de validez. Solo un perfil `approved` satisface las comprobaciones de un país. *** ## El ciclo de vida del documento Los documentos viven en una **biblioteca** de ámbito de tenant, separada de cualquier perfil individual. Suba un pasaporte una sola vez y podrá adjuntarlo hoy a un perfil de número de teléfono alemán y reutilizar mañana el mismo archivo para un registro de Sender ID, sin una segunda carga. ### 1. Carga `POST /compliance/documents` acepta una carga `multipart/form-data` y devuelve el ID de biblioteca del documento, que siempre comienza con `doc_`: ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/documents \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -F "type=business_registration" \ -F "country_code=DE" \ -F "file=@/path/to/registration.pdf" ``` | Aceptado | Valores | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Tipos de documento | `id_card`, `passport`, `drivers_license`, `utility_bill`, `bank_statement`, `business_registration`, `vat_certificate`, `lease_agreement`, `proof_of_address`, `power_of_attorney`, `other` | | Formatos de archivo | JPEG, PNG, WebP, PDF | | Tamaño máximo | 10 MB | Los archivos se cifran antes de salir de la API y se conservan en almacenamiento privado; nada de un ID `doc_…` es adivinable ni compartible fuera de su organización. Liste la biblioteca en cualquier momento con `GET /compliance/documents`. ### 2. Referencia por ID `doc_…` Un documento por sí solo es inerte: solo realiza trabajo regulatorio cuando está **adjunto a un perfil** con un rol: ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles/cprof_abc123/documents \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "document_id": "doc_k7f2m9x1ab", "role": "business_doc" }' ``` Los roles (`id_proof`, `address_proof`, `business_doc`, `authorization`, `other`) indican al operador qué requisito satisface el documento. El mismo ID `doc_…` puede desempeñar un rol diferente en un perfil diferente. ### 3. Caducidad Muchos reguladores consideran los documentos obsoletos tras una antigüedad fija: Ofcom en el Reino Unido, la BNetzA alemana y la ARCEP francesa, entre otros, exigen en general que la prueba de identidad o de dirección no tenga más de 3–12 meses. Orbit registra un `expires_at` por documento adjunto; una vez que un documento caduca, deja de contar para los requisitos del país aunque el propio archivo siga en su biblioteca. ### 4. Renovación Renovar es una carga nueva, no una edición: suba el documento de reemplazo, adjúntelo al perfil con el mismo rol y, a continuación, desvincule (y opcionalmente elimine, con `DELETE /compliance/documents/:id`) el caducado. Los perfiles ya `approved` permanecen aprobados mientras usted sustituye el documento; la solicitud se vuelve a revisar en el siguiente uso. La eliminación de un documento se rechaza mientras siga adjunto a cualquier perfil. Desvincúlelo primero de todos los perfiles y luego elimínelo. *** ## Dónde se reutilizan los documentos El ID `doc_…` es el puntero único que comparten tres superficies del producto: 1. **Registro de Sender ID.** Cada entrada de país en [Registro de Sender ID](/compliance/sender-id-registration) lleva `document_refs`: una lista de IDs `doc_…` que respaldan el registro de ese país. La ruta de registro nunca acepta archivos: referencie los IDs de biblioteca que ya cargó, y el mismo documento respalda tantos países como lo acepten. 2. **Vista previa regulatoria de números.** La comprobación de [regulatory-preview](/numbers/regulatory-preview) devuelve `compliance_profile_satisfies: true` solo cuando un perfil cubre todos los campos obligatorios **y** sus documentos adjuntos no están caducados: un documento caducado cambia el indicador a `false` incluso en un perfil por lo demás completo. 3. **Bloqueo en la compra de números.** Comprar un número en un país regulado sin un perfil satisfactorio deja el número en `pending_compliance`: se cobra, pero no se activará hasta que se adjunte un perfil aprobado. Si la fecha límite de verificación del operador pasa mientras el número sigue en espera, el número puede liberarse automáticamente; consulte [Ciclo de vida del número](/numbers/lifecycle) para la liberación y la recuperación. *** ## Supervise la caducidad antes de que le cueste un número Orbit deriva alertas de caducidad por número a partir de las marcas de tiempo que ya almacena: el `expires_at` de cada documento y la fecha límite de verificación del operador en los números en espera en `pending_compliance`. Lea las alertas con: ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/numbers/document-expiry-alerts" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` Cada alerta indica el número, la caducidad vinculante más próxima (`earliest_expiry_at`), si proviene de un documento o de la fecha límite del operador (`earliest_expiry_source`), los días completos hasta que caduca (negativos una vez que ya lo ha hecho) y una `suggested_action`: * `renew` — aún válido pero dentro de su ventana de alerta; cargue el reemplazo ahora. * `renew_or_release` — ya caducado; renueve de inmediato o decida dejar ir el número. La ventana de anticipación por defecto es de 30 días. Ajústela por organización con el ajuste `numbers.document_expiry_alert_days` (1–365 días), o previsualice una ventana diferente de forma puntual con el parámetro de consulta `?days=`. Las filas de respuesta se ordenan por mayor urgencia primero; un inventario en riesgo muy grande se trunca y reporta `truncated: true`, así que estreche la ventana si alcanza el tope. *** ## Propiedad del tenant por diseño La división de responsabilidades es deliberada: | Orbit (la plataforma) | Usted (el tenant) | | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Cifra y almacena cada documento una sola vez, delimitado a su organización. | Aportar documentos veraces y vigentes desde el primer momento. | | Transporta el perfil y sus documentos a cada operador y reporta el estado de revisión por proveedor. | Elegir qué perfiles respalda un documento y con qué rol. | | Señala los documentos próximos a caducar o ya caducados por número. | Cargar reemplazos y volver a adjuntarlos antes de que un documento caduque. | | Aplica las barreras: los remitentes no registrados y los perfiles no satisfechos no activan números ni pasan las comprobaciones de envío. | Mantener exactos los campos estructurados del perfil a medida que cambian los datos de su empresa. | Orbit nunca inventa ni renueva automáticamente documentos de identidad en su nombre: el regulador está verificando *su* identidad, así que una renovación siempre empieza con una nueva carga por su parte. Lo que la plataforma garantiza es que un documento que usted suministra una vez es reutilizable en todas partes donde se acepta, y que verá su caducidad llegar con suficiente antelación para actuar. *** ## Referencias relacionadas * [Registro de Sender ID](/compliance/sender-id-registration): registro por país respaldado por `document_refs`. * [Regulatory Preview](/numbers/regulatory-preview): comprobación de qué campos y documentos requiere un país antes de la compra. * [Ciclo de vida del número](/numbers/lifecycle): qué le ocurre a un número detenido en `pending_compliance`, y la liberación/recuperación. * [Requisitos de cumplimiento por país](/compliance/country-requirements): qué tipos de remitente y documentos acepta cada país. * [Referencia de API → Compliance](/api-reference/endpoints/compliance): esquemas completos de solicitud y respuesta.