¶ Introducción
El presente documento define las consideraciones técnicas, operativas y administrativas relacionadas con el uso de la plataforma de notificaciones, la forma en que se practican las notificaciones electrónicas y los aspectos funcionales relevantes para su correcta operación, así como la aplicación de los mandatos establecidos en la Norma Técnica de Notificaciones Electrónicas.
Esta guía define el proceso de integración de las instituciones a la plataforma de notificaciones. Su objetivo es proporcionar apoyo a las OAE para solicitar su habilitación en la plataforma, configurar su institución y enviar mensajes desde la interfaz web y/o la API en un ambiente de pruebas antes de su integración en producción.
¶ Consideraciones de la versión en marcha blanca
Esta es la primera versión de la plataforma de notificaciones en producción, que opera durante 2025 con instituciones que desean formar parte de esta etapa del producto. Es importante considerar que esta versión:
- No contempla el cambio de configuración de DDU a correo electrónico.
- No incluye flujo de envío a representantes de personas jurídicas.
- El límite para enviar mensajes adjuntos es de 20 MB, en un solo archivo o varios.
¶ Definiciones
Las siguientes definiciones se aplican en el contexto de este documento.
- 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.
- Bandeja de mensajes de la Casilla Única: cuando el DUU se configure como Casilla, se accede a una bandeja de mensajes que reúne todas las notificaciones de los procedimientos administrativos en los que la persona figure como interesada, apoderada o representante. Los mensajes se ordenan según la fecha y órgano de la Administración del Estado que los envió.
- Casilla Única: componente de la Plataforma de Notificaciones que puede configurarse como Domicilio Digital Único, permitiendo al usuario acceder y visualizar las notificaciones recibidas, a través de una Bandeja de Mensajes. Esta funcionalidad ofrece un acceso centralizado a las notificaciones recibidas de parte de los órganos de la Administración del Estado (OAE).
- Domicilio Digital Único (DDU): medio electrónico elegido por un usuario para recibir notificaciones electrónicas en todo procedimiento administrativo. Las opciones disponibles son Casilla o un correo electrónico validado en la plataforma de notificaciones.
- Notificación electrónica: es el acto de comunicar formalmente a su destinatario una resolución. Mensaje enviado a través de la plataforma electrónica de notificaciones, sobre los procedimientos administrativos de los órganos de administración del Estado, en base a un registro único.
- Procedimiento administrativo: es una sucesión de actos trámite, vinculados entre sí, emanados de la Administración y, en su caso, de particulares interesados, que tiene por finalidad producir un acto administrativo terminal.
- Aviso de notificación: correo electrónico definido por el ciudadano cuando su Domicilio Digital Único es la Casilla, el cual le informa cada vez que reciba una notificación en un procedimiento administrativo donde figure como interesado.
- Usuario: Personas naturales o sus apoderados(as), y los(as) representantes de las personas jurídicas o entidades y agrupaciones sin personalidad jurídica, que actúan como interesados(as) en un procedimiento administrativo, así como los(as) funcionarios(as) que acceden a las plataformas electrónicas que soportan procedimientos administrativos o procesos relacionados con estos.
¶ ¿Qué es la plataforma de notificaciones?
Es la plataforma electrónica encargada de registrar a las personas naturales y jurídicas en el Domicilio Digital Único (DDU); y de ejecutar las notificaciones electrónicas de los Órganos de la Administración del Estado (OAE) en el marco de procedimientos administrativos.
¶ ¿Quiénes deben integrarse a la plataforma de notificaciones?
Todos los Órganos de la Administración del Estado (OAE): ministerios, secretarías, servicios, gobernaciones, municipalidades, entre otros, deben practicar notificaciones por medios electrónicos en el marco de sus procedimientos administrativos, utilizando como base la información contenida en el registro único dependiente del Servicio de Registro Civil e Identificación, según lo establece el artículo 46 de la ley N° 19.880, en adelante también “Registro de Domicilios Digitales Únicos” o “Registro de DDU”.
Para ello, los OAE pueden integrarse a la plataforma de notificaciones, para dar cumplimiento al mandato de envío de notificaciones por medios electrónicos a los interesados y apoderados de los procedimientos administrativos.
¶ Proceso de Integración a la Plataforma de Notificaciones
Para utilizar cualquier plataforma o servicio compartido de Gobierno Digital, cada institución debe contar con un Coordinador de Transformación Digital oficialmente designado, quien se encarga de las comunicaciones con la SGD.
Antes de solicitar la integración a la plataforma, la institución debe:
- Contar con un Coordinador o Coordinadora de Transformación Digital oficialmente designado(a).
- Asegurar que los funcionarios y funcionarias que utilicen la plataforma dispongan del mecanismo oficial de autenticación ClaveÚnica.
- Seleccionar el o los procedimientos administrativos que requieren notificación. El Procedimiento Administrativo debe estar cargado en el CPAT. Si no se encuentra publicado, la institución debe informarlo en la próxima apertura de la herramienta.
- Designar al equipo de contacto institucional, que incluya: un contacto técnico, un contacto de negocio y un administrador institucional.
- Definir el medio de envío de las notificaciones. La plataforma permite dos opciones: vía web y vía API, pudiendo seleccionarse una o ambas.
Una vez que la institución cumple con los requisitos mencionados, puede iniciar la solicitud de integración a la Plataforma de Notificaciones, ingresando a CeroFilas. Para ello debe:
- Ingresar una “Solicitud de integración a la Plataforma de Notificaciones” (Instituciones).
- La Secretaría de Gobierno Digital evalúa la solicitud de integración.
- 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 de pruebas.
- Si la solicitud no es aprobada, se rechaza y la institución debe presentar una nueva solicitud si desea intentarlo nuevamente.
- La institución debe realizar las siguientes actividades en el ambiente de prueba:
- Configurar la institución: incluir logo, firma y procedimiento administrativo.
- Designar y crear al administrador de mensajes.
- Enviar mensaje desde la plataforma web y/o API (utilizando el nodo de PISEE, en caso de API).
- Solicitud de certificación, la institución debe continuar el flujo iniciado en cero filas y presenta una solicitud para que certifiquen el trabajo realizado en el ambiente de pruebas.
- Certificación.
- La SGD evalúa las actividades del punto 2-b, y determina si aprueba o rechaza la solicitud de certificación.
- Si la solicitud tiene observaciones por parte de la SGD, la institución deberá realizar las correcciones y presentar una nueva solicitud de certificación (paso 4).
- Si la solicitud es aprobada, se enviará un correo con los datos para que realice la configuración en el ambiente de producción.
- Habilitación en producción, la institución ya está lista para preparar el entorno de notificación, esto quiere decir que ya pueden comenzar a preparar sus notificaciones para ser enviadas a la ciudadanía.
Importante: En la solicitud de integración se incluyen los términos y condiciones de uso de la plataforma para las instituciones. Es fundamental que estos sean revisados para continuar con el proceso. A continuación, se detalla el flujo de integración.
¶ Ingresar solicitud de integración a la Plataforma de Notificaciones
La institución debe estar preparada para integrarse a la plataforma de notificaciones, según lo indicado al inicio del punto 2, una vez lista debe solicitar la integración en el sitio web de CeroFilas de la Secretaría de Gobierno Digital.
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:
- 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.
¶ Evaluar solicitud
La Secretaría de Gobierno Digital (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 presenta inconsistencias, se rechaza y se envía un correo con las observaciones de la evaluación. Para continuar con la integración, la institución debe corregir los errores y presentar una nueva solicitud.
Si la solicitud es aceptada, la SGD habilita a la institución y al administrador institucional en la plataforma, permitiéndoles avanzar en la configuración. La habilitación inicial se realiza en un ambiente de pruebas, donde la institución puede resolver dudas y efectuar un primer envío de mensajes antes de la implementación en producción.
En esta fase, la SGD ejecuta las siguientes acciones en el ambiente de pruebas:
- Registra a la institución en la plataforma.
- Registra al administrador institucional.
- Genera las credenciales para la integración vía API, en caso de que la institución haya seleccionado esta opción en la solicitud.
- Crea un nodo para la integración con la plataforma PISEE, permitiendo el envío de notificaciones a través de la API.
- Envía un correo con toda la información necesaria para que la institución pueda realizar un primer envío de mensajes en el ambiente de pruebas, siguiendo las actividades detalladas en la siguiente sección.
¶ Realizar actividades en ambiente de pruebas
Para cualquier integración que realice un OAE en la Plataforma de Notificaciones, es obligatorio realizar un envío de mensaje en el ambiente de pruebas. Para ello, se deben completar las configuraciones necesarias que permitan operar correctamente en la plataforma.
Configurar la institución
Este proceso, independiente del tipo de integración seleccionado, permite iniciar la operación y se lleva a cabo a través de la interfaz web.
El administrador institucional, designado en el formulario de solicitud, debe acceder a la plataforma utilizando ClaveÚnica y completar las siguientes actividades:
- Ingresar el logo de la institución, este se muestra en todos los mensajes enviados. Su uso es obligatorio para enviar una notificación, este debe cumplir con las siguientes características: dimensiones óptimas entre 80-350 px ancho x 80 px alto, formato PNG o JPG / tamaño máximo 5 MB. Debe ingresar a la opción Configuración/Carga de Logotipo.
- Ingresar una o varias firmas institucionales, esta se muestra en los mensajes enviados por la institución, dependiendo de la firma que se seleccione al momento del envío del mensaje. Aunque es opcional, es recomendable que los mensajes tengan una firma institucional. La firma solo admite texto y no admite imágenes. Debe ingresar a la opción Configuración/crear o editar firma.
- Seleccionar Procedimientos Administrativos que se notificarán. Estos procedimientos que podrán vincularse a una notificación y deben elegirse de la lista de procedimientos que la institución haya cargado en el CPAT (Catálogo de Procedimientos Administrativos y Tramitaciones). Debe ingresar a la opción Administración/Procedimientos administrativos y hacer click en el botón Agregar procedimientos.
Crear 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. Debe ir a la opción Administración/Usuarios.
Envío de mensaje desde la plataforma web y/o API: según lo indicado en la solicitud la institución debe enviar un mensaje desde la interfaz web y/o desde la API.
Para enviar un mensaje a través de la web, el funcionario asignado con el rol de administrador de mensajes debe acceder a la plataforma y realizar el envío; debe ir a la opción Crear mensaje. Para el envío de mensajes a través de la API, se debe realizar a través del nodo de PISSE, puede revisar el punto 4 de este documento “Envío de notificación por parte del OAE desde la API”, allí encontrará detalles para realizar el envío.
Aunque estas actividades se llevan a cabo en un ambiente de pruebas, se sugiere seguir las siguientes recomendaciones para el contenido del mensaje:
- Puede utilizar cualquier RUN válido de persona natural como destinatario; aquí les dejamos dos usuarios de prueba que pueden utilizar: 33333333-3, tiene activado su DDU como casilla y 33333351-1, tiene configuración de DDU Excepcionado.
- Asegurar que el contenido del mensaje sea respetuoso y simule una notificación real.
- Adjuntar archivos, estos deben ser de prueba, evitando incluir información sensible o comprometida.
- Añadir la firma institucional creada.
Si la institución ha optado por la integración a través de la API o por ambas opciones (WEB/API), debe enviar también, un mensaje mediante la integración por API, esto se realizará a través del nodo de PISEE.
- La SGD envía las credenciales de acceso para la institución.
- La SGD envía un nodo PISEE, el cuál debe configurar con las credenciales entregadas para su institución.
El objetivo de las actividades en ambiente de pruebas, es que pueda realizar la configuración y envío de mensajes, desde la interfaz web o API, según la integración que haya solicitado. En la interfaz web puede ver el detalle y estado de los mensajes que ha enviado su institución, y una previsualización de cómo lo verá el ciudadano. Si quiere ver directamente cómo lo recibe y visualiza el destinatario, y utilizó el usuario de prueba para este ambiente, puede ingresar a la CasillaÚnica en ambiente de pruebas, con los siguientes datos:
- Ingrese a la url de pruebas: https://portal.demo.casillaunica.gob.cl/casilla/
- Coloque los datos para la autenticación con claveÚnica de pruebas: RUN 33333333-3 y clave testing. Importante: Solo este usuario tiene acceso a la CasillaÚnica en ambiente de pruebas.
A continuación una vista de un mensaje visto en la bandeja de un ciudadano:
¶ Solicitud de certificación
La revisión se realizará en el ambiente de pruebas, y está enfocada a validar por parte de SGD, si la institución pudo ejecutar todas las actividades del punto anterior. Se espera que la institución haya podido:
- Configurar la institución: Ingresar el logo de la institución, ingresar una o varias firmas institucionales y seleccionar procedimientos administrativos que se notificarán
- Crear al administrador de mensajes.
- Enviar mensaje a través de la plataforma web y/o API.
Cuando la institución haya realizado las actividades descritas en el punto “2.3 Realizar actividades en ambiente de pruebas”, debe continuar el flujo de la solicitud de integración a la plataforma de notificaciones ingresando a CeroFilas, y debe realizar una solicitud de certificación:
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
En caso de cumplir con los parámetros establecidos, la Secretaría de Gobierno Digital habilita a la institución en producción, permitiéndole comenzar a enviar notificaciones electrónicas de los procedimientos administrativos a los interesados.
El OAE realiza la revisión y corrección: si la institución no presenta evidencias o estas no cumplen con lo esperado, debe repetir la actividad hasta realizar las acciones indicadas correctamente.
¶ Certificación
La Secretaría de Gobierno Digital (SGD), evalúa la solicitud de certificación asegurándose que las actividades descritas en el punto “2.3 Realizar actividades en ambiente de pruebas” se hayan completado:
- Configurar la institución: ingresar el logo de la institución, ingresar una o varias firmas institucionales y seleccionar procedimientos administrativos que se notificarán.
- Crear al administrador de mensajes.
- Envío de mensaje desde la plataforma web y/o API.
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 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 nuestro nodo proveedor. Para realizar la solicitud del nodo en producción, debe comunicarse con la Mesa de servicios.
¶ Habilitación en producción
La SGD habilita a la institución y al administrador institucional en la plataforma para continuar con el proceso de configuración de la institución en producción. En este paso la SGD realizará las siguientes actividades en el ambiente de producción:
- Registra a la Institución.
- Registra al Administrador Institucional indicado en el formulario.
- Se crean las credenciales para integración a través de la API en producción, si indicó en la solicitud que la integración es por API o ambas.
La institución debe:
- Configurar la institución: Ingresar el logo de la institución, luego ingresar una o varias firmas institucionales y, finalmente, seleccionar los procedimientos administrativos que se notificarán.
- Crear al administrador de mensajes.
- Solicitar nodo PISEE a través de la mesa de servicios de la SGD (opcional); si su institución ya cuenta con un nodo:
- 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 anexo 8.3 “Configuración de Nodo PISEE2”.
- El equipo de PISEE evalúa si es necesario enviar una nueva versión del nodo.
- Integrarse vía API a través del nodo PISEE (opcional).
Luego de completar los pasos de integración, la institución queda habilitada para enviar notificaciones por medios electrónicos a los interesados en los procedimientos administrativos definidos en la plataforma.
¶ Envío de notificación por parte del OAE desde la interfaz web
El OAE cuenta con dos mecanismos no excluyentes de practicar las notificaciones electrónicas: mediante la interfaz web y de manera automática con la integración vía API. En ambos casos, antes de enviar la primera notificación la institución debe estar configurada.
¶ Envío de notificación
Como precondición a este proceso, todas las actividades descritas en la sección “2.6-Habilitación en producción” deben estar realizadas.
El usuario podrá optar por enviar mensajes con la opción de Mensaje Simple, esto es un solo mensaje a uno o más destinatarios, en los que todos reciben el mismo contenido y archivos adjuntos. También se pueden enviar mensajes a través de la opción de Mensaje Múltiple, esto último es enviar un mensaje para distintos grupos de destinatarios, en donde por cada grupo se podrá individualizar los destinatarios y archivos adjuntos. Esta opción en la plataforma, la puede encontrar en el menú del administrador del mensaje como “Crear mensaje”.
Luego, el usuario debe indicar el Procedimiento Administrativo para el cuál necesita practicar la notificación, el cuál el administrador institucional lo debió haber añadido a la plataforma previamente.
Si al enviar un mensaje, no encuentra en la lista el procedimiento administrativo que desea notificar, debe reportarlo al administrador institucional de la plataforma, para que verifique si ya fue añadido en la lista del notificador.
Finalmente, el usuario puede redactar la notificación agregando a los destinatarios de manera manual o por archivo .csv, agregando: asunto, cuerpo del mensaje y archivos adjuntos; de la misma forma que un correo electrónico tradicional.
Si configuró una o más firmas para su institución, puede elegir una para que se muestre en el mensaje, también puede enviar mensajes tomando como base las plantillas creadas previamente.
Para más detalles refiérase al Manual de Usuario Institucional disponible en: Manual-instituciones-Plataforma-notificador.
¶ Adjuntos enviados en una notificación
En un mensaje simple se pueden enviar archivos cuyo peso no sea mayor a 20 MB, en un archivo o varios que en total no superen el peso indicado. Los archivos adjuntos enviados en las notificaciones, deben tener alguna de estas extensiones: pdf, jpg, png, word (doc. docx), excel(xls, xlsx). Si el archivo tiene firma electrónica, ésta debe ser válida y el documento no debe estar adulterado para poder adjuntarlo. La plataforma acepta y valida archivos con firma electrónica en formato PDF.
¶ Estado de envío 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 al detalle de cada mensaje. La plataforma maneja 3 estados:
- 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.
¶ Envío de notificación por parte del OAE desde la API
La API de notificaciones permite gestionar las notificaciones (envíos de mensajes y visualización de sus estados) a las instituciones que se encuentren habilitadas en la plataforma de notificaciones. Las validaciones para el envío de un mensaje que se realizan en un mensaje enviado desde la WEB son las misma que se realizan desde la API, por lo que todas las actividades descritas en la sección “2.6-Habilitación en producción” deben estar realizadas antes de realizar un mensaje desde este canal.
Para consumir esta API es necesario tener configurado un nodo de interoperabilidad PISEE 2, además de un client_id y un client_secret asociado a la institución que desea utilizar la plataforma.
¶ Envío de notificaciones desde la API
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)
| Campo | Tipo | Obligatorio | Descripción |
|
recipients |
Arreglo |
Sí |
Lista de destinatarios, cada destinatario se identifica por un objeto con el atributo “rol_unico” que corresponde al rol único del destinatario (ya sea RUN o RUT) sin dígito verificador. (máximo 250 destinatarios) Por ejemplo:
|
|
message_type |
Cadena. | Sí |
Corresponde al tipo de notificación. Puede ser de alguno de los siguientes valores:
CP: Comunicación Personal CI: Comunicado Institucional |
|
procedure_code |
Cadena |
Obligatorio solo si message_type = NT |
Código del procedimiento administrativo. |
|
procedure_stage |
Numérico |
Obligatorio solo si message_type = NT |
Etapa del procedimiento administrativo en formato numérico. Puede ser de alguno de los siguientes valores: 1 = Etapa de inicio 2 = Etapa de instrucción 3 = Etapa de finalización |
|
signature_uid |
Cadena (UUID) | No | Identificador único universal (UUID) de la firma institucional a utilizar. Solo si se envía un mensaje con una firma institucional. |
|
subject |
Cadena | Sí | Asunto de la notificación. |
|
content |
Cadena | Sí | Contenido de la notificación. |
|
content_type |
Cadena | Sí |
Tipo MIME del contenido de la notificación. Por ejemplo "text/html" |
|
webhook_url |
Cadena (URL) | No | URL para recibir el estado del procesamiento del mensaje. Si se especifica se gatilla una petición post a la URL indicada cuando se inicia el proceso de envío de dicho mensaje. Dentro del body se envía la información del resultado del envío: status y message_data_id. Si no se especifica se debe enviar como null o vacío, ejemplo: "webhook_url": "" ó "webhook_url": null |
Tabla 1. Descripción del objeto JSON para enviar un mensaje
¶ attachments (archivos adjuntos)
- Formato: Archivo binario
- Se pueden incluir múltiples archivos adjuntos usando varios campos attachments en el formulario
- Restricciones:
- Límite de tamaño por archivo individual: 20MB
- Límite de tamaño total de adjuntos: 20MB
- Los tipos de adjuntos soportados son: pdf, jpg, png, word (doc. docx), excel(xls, xlsx); los pdf con firma electrónica serán validados.
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 Carga 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"
}Figura 22. Ejemplo de respuesta después de enviar un mensaje
¶
Errores en el envío de mensaje desde la API
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"
}Figura 23. Ejemplo de respuesta después de enviar un mensaje con error
Posibles mensajes en la validación del envío: A continuación se presentan todos los estados mensajes de validación del contenido del mensaje que se está intentando enviar.
|
Código |
Mensaje | Posibles causas y acciones |
|
ERR001 |
No se proporcionó ningún destinatario para el mensaje |
No se proporcionó un valor válido para "recipients". Este atributo espera un arreglo de destinatarios de la siguiente forma (debe contener al menos un registro): "recipients": [ { "rol_unico": 16724949 } ] |
|
ERR002 |
El/los siguiente(s) índices contienen elementos no esperados para destinatarios [i, j, k] |
Alguno de los nodos en "recipients": [ ... ] no contiene el atributo "rol_unico". El mensaje indica los índice dentro del arreglo que no cumplen este requisito, el primer elemento del arreglo corresponde al 0 |
|
ERR003 |
El/los siguiente(s) índices de destinatarios no son válidos [i, j, k], verifique el contenido o longitud del dato |
Alguno de los nodos en "recipients": [ ... ] no contiene un valor válido para "rol_unico". El mensaje indica los índices dentro del arreglo que no cumplen este requisito, el primer elemento del arreglo corresponde al 0. "rol_unico" es de tipo entero positivo y no debe exceder el valor 99.999.999 |
|
ERR004 |
Código de tipo de mensaje no ingresado | No se proporcionó un valor para "message_type", este campo es obligatorio y corresponde al código de tipo de mensaje |
|
ERR005 |
Código de tipo de mensaje no permitido |
1. El código de tipo de mensaje enviado en el campo "message_type" no es uno de los tipos válidos (NT,CP,CI) 2. Se envío un código válido, pero su institución no está habilitada para enviar ese tipo de mensajes |
|
ERR006 |
Código de procedimiento administrativo no ingresado | No se ingresó un valor válido para el campo "procedure_code". Es requerido siempre que se intente enviar un mensaje de tipo notificación ("message_type" : "NT"). En cualquier otro tipo de notificación es opcional |
|
ERR007 |
Código de procedimiento administrativo no válido | El código de procedimiento enviado en el campo "procedure_code" no existe o no ha sido habilitado para el envío de notificaciones desde su institución |
|
ERR008 |
Debe configurar el logo de su institución en la plataforma | La institución que está intentando enviar el mensaje aún no ha configurado el logotipo en la plataforma. Antes de enviar cualquier mensaje es necesario configurar el logotipo, por favor contacte con su administrador de institución. |
|
ERR013 |
El archivo [índice/posición del archivo] tiene un formato no permitido. Selecciona un formato válido | Se adjuntó un archivo al mensaje y la extensión es diferente a: pdf, jpg, png, word (doc. docx), excel(xls, xlsx) |
|
ERR014 |
El nombre del archivo [índice/posición del archivo] debe tener máximo 50 caracteres | El nombre de un archivo adjuntado en el mensaje excede a los 50 caracteres |
|
ERR015 |
El límite total para los adjuntos es de 25 MB. Elige un archivo que no exceda ese límite | La suma de los archivos que se adjuntaron al mensajes es mayor a 20 MB |
|
ERR016 |
El Archivo [índice/posición del archivo] ya fue adjuntado | En los archivos que fueron adjuntados al mensaje hay archivos duplicados o tienen el mismo nombre |
|
ERR017 |
El contenido del archivo [índice/posición del archivo] (base64) no tiene el formato correcto | En los archivos que fueron adjuntados un base64 no tiene el formato correcto (caracteres y tamaño múltiplo de 4) |
|
ERR018 |
La extensión del archivo [índice/posición del archivo] no corresponde con el tipo de documento | En los archivos que fueron adjuntados existe una extensión que no corresponde con el tipo de documento adjuntado |
|
ERR019 |
El archivo [índice/posición del archivo] excede los 20 MB permitidos. Elige un archivo que no exceda ese límite | Se adjuntó un archivo y su peso es de 20 MB o más |
|
ERR020 |
Firma no válida | Se añadió el código de una firma que pertenece a otra institución |
|
ERR021 |
El archivo [índice/posición del archivo] no se ha cargado por los siguientes motivos: El archivo está adulterado, fué modificado después de su firma y/o tiene firma(s) revocada(s)” | Se adjuntó un archivo en donde alguna de las firmas del archivo está adulterado, fue modificado después de su firma y/o tiene firma(s) revocada(s) |
|
ERR023 |
RUN no válido | El RUN ingresado, tiene caracteres que no son números, está fuera de la cantidad de dígitos permitidos o no se envió ningún valor |
|
ERR026 |
No se puede enviar el mensaje, cantidad de caracteres excede al número permitido de 150 caracteres | La cantidad de caracteres en el asunto excede a los 150 permitidos |
|
ERR027 |
No se puede enviar el mensaje, asunto del mensaje no ingresado | Asunto del mensaje no ingresado |
|
ERR028 |
No se puede enviar el mensaje, URL no válida | URL en el contenido del mensaje no es válida o no se añadió ninguna |
|
ERR030 |
No se puede enviar el mensaje, se permite hasta 250 destinatarios en un mensaje | Se colocó una lista de destinatarios mayor a 250 |
|
ERR031 |
Este es un envío duplicado, si estás seguro de que debe enviarse, debes esperar 5 minutos desde que apareció este mensaje por primera vez. | Un mensaje con el mismo contenido se ha enviado en un período dentro de 5 minutos |
|
ERR032 |
El límite total de archivos permitidos se ha superado, elige hasta 50 archivos. | Se adjuntó más de 50 archivos al mensaje |
|
ERR033 |
Debes renombrar el archivo, usando sólo letras (sin acentos ni ñ), números y como separadores usa guiones, guiones bajos o espacio (sin usarlos al inicio, al final o juntos) | se adjuntó un archivo cuyo nombre tiene caracteres diferentes a los permitidos: letras, números, guiones (-, _), espacios. |
|
ERR034 |
No se puede enviar el mensaje, el atributo webhook tiene una URL no válida | Se colocó una URL con una estructura que no corresponde con la esperada |
Tabla 2. Posibles mensajes de error al enviar un mensaje
¶ ¿Cómo conocer el estado de una notificación enviada desde la API?
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
}
}
}
Figura 24. Ejemplo de respuesta de estado de un mensaje para diferentes destinatarios
Posibles estados de un mensaje: A continuación se presentan todos los estados posibles que puede tener un mensaje.
| Estados | Descripción |
| pending | Estado inicial, al crear el envío se crea con este estado. |
| delivered | Estado final, el envío queda con este estado al finalizar el proceso de enviar los mensajes. |
| error | Falló al momento de crear/actualizar el envío para el destinatario correspondiente. |
| error_rejected | Se ha determinado que el mensaje es sospechoso o no es válido |
| error_undetermined_undetermined | No se ha podido determinar un motivo específico de rebote. |
| error_permanent_general | Ha ocurrido un rechazo permanente general. |
| error_permanent_no_email | Ha ocurrido un rechazo permanente porque la dirección de correo electrónico de destino no existe. |
| error_permanent_supressed | Se ha descartado el envío a esta dirección dado que tiene un historial reciente de rebotes como dirección no válida. |
| error_permanent_on_account_suspension_list | Se ha descartado el envío a esta dirección porque está en la lista de correos electrónicos con rebotes previos. |
| error_transient_general | Ha ocurrido un rebote general. Es posible que pueda enviar correctamente a este destinatario en el futuro. |
| error_transient_mailbox_full | Ha ocurrido un rebote. La bandeja de mensajes del destinatario está llenared |
| error_transient_message_too_large | Ha ocurrido un rebote. Mensaje demasiado grande |
| error_transient_content_rejected | Ha ocurrido un rebote. Contenido rechazado |
| error_transient_attachment_rejected | Ha ocurrido un rebote. Archivo adjunto rechazado |
| error_send_message_mail | No se ha podido comunicar con el servidor de correo |
Tabla 3. Tabla con estados para un mensaje
Estado de configuración de DDU: Al momento que se envían los mensajes, para DDU configurados como email, temporalmente y por pocos segundos, quedan en estado “pending”; para los otros casos inicialmente quedan como delivered; esto pasa para cada destinatario de un mensaje. A continuación una tabla con valores para el estado del mensaje para un destinatario que puede mostrar de acuerdo a la configuración de DDU:
| Estado DDU destinatario | Estado mensaje inicial | Estado mensaje Final |
| DDU no configurada | delivered | delivered o error |
| DDU excepcionada | delivered | delivered o error |
| DDU configurada como casilla | delivered | delivered o error |
| DDU configurada como correo electrónico | pending | delivered o error (todos los posibles errores indicados en la tabla 3 sección 4.3) |
Tabla 4. Tabla con estados del mensaje según la configuración de DDU
¶
¿Cómo ver los mensajes pendientes por leer de un ciudadano, desde la API?
Endpoint que se dispone para mostrar la cantidad de notificaciones sin leer de un ciudadano. Para ver los mensajes pendientes de lectura 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.
{
"access_url": "https://portal.devel.casillaunica.gob.cl/ext/bandeja",
"current_ddu_type": "casilla",
"result_message": "Usuario tiene mensajes pendientes por leer en su casilla",
"status": true,
"total_pending": 11
}Figura 25. Ejemplo de respuesta a consulta de mensajes en estado pendiente para un destinatario
¶ ¿Cómo obtener los códigos de los procedimientos administrativos desde la API?
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"
}
]
}
Figura 25. Ejemplo de respuesta a consulta de procedimientos administrativos
Posibles salidas: A continuación se presentan los posibles mensajes que puede retornar este endPoint de acuerdo a los procedimientos administrativos asociados a la institución.
| Tiene procedimientos | Resultado |
| SI | Lista con los procedimientos administrativos y sus datos. |
| NO | Un mensaje que indique que no existen Procedimientos administrativos registrados. |
Tabla 6. Tabla con salida de procedimientos administrativos
¶ ¿Cómo obtener los identificadores únicos universales de las firmas institucionales desde la API?
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"
}
]
}
Posibles salidas: A continuación se presentan los posibles mensajes que puede retornar este endPoint de acuerdo a las firmas institucionales creadas.
| Tiene firmas | Resultado |
| SI | Lista con las firmas institucionales y sus datos. |
| NO | Un mensaje que indique que no existen firmas institucionales registradas. |
¶ ¿Cómo obtener un comprobante de mensajes desde la API?
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
Posibles salidas: A continuación se presentan los posibles mensajes que puede retornar este endPoint de acuerdo al certificado de mensajes de un ciudadano.
| Se genera comprobante | Resultado |
| SI | Una URL con el certificado de mensajes para descargar. |
| NO | Un mensaje que indique que no se puede descargar el comprobante, el mensaje no ha sido enviado. |
Posibles mensajes en la validación del comprobante: A continuación se presentan todos los mensajes de validación del comprobante de mensaje que se está intentando obtener.
|
Código |
Mensaje | Posibles causas y acciones |
|
ERR022 |
Código de mensaje no válido | El código no existe, pertenece a un mensaje de otra institución o no cumple el formato. |
|
ERR023 |
RUN no válido | El run tiene caracteres que no son números, está fuera de la cantidad de dígitos permitidos. |
|
ERR024 |
Mensaje no válido | El certificado que se puede obtener ya que no corresponde al destinatario. |
|
ERR025 |
No se puede descargar el comprobante, el mensaje no ha sido enviado | Dado que un mensaje que fue enviado por la API o la web y no se envió correctamente, se encuentra “en proceso” o con “error”, entonces no se puede generar un comprobante. |
¶ Nivel de transacciones en la API
La API y todos sus servicios estarán disponibles 24 x 7 con un máximo de 6 TPS.
¶ Procedimiento para registro de una Excepción
En esta opción, el funcionario designado como administrador institucional podrá registrar una excepción para un ciudadano que, previa solicitud, quede exento de recibir notificaciones electrónicas, conforme a lo establecidos en el capítulo III, párrafo 1, artículo 46 de la ley 19.880 de Transformación Digital del Estado.
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”.
¶ ¿Cómo un OAE puede obtener el certificado de envío de notificaciones?
La plataforma dispondrá una opción para descargar un certificado de envío de cada mensaje , que certifica que se ha realizado el envío de un mensaje a un destinatario, en la fecha y hora y con los datos mostrados en el certificado; se podrá obtener desde la plataforma web y a través de la API. Los certificados descargados podrán ser validados por cualquier persona.
¶ ¿Qué debe hacer un AOE si tiene alguna inquietud o inconveniente con la plataforma?
La mesa de servicios para las instituciones estará a cargo de la Secretaría de Gobierno Digital (SGD). Puede dejar sus solicitudes en el siguiente formulario: https://gobdigitalcl.freshdesk.com/support/home. Ver figura 29
Para informar sobre otros inconvenientes o hacer sugerencias, puede escribir al correo del producto. Ver figura 30
¶ Anexos
¶
Ejemplos de uso de API en cURL
¶ Envío de Notificaciones
curl --location '{url}/notificador/sendMessage' \
--form 'data="{
\"recipients\": [
{\"rol_unico\": 26093912},
{\"rol_unico\": 26789805}
],
\"message_type\": \"NT\",
\"procedure_code\": \"PA-SUP00604-00007\",
\"procedure_stage\": 1,
\"signature_uid\": \"92d6692d-a401-4f7f-918c-c3c74ae1b3b5\",
\"subject\": \"Mensaje de Prueba\",
\"content\": \"Recordemos que, el Nuevo Ingreso Familiar de Emergencia (IFE), promulgado el domingo 21 de junio, amplió su cobertura y aumentó los montos, para apoyar a los hogares con ingresos informales o formales insuficientes que se han visto afectados por la crisis sanitaria y económica provocada por el brote de Covid-19, como parte del conjunto de medidas que el Gobierno ha implementado en la actual contingencia. Para acceder al beneficio es necesario que la persona tenga Registro Social de Hogares (RSH) y que pertenezca al 90% más vulnerable. Pero, además se creó un nuevo indicador para contar con información más actualizada de la vulnerabilidad socioeconómica de las familias durante la emergencia: El Indicador Socioeconómico de Emergencia (ISE) y en cuyo caso se requiere que los hogares además se encuentren dentro del 80% de este indicador.\",
\"content_type\": \"text/html\",
\"webhook_url\": \"https://institucion.com/recibir-update-mensaje\"
}"' \
--form 'attachments=@"/ruta/al/archivo/archivo.png"' \
--form 'attachments=@"/ruta/al/archivo/archivo.pdf"'¶ Ver estado de un envío
curl --location '{url}/notificador/messageStatus/6789a014291e172670ae075e'
¶ Ver mensajes pendientes de un ciudadano
curl --location '{url}/notificador/citizenPending/26093912'
¶ Ver procedimientos administrativos de una institución
curl --location '{url}/notificador/getProcedure'
¶ Ver las firmas administrativas de una institución
curl --location '{url}/notificador/getSignature'
¶ Obtener un comprobante de mensaje de un ciudadano
curl --location '{url}/notificador/getReceipt/64f65a4d144e0d5ac4bfd25e/26093912'
¶ Ejemplos de uso de API en Postman
¶
Envío de notificaciones
Envío de un mensaje a dos destinatarios desde Postman, se puede ver la url del servicio, método y respuesta.
¶ Ver estado de un envío
Consulta de estado de un mensaje enviado, se debe ingresar como parámetro el message_id del mensaje.
¶ Ver mensajes pendientes de un ciudadano
Consulta de mensajes pendientes que tiene un ciudadano.
¶ Configuración de Nodo PISEE 2
¶ Credenciales de API de Notificaciones
Para registrar las credenciales necesarias para comunicarse con la API de Notificaciones se requiere ajustar los siguientes parámetros en el archivo config.json del nodo PISEE que le fue entregado.
Dentro del elemento “identificación”.”custom” se deben agregar o ajustar los valores de:
id: Corresponde al client_id que identifica a su Institución
secret: Corresponde al client_secret que identifica a su Institución
¶ Endpoints de de API de Notificaciones
Para poder acceder a los servicios provistos por la API de Notificaciones a través del nodo de PISEE 2 es necesario registrar cada uno de los endpoints o servicios que se desean consumir. Esto se hace en el archivo config.json del nodo PISEE que le fue entregado.
Dentro del arreglo “consumidor” se deben listar los servicios que su Institución desea utilizar.
