¶ 1. Introducción
La presente guía técnica tiene por finalidad desarrollar los aspectos operativos y procedimentales necesarios para la correcta implementación de la Norma Técnica de Notificaciones establecida por el Decreto N° 8, de 2023.
Esta guía no crea obligaciones adicionales para los órganos de la Administración del Estado.
¶ 2. Glosario
- Plataforma Casilla Única: Sistema electrónico desarrollado por la Secretaría de Gobierno Digital que permite la emisión, recepción y gestión de mensajes, comunicaciones y notificaciones electrónicas. La plataforma dispone de dos ambientes diferenciados: un módulo institucional, destinado a las Entidades Usuarias para el envío y gestión de las notificaciones, comunicaciones y mensajes, y un ambiente ciudadano, destinado a las personas usuarias para la recepción y consulta de dichos mensajes, comunicaciones y notificaciones.
- DDU: Medio electrónico establecido para recibir las notificaciones electrónicas en un procedimiento administrativo, el cual consiste en la Casilla Única.
- Usuario/a: Persona natural que utiliza la Plataforma de Notificaciones para recibir notificaciones a través de dicho medio.
- Entidad Usuaria: Institución integrada a la Plataforma Casilla Única y que la utiliza para enviar comunicaciones, mensajes y/o notificaciones electrónicas.
- SGD: Secretaría de Gobierno Digital.
¶ 3. Visión general
¶
3.1 ¿Qué es la Casilla Única?
La Casilla Única es la plataforma electrónica desarrollada por la Secretaría de Gobierno Digital que permite a los órganos de la Administración del Estado enviar mensajes, comunicaciones y notificaciones electrónicas a las personas, centralizando su recepción en un Domicilio Digital Único (DDU).
El acceso a la Casilla Única se realiza mediante autenticación a través de ClaveÚnica
¶ 3.2 Usos de la plataforma
La plataforma permite:
- Envío de mensajes y comunicaciones institucionales, de carácter informativo o funcional, destinados a facilitar la relación entre la Administración y las personas, tales como avisos de interés público, información sobre beneficios o recordatorios de trámites. Este tipo de mensajes podrá enviarse sin requerir el consentimiento previo de la persona usuaria.
- El uso de Casilla Única para la práctica de notificaciones electrónicas dependerá del grado de obligatoriedad aplicable a cada entidad, conforme a la gradualidad establecida en el DFL N° 1 de 2020, del Ministerio Secretaría General de la Presidencia:
- Una vez vigente la respectiva fase de implementación, las entidades deberán practicar las notificaciones electrónicas a través de la Casilla Única, sin requerir el consentimiento previo de la persona usuaria, salvo las excepciones previstas en la ley.
- Mientras no resulte exigible la notificación electrónica, el uso de la plataforma tendrá carácter voluntario y requerirá el consentimiento previo del interesado.
Los órganos de la Administración del Estado cuentan con dos mecanismos no excluyentes para practicar notificaciones electrónicas a través de la Plataforma Casilla Única:
- Mediante la interfaz web del módulo institucional; y
- De manera automática, a través de la integración vía API de notificaciones.
En ambos casos, previo al envío de la primera notificación, la institución debe encontrarse debidamente configurada en la plataforma, conforme al proceso de integración y configuración institucional descrito en esta guía.
¶ 4. Arquitectura general y ambientes de la plataforma
¶
4.1 Arquitectura general
La plataforma dispone de dos ambientes diferenciados:
- Un módulo institucional, destinado a las Entidades Usuarias para el envío y gestión de las notificaciones, comunicaciones y mensajes.
- Un ambiente ciudadano, destinado a las personas usuarias para la recepción y consulta de dichos mensajes, comunicaciones y notificaciones.
¶ 4.2 Componentes principales
Son componentes de la plataforma:
- Casilla Única: Componente que constituye el Domicilio Digital Único, permitiendo a un(a) usuario(a) acceder y visualizar las notificaciones que haya recibido en un procedimiento administrativo, en la bandeja de mensajes. Por medio de ésta, la persona usuaria podrá acceder en forma centralizada a sus notificaciones recibidas desde la Administración del Estado.
- Módulo institucional: Componente que permite a cada órgano de la Administración del Estado:
- Realizar el envío de notificaciones electrónicas a los(as) interesados(as), sus apoderados(as) o sus representantes, según corresponda.
- Consultar el estado de las notificaciones enviadas a los(as) interesados(as), sus apoderados(as) o sus representantes, según corresponda.
- Incorporar información a la Plataforma de Notificaciones sobre solicitudes de notificación en forma diversa a medios electrónicos, así como el pronunciamiento del correspondiente órgano de la Administración del Estado al respecto. Cuando la solicitud sea acogida, se enviará dicha información al Registro de DDU.
- Componente de envío de mensajes: Permite enviar las notificaciones a la Casilla Única.
- API de notificaciones: Servicio web que permite a los órganos de la Administración del Estado integrar sus plataformas electrónicas al componente de envío de mensajes para gestionar el envío de notificaciones de manera automática.
- Módulo de administración del DDU: Permite a las personas configurar su DDU en cualquier momento, accediendo a través del portal web de la Plataforma de Notificaciones.
¶ 4.3 Ambiente institucional
El ambiente institucional corresponde a la interfaz destinada a las Entidades Usuarias y presenta las siguientes características:
- Uso preferente en entornos de escritorio (desktop).
- Acceso restringido a usuarios con rol o perfil previamente creado.
- Cada usuario puede tener asignado un único rol.
- Control de acceso a funcionalidades según rol autorizado.
¶ 4.4 Ambiente ciudadano
El ambiente ciudadano corresponde a la interfaz destinada a las personas usuarias y considera, entre otros, los siguientes elementos:
- Aviso de nuevos mensajes mediante correo electrónico configurado por el usuario.
- Posibilidad de modificar el correo de aviso con posterioridad a la activación.
- Bandejas de mensajes: entrada, archivados y destacados.
- Búsquedas, filtros y paginación de mensajes.
- Interfaz optimizada para dispositivos de escritorio y móviles.
- Cumplimiento de criterios de accesibilidad (navegación por teclado y herramientas de apoyo).
¶ 4.5 Características generales de funcionamiento
La plataforma presenta, entre otras, las siguientes características generales:
- Autenticación mediante ClaveÚnica.
- Escalamiento progresivo de la capacidad de envío según uso y demanda.
- Límite máximo total de archivos adjuntos por mensaje de 20 MB.
- Identificación de los mensajes mediante logo y firma institucional.
- Envío de correos electrónicos asociados a hitos relevantes efectuados en la plataforma (activación, validación de correo de aviso configurado, nuevo mensaje recibido).
- Registro de auditoría de todas las acciones realizadas por ciudadanos y funcionarios.
- Cierre automático de sesión por inactividad.
- Protección del contenido de los mensajes mediante mecanismos de encriptación.
¶ 5. Roles y responsabilidades
En el ambiente institucional existen los siguientes roles:
- Administrador general: Rol ejercido por la Secretaría de Gobierno Digital, responsable de la administración global de la plataforma.
- Administrador institucional: Funcionario de la institución que se encargará de realizar la configuración de su institución. Pueden existir más de uno por institución.
- Administrador de mensajes: Funcionario de la institución que se encargará del envío de mensajes. Pueden existir más de uno por institución.
- Equipo Técnico / TI: Responsable de la integración y operación de la API, cuando corresponda.
¶ 6. Proceso de integración institucional
¶
6.1 Requisitos previos
Antes de solicitar la integración a la plataforma, la institución debe:
- Contar con un Coordinador o Coordinadora de Transformación Digital designado oficialmente.
- Asegurar que los funcionarios y funcionarias que utilicen la plataforma dispongan del mecanismo oficial de autenticación ClaveÚnica.
- Designar al equipo de contacto institucional, que incluya: un contacto técnico, un contacto de negocio y un administrador institucional.
- Definir su modalidad de integración (web, API o ambas). También puede elegir enviar la notificación a través de un proceso de negocio de su institución diseñado en la herramienta SIMPLE.
¶ 6.2 Solicitud de integración
La solicitud de integración se realiza a través del formulario correspondiente en CeroFilas, seleccionando la opción “Solicitud de integración a la Plataforma de Notificaciones”.
En el formulario de la solicitud se debe indicar la siguiente información:
- Institución Solicitante
- Datos de contacto administrativo
- Datos del administrador institucional en la plataforma
- Indicar tipo de integración: Manual - Vía API - Ambas
- Datos de contacto técnico (si la integración es con API o ambas)
- Para integración vía API debe indicar:
- Nombre y descripción de la aplicación que se integra
- URL de la Aplicación (opcional)
Antes de enviar el formulario es importante que sean leídos los términos y condiciones para las instituciones.
¶ 6.3 Evaluación de la solicitud
La SGD evalúa todas las solicitudes de integración, verificando que:
- Los datos solicitados estén completos.
- Los correos electrónicos proporcionados en el formulario sean institucionales.
- La institución no se encuentre previamente integrada.
Si la solicitud cumple con los requisitos, la SGD la acepta, habilita a la institución en ambiente de pruebas y envía un correo con la información necesaria para ingresar al ambiente a este ambiente.
Si la solicitud no es aprobada, se rechaza y la institución debe presentar una nueva solicitud si desea integrarse a la Plataforma de Notificaciones.
¶ 6.4 Ambiente de pruebas
Una vez aceptada la solicitud, la institución será habilitada en ambiente de pruebas, donde deberá:
- Configurar su institución: incluir logo, firma y procedimiento administrativo.
- Designar y crear al administrador de mensajes.
- Realizar envíos de prueba.
El objetivo es que la institución pueda interactuar con la plataforma y aclarar dudas, antes de llegar a producción; y pueda realizar la acción principal que es el envío de un mensaje.
¶ 6.5 Solicitud de certificación
La institución debe continuar el flujo iniciado en cero filas y presentar una solicitud para que certifiquen el trabajo realizado en el ambiente de pruebas. Cuando la institución haya realizado las actividades descritas en el punto anterior, debe continuar el flujo de la solicitud de integración a la plataforma de notificaciones ingresando a CeroFilas.
En su bandeja encontrará la solicitud de integración realizada, con el estado “Solicitud de Certificación”, debe hacer click en el botón “Realizar”, se mostrará los datos de la solicitud Ingrese la solicitud y si es necesario, agregue en los comentarios los detalles de la solicitud que el equipo de SGD debe tener en cuenta durante la evaluación.
La Secretaría de Gobierno Digital (SGD), evalúa la Solicitud de Certificación asegurándose que las actividades descritas en el punto 6.4 de este documento, se hayan completado:
- Si hay algún inconveniente, la certificación no será aprobada y se enviará un correo con las observaciones de la evaluación. Una vez corregidas, la institución debe realizar una nueva Solicitud de Certificación.
- Si la solicitud de certificación es aprobada, se enviará un correo con la respuesta de la solicitud de certificación y con los detalles e información necesarias para continuar el proceso de habilitación en producción.
Si requiere enviar notificaciones a través de la API, debe hacerlo a través del nodo de PISEE en producción. Esto permitirá integrarse al modelo de interoperabilidad, donde su nodo consumidor podrá acceder a los servicios de envío de mensajes de la Plataforma de Notificaciones.
¶ 6.6 Habilitación en producción
Aprobada la certificación, la Secretaría de Gobierno Digital habilitará a la institución en ambiente de producción para su operación regular.
Si el tipo de integración que solicitó la institución es a través de API, la institución debe solicitar nodo PISEE a través de la mesa de servicios de la SGD; si su institución ya cuenta con un nodo productivo:
- La SGD autorizará ese nodo para que consuma los servicios de la plataforma de notificaciones.
- La institución ajustará su nodo para que consuma los servicios de la plataforma de notificaciones, ver manual de integración
- El equipo de PISEE evalúa si es necesario enviar una nueva versión del nodo.
A continuación, se muestra un gráfico con un resumen del proceso de integración a la plataforma de Notificaciones utilizando CeroFilas.
Para más detalle de cada paso, puede ingresar al manual de integración en el siguiente enlace: Manual_integracion_Notificaciones_SGD
¶ 6.7 Configuración institucional inicial
Previo al envío de notificaciones, el administrador institucional deberá realizar las siguientes configuraciones:
- Carga del logo institucional. Se muestra en todos los mensajes enviados. Su uso es obligatorio para enviar una notificación,
- Creación y gestión de firmas institucionales. Se muestra en los mensajes enviados por la institución, dependiendo de la firma que se seleccione al momento del envío del mensaje.
- Habilitación o deshabilitación de procedimientos para notificación.
- Creación de usuarios con rol de administrador de mensajes. Si la institución va a operar a través de la web o solo necesita ver los mensajes que se han enviado desde la API, entonces debe crear usuarios con el rol de administrador de mensajes.
Puede encontrar más detalles de cómo realizar las opciones de configuración en el manual de integración.
¶ 7. Envío y gestión de notificaciones
Esta sección describe los datos requeridos para el envío de notificaciones electrónicas, los mecanismos disponibles para su envío (interfaz web y API), y las funcionalidades asociadas a la gestión, trazabilidad, excepciones y soporte.
¶ 7.1 Datos requeridos para el envío de una notificación
Algunos de los datos asociados a una notificación son obtenidos automáticamente desde plataformas institucionales integradas, mientras que otros deben ser proporcionados por la institución al momento del envío.
Datos obligatorios del mensaje
Todo mensaje enviado desde la plataforma, ya sea por interfaz web o mediante API, debe considerar los siguientes datos:
- Institución remitente: corresponde a la institución a la cual pertenece el funcionario que realiza el envío.
- Tipo de mensaje: por defecto, los mensajes enviados son de tipo Notificación electrónica. Podrán habilitarse los tipos Comunicado personal y Comunicado institucional, previa autorización de la Secretaría de Gobierno Digital.
- Destinatario(s): identificado(s) mediante RUN.
- Mensaje simple: hasta 50 destinatarios.
- Mensaje múltiple y API: hasta 250 destinatarios.
- Asunto: título descriptivo del mensaje, con un máximo de 150 caracteres.
- Contenido: cuerpo del mensaje que se desea comunicar.
- Documentos adjuntos (opcional): archivos incorporados al mensaje, los cuales deben cumplir las condiciones definidas por la plataforma.
¶ 7.2 Envío de notificaciones
¶ a) Desde la interfaz web
Las instituciones pueden practicar notificaciones electrónicas mediante la interfaz web de la plataforma. Antes de realizar el primer envío, la institución debe haber completado su configuración inicial.
Gestión de destinatarios
Los destinatarios pueden incorporarse:
- De forma manual, o
- Mediante carga de archivo en formato CSV (opción disponible únicamente en la interfaz web).
En ambos casos se validará que sea un RUN válido.
Contenido del mensaje
El usuario debe definir:
- Asunto
- Contenido del mensaje.
- Firma institucional .
Esta información puede obtenerse desde una plantilla o borrador previamente creado.
Archivos adjuntos
Los mensajes pueden incluir archivos adjuntos, cumpliendo las siguientes condiciones:
- Hasta 50 archivos por mensaje.
- Tamaño máximo total de 20 MB.
- Formatos permitidos: PDF (con firma electrónica simple o avanzada), JPG, PNG, DOC, DOCX, XLS y XLSX.
- En el caso de archivos PDF firmados, la plataforma valida la firma electrónica y la integridad del documento.
¶ b) Envío de notificación desde la API
La API de notificaciones permite a las instituciones automatizar el envío y la consulta de notificaciones desde sus sistemas internos. Las validaciones aplicadas a los mensajes enviados mediante API son las mismas que las aplicadas a los mensajes enviados desde la interfaz web.
Para utilizar la API, la institución debe contar con:
- Un nodo de interoperabilidad PISEE 2.
- Un client_id y un client_secret asociado a la institución que desea utilizar la plataforma.
La API cuenta con un método para poder realizar el envío y otros que son de apoyo para esta tarea. Puede encontrar más detalles del envío de notificaciones desde la API, haga clic aquí.
Las reglas de validación, límites y formatos aplicables al envío de notificaciones mediante la API son equivalentes a las descritas para el envío desde la interfaz web, salvo que se indique expresamente lo contrario.
Endpoint de envío de mensajes
Para el envío de notificaciones, se debe configurar y consumir el siguiente endpoint:
URL: /notificador/sendMessage
Tipo de llamada: POST
La solicitud debe enviarse como multipart/form-data con dos partes posibles:
data: Una cadena JSON que contiene los datos de la notificación que se desea enviar.
attachments: Archivos adjuntos opcionales (se permiten múltiples archivos)
data (objeto JSON)
attachments (archivos adjuntos)
Enlaces dentro del contenido del mensaje
Para colocar un enlace dentro del contenido del mensaje, se debe añadir la etiqueta html que permite añadir enlaces a otras páginas en internet, debe especificar en el atributo target que debe Cargar la URL en una nueva pestaña, ejemplo:
<a href="https://digital.gob.cl" target="_blank">Enlace</a>
Resultado
Una vez ejecutada la llamada, y si todo está correcto, el endpoint retorna el código HTTP 200 y como respuesta un JSON con los siguientes valores:
message_data_id: Corresponde al ID del envío.
sent_at: Fecha de envío.
status: Corresponde al estado del envío.
{
"message_data_id": "630c7a94ee5a2dbd341d23ff7",
"sent_at": "Mon, 14 Jun 2023 15:09:03 GMT",
"status": "pending"
}
Ejemplo de respuesta después de enviar un mensaje
Manejo de errores
El contenido del mensaje que se envía desde la API debe tener datos válidos para la institución que está realizando el envío, se realizan validaciones y si hay algún error no se realiza el envío. Cuando un mensaje no puede ser enviado por las validaciones realizadas en los datos, se muestra la siguiente información:
errors: muestra los errores encontrados, muestra el código y una descripción del error.
message: resumen del estado del envío.
{
"errors": [
{
"code": "ERR007",
"message": "Código de procedimiento administrativo no válido"
}
],
"message": "Falló la validación de los datos de entrada"
}Ejemplo de respuesta después de enviar un mensaje con error
¶ 7.3 Consulta de estado y trazabilidad de notificaciones
La plataforma dispone de endpoints para consultar el estado de las notificaciones enviadas y su situación por destinatario.
Consulta de estado de un mensaje
messageStatus
Para ver el estado de una notificación enviada, se debe configurar y consumir el siguiente endpoint:
URL: /notificador/messageStatus/{message_data_id}
Tipo de llamada: GET
El parámetro a configurar en esta llamada es el siguiente:
message_data_id: El ID del envío generado a través del endpoint de envío de notificaciones. Corresponde al valor message_data_id que fue retornado como respuesta en el endpoint de envío de notificaciones (/notificador/sendMessage).
Una vez ejecutada la llamada, el endpoint retorna como respuesta un JSON con los siguientes valores:
message_data_id: Corresponde al ID del envío.
entity_id: ID de la institución.
recieved_at: Fecha de recepción del mensaje por parte de la plataforma.
status: Estado actual del envío.
subject: Asunto del envío.
recipents_count: Cantidad de destinatarios del envío.
recipients: Objeto que contiene roles únicos de destinatarios como llave y como contenido una estructura con los atributos:
- ddu_type: Corresponde al tipo de configuración del DDU al momento de recibir el mensaje (casilla, email, not_configured o excepcion).
- message_status: Corresponde al estado del mensaje, al momento de efectuar la consulta del endpoint messageStatus. Los valores posibles son delivered, error, pending, de acuerdo a lo definido en la tabla 4
- method: Corresponde al método empleado para enviar el mensaje (WEB o API).
- delivered_at: Corresponde a la fecha de envío del mensaje.
- read_at: Corresponde a la fecha de lectura del mensaje. Si el valor es null significa que el mensaje aún no ha sido leído por el destinatario.
{
"entity_id": "794a0088-cec0-11eb-b8bc-0242ac130003",
"message_data_id": "60c7a94ee5a2dbd341d23ff7",
"received_at": "Wed, 24 Aug 2022 15:59:23 GMT",
"status": "processed",
"subject": "Asunto de ejemplo",
"recipents_counts": 5,
"recipients"{
"10936746": {
"ddu_type": "not_configured",
"message_status": "delivered",
"method": "API",
"delivered_at": "Wed, 24 Aug 2022 15:59:23 GMT",
"read_at": null
},
"16409277": {
"ddu_type": "casilla",
"message_status": "delivered",
"method": "API",
"delivered_at": "Wed, 24 Aug 2022 15:59:23 GMT",
"read_at": "Mon, 14 Jun 2021 15:09:03 GMT"
},
"17353548": {
"ddu_type": "email",
"message_status": "delivered",
"method": "API",
"delivered_at": "Wed, 24 Aug 2022 15:59:23 GMT",
"read_at": null
},
"21175730": {
"ddu_type": "excepcion",
"message_status": "delivered",
"method": "API",
"delivered_at": "Wed, 24 Aug 2022 15:59:23 GMT",
"read_at": null
},
"16472149": {
"ddu_type": "email",
"message_status": "error",
"method": "API",
"delivered_at": "Wed, 24 Aug 2022 15:59:23 GMT",
"read_at": null
}
}
}
Ejemplo de respuesta de estado de un mensaje para diferentes destinatarios
Consulta de notificaciones pendientes de un ciudadano
citizenPending
Endpoint que se dispone para mostrar el listado de notificaciones pendientes de lectura en los portales de los OAE. Para ver los mensajes pendientes de un ciudadano, se debe configurar y consumir el siguiente endpoint:
URL: /notificador/citizenPending/{rol-unico}
Tipo de llamada: GET
El parámetro a configurar en esta llamada es el siguiente:
rol-unico: Rol único del ciudadano del cual se hace la consulta.
Una vez ejecutada la llamada, el endpoint retorna como respuesta un JSON con los siguientes valores:
access_url: Ruta directa a la bandeja de mensajes de ciudadanos.
current_ddu_type: estado actual del DDU del ciudadano.
result_message: Mensaje con resumen del resultado de la consulta de acuerdo a si el ciudadano tiene o no mensajes pendientes por leer.
status: estado de la consulta.
total_pending: Cantidad de mensajes que se encuentran en estado “pending” por parte del ciudadano.
messages: Objeto que contiene roles únicos de destinatarios como llave y como contenido una estructura con los atributos:
- ddu_type: Corresponde al tipo de configuración DDU que tenía el destinatario al momento que se le envió el mensaje (casilla, email, not_configured o excepcion).
- delivered_at: Fecha de envío del mensaje.
- entity_id: ID de la institución.
- message_data_id: ID interno del mensaje.
- message_status: Corresponde al estado del mensaje, al momento de efectuar la consulta del endpoint citizenPending. Los valores posibles son delivered, error, pending, de acuerdo a lo definido en la tabla 3
- message_url: Ruta directa al mensaje en la bandeja del ciudadano.
- method: Corresponde al método empleado para enviar el mensaje (WEB o API).
- recieved_at: Fecha de recepción del mensaje por parte de la plataforma.
- subject: Corresponde al asunto del mensaje.
{
"access_url": "https://portal.devel.casillaunica.gob.cl/ext/bandeja",
"current_ddu_type": "casilla",
"messages": [
{
"ddu_type": "not_configured",
"delivered_at": "Mon, 26 Dec 2022 16:42:18 GMT",
"entity_id": 1,
"message_data_id": "63a9f918b8543666dba6ed9b",
"message_status": "delivered",
"message_url": "https://portal.devel.casillaunica.gob.cl/bandeja/mensaje/?id=63a9f918b8543666dba6ed9b&institution=Banco%20del%20Estado&uri=inbox",
"method": "web",
"received_at": "Mon, 26 Dec 2022 16:42:16 GMT",
"subject": "prueba"
},
{
"ddu_type": "casilla",
"delivered_at": "Tue, 25 Jul 2023 22:44:42 GMT",
"entity_id": 1,
"message_data_id": "64c05057032d99f98be83b55",
"message_status": "delivered",
"message_url": "https://portal.devel.casillaunica.gob.cl/bandeja/mensaje/?id=64c05057032d99f98be83b55&institution=Banco%20del%20Estado&uri=inbox",
"method": "api",
"received_at": "Tue, 25 Jul 2023 22:44:39 GMT",
"subject": "PRUEBA-API-25Jul-1845- bancoestado"
}
],
"result_message": "Usuario tiene mensajes pendientes por leer en su casilla",
"status": true,
"total_pending": 11
}
Ejemplo de respuesta a consulta de mensajes en estado pendiente para un destinatario
¶ 7.4 Servicios de apoyo disponibles en la API
La API dispone de endpoints adicionales para apoyar la operación institucional, entre ellos:
getProcedure
Para conocer los códigos de los procedimientos administrativos asociados a la institución con la cual quiero enviar algún mensaje, es necesario consumir el siguiente endpoint:
URL: /notificador/getProcedure
Tipo de llamada: GET
Una vez ejecutada la llamada, el endpoint retorna como respuesta un JSON con los siguientes valores:
procedures: Objeto que contiene una lista de procedimientos administrativos con los atributos:
name: Nombre del procedimiento administrativo.
code: Código del procedimiento administrativo.
stage: Etapa del procedimiento administrativo como número.
stage_name: Etapa del procedimiento administrativo como string.
{
"procedures": [
{
"code": "PA-SER0000-5463",
"name": "Licitación Pública",
"stage": 1,
"stage_name": "Etapa de inicio"
},
{
"code": "PA-SER0000-5463",
"name": "Licitación Pública",
"stage": 3,
"stage_name": "Etapa de finalización"
}
]
}
Ejemplo de respuesta a consulta de procedimientos administrativos
getSignature
Para conocer los UUID de las firmas institucionales con la cual quiero enviar algún mensaje, es necesario consumir el siguiente endpoint:
URL: /notificador/getSignature
Tipo de llamada: GET
Una vez ejecutada la llamada, el endpoint retorna como respuesta un JSON con los siguientes valores:
signatures: Objeto que contiene una lista de firmas institucionales con los atributos:
name: Nombre de la firma institucional.
code: Código de la firma institucional.
body: Contenido de la firma institucional.
updated_at: Fecha de la última modificación de la firma institucional.
{
"signatures": [
{
"body": "<p style="line-height: 24px; margin: 0px; padding: 0px; border: 0px; color: #373737;"><strong><span style="font-family: Roboto; font-size: 16px;">Enrique González Muñoz</span></strong><br /><em><span style="font-family: Roboto; font-size: 16px;">QA - Gobierno Digital </span><br /></em><br /><em><span style="font-family: Roboto; font-size: 16px;">Subsecretaria de Hacienda</span></em><br /><strong><em><span style="font-family: Roboto; font-size: 16px;">Ministerio de Hacienda</span></em></strong><br /><br /><br /></p>",
"name": "Firma Enrique",
"uid": "46e497de-8724-4a4d-befb-331486c70ba9",
"updated_at": "Mon, 20 Dec 2024 16:42:18 GMT"
},
{
"body": "<p style="line-height: 24px; margin: 0px; padding: 0px; border: 0px; color: #373737;"><strong><span style="font-family: Roboto; font-size: 16px;">Dirección de Arquitectura</span></strong><br /><em><span style="font-family: Roboto; font-size: 16px;">Subsecretaria de Hacienda</span></em><br /><br /><br /></p>",
"name": "Firma institución",
"uid": "483ef791-7253-46a0-997c-afd8d089cc26",
"updated_at": "Mon, 20 Dec 2024 10:42:18 GMT"
}
]
}Ejemplo de respuesta a consulta de firmas institucionales
getReceipt
Para obtener un comprobante de mensajes desde la API es necesario consumir el siguiente endpoint:
URL: /notificador/getReceipt/{message_data_id}/{rol_unico}
Tipo de llamada: GET
El parámetro a configurar en esta llamada es el siguiente:
message_data_id: El ID del envío generado a través del endpoint de envío de notificaciones. Corresponde al valor message_data_id que fue retornado como respuesta en el endpoint de envíos (Sección 3.6).
rol_unico: Rol único del ciudadano del cual se quiere obtener el comprobante.
Una vez ejecutada la llamada, el endpoint retorna como respuesta un JSON con los siguientes valores:
url: Dirección desde la cual se puede descargar el comprobante de mensajes.
{
"url": "https://s3-153795248828-ms-message-devel.s3.amazonaws.com/statistics/certificate/comprobante_envio_21131064_20241226T1848.pdf?AWSAccessKeyId=AKIASHTXJIK6CTPBY5GM&Signature=NXClYleRHwuChA36GIXr0b31Wkg%3D&Expires=1735249783"
}
Ejemplo de respuesta a consulta de certificado de mensajes
Nivel de transacciones en la API
La API y todos sus servicios estarán disponibles 24 x 7 con un máximo de 4 TPS.
¶ 7.5 Estado de notificaciones enviadas
Las notificaciones que se han enviado, desde la plataforma web y desde la API, se pueden ver en el listado de mensajes enviados, en la opción del menú “Mensajes enviados”. Desde allí podrá acceder a un listado de los mensajes que ha enviado la institución y podrá ver el detalle de cada uno haciendo click en cualquiera de ellos. La plataforma maneja 3 estados de envío:
- Enviado, mensaje enviado correctamente.
- En proceso, el mensaje se encuentra en proceso de envío.
- Con error, la plataforma tuvo problemas para realizar el envío del mensaje.
Por defecto, el listado de mensajes enviados muestra los registros de los últimos 30 días, pudiendo aplicarse filtros de búsqueda.
¶ 7.6 Registro de excepciones a la notificación electrónica
El administrador institucional podrá registrar excepciones a la notificación electrónica para ciudadanos que lo soliciten, conforme a lo dispuesto en la Ley N° 19.880 y su normativa complementaria.
En el módulo de excepción de la plataforma, el funcionario debe registrar la solicitud en un formulario, indicando los datos del solicitante, los motivos de excepción y adjuntando los documentos de respaldo. Este registro viene a dar cuenta de una solicitud efectuada por parte del interesado, ante el órgano de la Administración del Estado donde está tramitando un procedimiento administrativo (Norma técnica de notificaciones, artículo 8). El usuario debe cumplir con los casos descritos en los artículos 28 y 29 del Reglamento.
El formulario de registro de excepción se compone de lo siguiente:
- RUN: ingreso del RUN, según corresponda de la persona que solicitó y fue aprobada la excepción a la recepción de notificaciones electrónicas.
- Correo electrónico: se ingresa el correo electrónico del solicitante.
- Teléfono: se ingresa el número de teléfono del solicitante.
- Dirección: se ingresa la dirección completa del solicitante.
- ID expediente electrónico: se ingresa el ID de la carpeta virtual del ciudadano. Es de uso interno y es opcional.
- Fecha de solicitud: se ingresa la fecha que se realizó la solicitud de excepción.
- Motivo: se selecciona de una lista desplegable, el motivo por el cual se solicita el registro de excepción, donde se dispone de varias opciones ya predefinidas.
- Otros motivos: en caso de seleccionar “Otros motivos” en el punto anterior, se despliega este campo donde se ingresa un texto explicativo del motivo de excepción.
- Seleccionar Archivos: botón que al presionar, se despliega el explorador de archivos del equipo, donde se puede elegir los documentos de soporte para el registro de excepción, una vez elegidos estos archivos, quedarán registrados dentro del formulario.
- Botón “Cancelar”: botón que permite al usuario cancelar la solicitud de excepción, regresando a la pantalla de Inicio sin realizar ningún cambio.
- Botón “Aprobar”: botón que permite al usuario aprobar la solicitud de excepción del ciudadano solicitante, quedando este en estado de “Excepción”.
¶ 7.7 Constancia de envío de notificaciones y de indisponibilidad de la plataforma
La plataforma permite descargar certificados o comprobantes, ambos son constancias de que se ha enviado un mensaje a un destinatario, es un documento en formato pdf con la fecha y hora y datos del envío de ese mensaje. Se podrá obtener desde la plataforma web y a través de la API. El certificado tiene firma electrónica y puede ser validado.
La opción se encuentra en la pantalla de detalle de mensajes enviados:
Se debe escoger qué tipo de constancia se quiere descargar:
¶ 7.8 Soporte y escalamiento
La mesa de servicios para las instituciones estará a cargo de la SGD. Puede dejar sus solicitudes en el producto Plataforma de Notificaciones de Estado, en el siguiente formulario: https://gobdigitalcl.freshdesk.com/support/home.
Para informar sobre otros inconvenientes en el producto o hacer sugerencias, puede escribir al correo del producto notificador@digitalgob.cl. A continuación se muestra un diagrama con el flujo de atención hacia las instituciones:
Flujo de comunicación en caso que los usuarios de una institución tengan inconvenientes o sugerencias del producto:
