Cómo funciona
La interconexión no es un trámite que se firma y se archiva: es un servicio que queda operando. Esto es lo que sucede en cada paso, y quién es responsable de cada parte.
Todo empieza con un Folio Único de Búsqueda y termina, en el mejor de los casos, con un indicio que la autoridad no tenía.
La pregunta que importa al evaluar este servicio no es cómo está construido, sino cuánto tiempo del equipo de la institución consume y qué queda bajo su responsabilidad.
En resumen: cuatro tareas del lado de la institución, todas administrativas y todas de una sola vez. Ninguna requiere desarrollo.
La modalidad se elige según dónde reside hoy el padrón, no al revés.
PostgreSQL, MySQL o SQL Server, con un usuario de solo lectura sobre las tablas que la institución determine. Basta con autorizar nuestra IP fija en el firewall: la búsqueda continua opera sobre datos vivos y no sobre una copia que envejece.
SOFOMES, hospitales, universidades, paqueterías.
Si su sistema ya expone una consulta por CURP, la utilizamos. El padrón nunca sale de su infraestructura y la institución determina exactamente qué campos devuelve.
Telecom, aerolíneas, plataformas con backend propio.
Se descarga la plantilla, se completa con el padrón y se carga en el portal. Sin servidores, sin firewall y sin equipo técnico. Es la vía para quien hoy lleva el registro en hojas de cálculo.
Escuelas, albergues, clínicas pequeñas, asociaciones.
De diez a quince días hábiles en un caso ordinario. El plazo lo marca la inscripción en Llave MX, no la parte técnica.
Revisamos a qué sector pertenece la institución, qué contiene su padrón y si captura CURP. De ahí sale la modalidad de conexión y la cotización en firme.
Es el paso que más suele demorar, y no depende de tecnología sino de que la e.firma de la persona moral esté vigente ante el SAT. Acompañamos el trámite; el representante legal es quien firma.
Se crea la configuración en el portal con el RFC de la institución. El asistente genera las cuatro URLs sobre su subdominio y valida la conexión al padrón antes de guardar.
RENAPO exige superar pruebas de conectividad y funcionales antes de producción. Se ejecutan contra el endpoint de reporte de prueba, sin tocar datos reales.
Se remiten los reportes SAST, DAST y SCA sobre la URL Base, con evidencia de ausencia de vulnerabilidades críticas, altas, medias y bajas. Los emitimos nosotros.
A partir de aquí la institución recibe reportes reales. Las fases 1 y 2 se ejecutan al instante y la fase 3 queda corriendo de forma permanente.
Esta es la parte que suele sorprender: una vez en producción, la institución no tiene que hacer nada de forma rutinaria. El servicio opera solo y sólo aparece cuando hay algo que reportar.
La PUI llama una sola vez y sin reintento garantizado. Si el servicio estuvo fuera de
línea, esos reportes no vuelven a anunciarse por sí solos. Por eso reconciliamos contra
GET /reportes de forma periódica y también cada vez que el servicio arranca:
se recupera lo que se perdió y se cierra lo que la PUI ya dio de baja.
El otro punto de falla es administrativo y no técnico: si la e.firma de la persona moral vence, RENAPO revoca los tokens de producción y la institución deja de recibir reportes sin notificación previa. Vigilamos ese vencimiento y avisamos con anticipación.
Con saber a qué sector pertenece y dónde reside su padrón podemos indicarle la modalidad que corresponde, el plazo estimado y el costo.