Información Preliminar
Disponibilidad de la API
Conexión y uso del servicio
Información preliminar
¿Qué es CoFFEE y CoFFEE-MRR?
CoFFEE (Plataforma Común de Fondos Europeos) es la plataforma informática común para la gestión de fondos europeos. Está orientada a integrar los diversos módulos que dan soporte a la gestión de los fondos europeos competencia de la Secretaría General de Fondos Europeos (SGFE) en el marco financiero plurianual 2021-2027 (MFP 21-27). Es la evolución de los sistemas de información que dan soporte a la gestión del Fondo Europeo de Desarrollo Regional (FEDER) en los marcos financieros previos al 2021-2027, pero ha sido concebida para albergar el soporte a otros fondos y/o mecanismos.
CoFFEE-MRR es un módulo de CoFFEE que aprovecha la tecnología, los procesos transversales, los mecanismos de incorporación de la información, etc. de la plataforma, y que incorpora la funcionalidad necesaria para la planificación, la gestión y el seguimiento de las iniciativas asociadas al Mecanismo de Recuperación y Resiliencia, y en concreto al Plan de Recuperación, Transformación y Resiliencia (PRTR).
¿Cómo solicito el acceso a CoFFEE/CoFFEE-MRR?
El procedimiento para solicitar el acceso a los sistemas de la Administración Presupuestaria está descrito en la sección
“Control de Accesos” del Portal de Administración Presupuestaria.
Disponibilidad de la API
¿Para qué sirve la API de CoFFEE?
Los servicios electrónicos se ponen en funcionamiento para facilitar a las entidades ejecutoras de las iniciativas dar cumplimiento a lo establecido en la normativa que regula el Plan, y en particular en la Orden HFP/1030/2021, de 29 de septiembre, por la que se configura el sistema de gestión del Plan de Recuperación, Transformación y Resiliencia (Orden de Gestión), y la Orden HFP/1031/2021, de 29 de septiembre, por la que se establece el procedimiento y formato de la información a proporcionar por las Entidades del Sector Público Estatal, Autonómico y Local para el seguimiento del cumplimiento de hitos y objetivos y de ejecución presupuestaria y contable de las medidas de los componentes del Plan de Recuperación, Transformación y Resiliencia (Orden de Intercambio), y está dirigida a las entidades que dispongan de capacidad y recursos para conectar sus propios sistemas de gestión con CoFFEE para proporcionar la información requerida.
Las entidades que no dispusieran de esa capacidad pueden incorporar la información de forma interactiva, para lo cual previamente deben solicitar el acceso.
¿Está la API REST ya disponible para conectarme?
Sí. Se puede consultar el estado de implementación de los diferentes endpoints en:
estado de endpoints.
Listado de versiones
| Fecha | Versión | Entorno | Enlace al API | Novedades |
|---|
| Abril 2025 | 2.0.6 | Producción |
Enlace a la versión 2.0.6 | Adaptación a cambios funcionales de CoFFEE |
| Abril 2025 | 2.0.5 | Sustituida por v2.0.6 |
Enlace a la versión 2.0.5 | Adaptación a cambios funcionales de CoFFEE |
| Febrero 2025 | 2.0.4 | Sustituida por v2.0.5 |
Enlace a la versión 2.0.4 | Adaptación a cambios funcionales de CoFFEE |
| Diciembre 2024 | 2.0.3 | Sustituida por v2.0.4 |
Enlace a la versión 2.0.3 | Nuevos instrumentos jurídicos: Instrumentos financieros directos, instrumentos financieros indirectos, acuerdos de ejecución, acuerdos de intermediación. |
| Octubre 2024 | 2.0.2 | Sustituida por v2.0.3 |
Enlace a la versión 2.0.2 | Definición de los servicios para el registro de progreso de indicadores. Definición de los servicios para la consulta de certificados de (no) revocación. |
| Junio 2024 | 2.0.1 | Sustituida por v2.0.2 |
Enlace a la versión 2.0.1 | Definición de los servicios para el alta de actuaciones, subproyectos instrumentales, subproyectos y proyectos. Definición de los servicios para el registro de progreso y seguimiento de indicadores. |
| Marzo 2024 | 2.0.0 | Sustituida por v2.0.1 |
Enlace a la versión 2.0.0 | |
| Marzo 2024 | 1.5.2 | Producción |
Enlace a la versión 1.5.2 | Parámetro codigoPropietario opcional en algunos listados e información de proyecto en subproyecto, subproyectos instrumentales y actuaciones. |
| Enero 2024 | 1.5.1 | Sustituida por v1.5.2 |
Enlace a la versión 1.5.1 | Adaptación de la definición de los servicios a los cambios funcionales de CoFFEE. Corrección de errores. |
| Noviembre 2023 | 1.5.0 | No implementado |
Enlace a la versión 1.5.0 | Adaptación de la definición de los servicios a los cambios funcionales de CoFFEE. |
| Abril 2022 | 1.3.1 | No Implementado |
Enlace a la versión 1.3.1 | Se tratan separadamente las declaraciones de progreso de indicadores (también se limitan los valores posibles para los indicadores cualitativos) y de ejecución financiera. Finalmente se incluyen los documentos contables DO y DO/. |
¿Hay mecanismos alternativos al API para proporcionar información a la plataforma?
Sí, dependiendo del tipo de información a reportar, el sistema facilitará mecanismos para que la información se proporcione de forma interactiva por los usuarios que se conecten a él, y también mediante la incorporación (interactiva) de un archivo con todos los datos a tratar.
Naturalmente, CoFFEE realizará las mismas validaciones cuando se proporcione la información de forma masiva a través de la carga de un fichero.
¿Cuál es el formato de codificación del fichero JSON que se carga en CoFFEE?
La codificación es UTF-8.
Conexión y uso del servicio
¿Cómo solicito el acceso a la API y qué procedimiento desencadena?
En el caso de que se desee proceder a integrar una aplicación de gestión externa con CoFFEE debe consultar el documento con las instrucciones para la cumplimientación de la autorización para actualizar información en CoFFEE mediante API.
El procedimiento se puede resumir en estos puntos:
2.La OIP se pondrá en contacto con el departamento técnico solicitante a través del buzón de correo CoFFEEDesarrollo@igae.hacienda.gob.es indicando el usuario que identifica la aplicación de gestión.
3.Los responsables de la información de los nodos (proyectos, subproyectos y subproyectos instrumentales del PRTR) autorizan que el usuario que identifica la aplicación de gestión que les da servicio pueda acceder y editar los datos de los nodos.
4.El departamente técnico solicitante configura el certificado electrónico que se usará para la comunicación segura.
¿Cómo se logra la seguridad en el acceso?
Los servicios Web cliente se autenticarán mediante HTTPS/TLS (1.2 o superior). En concreto, se utilizará un certificado de sello de Administración, órgano o entidad de derecho público para actuación administrativa automatizada, o un certificado de sello electrónico cualificado derivado del Reglamento eIDAS, emitido en cualquier caso por alguno de los prestadores de servicios de certificación reconocidos por el servicio @Firma.
Durante el proceso organizativo de autorización de acceso se acuerda entre la Oficina de Informática Presupuestaria y el contacto técnico del organismo interesado el certificado que utilizará el extremo cliente del servicio
¿Cómo es una interacción típica con el servicio (una llamada a un método del API)?
Una vez ha finalizado el proceso de autorización del acceso, el sistema cliente está en condiciones de hacer uso del servicio. Para ello, toda interacción se llevará a cabo bajo una comunicación segura (TLS) utilizando el certificado de sello preacordado.
Cada llamada al servicio REST incluirá en la petición HTTP, además de los parámetros indicados en la documentación del propio servicio, dos parámetros adicionales (idUsuario e idAplicacion), que contendrán los valores que se facilitaron durante el proceso de configuración del acceso.
¿Pueden varias organizaciones utilizar el mismo certificado de sello para interactuar con el API?
Aunque no es habitual, esa posibilidad se habilita si se tramitan dos solicitudes de acceso, una por cada una de las organizaciones, y se configura el mismo certificado en ambas. En el proceso de autorización se creará y asignará un usuario de servicio (idUsuario) distinto para cada una de ellas, y se configurarán en CoFFEE los correspondientes perfiles que actúen en cada uno de los ámbitos.
Dado que cada petición al servicio incluye entre sus parámetros el código de usuario de servicio (idUsuario), CoFFEE podrá determinar el origen y podrá actuar en consecuencia, aplicando el perfil de seguridad correspondiente..
No obstante lo anterior, hay que tener en cuenta que si una de las organizaciones utilizara el idUsuario asignado a la otra, no existiría ningún mecanismo para identificar la suplantación, por lo que esta posibilidad se llevará a cabo a riesgo de las organizaciones cliente.
¿Hay límites establecidos para el uso del servicio?
Se han definido los siguientes límites:
- Tamaño máximo de petición: 100MB.
- Tamaño máximo de documento: 60MB.
- Límite máximo de elementos en una colección: 100 elementos.
- Número máximo de peticiones por segundo: 5 peticiones.
- Número máximo de documentos subidos sin asociar: 20 documentos.
Preguntas generales sobre la API
¿Cuál es el formato de las fechas?
Se sigue la especificación OpenApi 3.0 que hace referencia a la definición
RFC 3339, sección 5.6, por ejemplo
2022-07-21.Es importante destacar que algunas fechas solicitadas se deben especificar en trimestres.
¿Son todos los campos de la API obligatorios?
No, sólo son obligatorios aquellos campos que están marcados como tales (con un asterisco en rojo).
En relación a las declaraciones de progreso de indicadores: el campo “fecha” (la fecha de referencia del progreso), ¿tiene que ser la fecha actual?
La fecha de referencia del progreso de un indicador es aquella en que se considera alcanzado el valor del indicador que se actualiza, y por tanto tiene que ser anterior o igual a la fecha actual, es decir, no se permiten fechas futuras.
¿Por qué en el caso de indicadores cuantitativos se informa la “variación” y en el caso de indicadores cualitativos se informa el “valor”?
Los indicadores son medidores del progreso y pueden ser cuantitativos (su valor es un dato numérico dentro de un rango) o cualitativos (pueden adoptar un valor de entre un conjunto cerrado de opciones)
- En el caso de indicadores cuantitativos se debe informar la variación producida desde el valor anterior del indicador. Por ejemplo, si el indicador es “Número de vehículos eléctricos matriculados” y se ha pasado de 1000 a 3000 vehículos, se declarará “2000”.
- En el caso de indicadores cualitativos se debe informar el nuevo valor que ha tomado de entre los posibles (inicio, en curso y finalizado).
El motivo por el que para los indicadores cuantitativos se proporciona la variación es que el sistema permite incorporar una justificación (textual y, opcionalmente, acompañada de archivos). Se entiende que en el momento de la declaración se está justificando el valor incrementado (o decrementado) de un indicador, y no el valor final alcanzado (en el ejemplo anterior, se justifican los 2000 vehículos que se han matriculado).
En el caso de los indicadores cualitativos, se produce un cambio en su estado, y por tanto se declara el estado alcanzado.
¿Qué es la referencia de un instrumento jurídico?
En las declaraciones de ejecución contable se especifica una referencia del instrumento jurídico bajo el que se hace la declaración. El caso típico es un contrato o una subvención, pero todos los instrumentos previstos deben poder ser identificados.
La referencia es, por tanto, un código que identifica al instrumento jurídico concreto en el ámbito de la Actuación para la que se registra la ejecución.
Habitualmente la referencia coincide con el propio código del instrumento que establece la persona que lo da de alta en CoFFEE (bien sea por pantalla, carga masiva, ...).
Por ejemplo, en el caso de una subvención dada de alta en CoFFEE con el código BDNS "576282", la referencia es exactamente ese mismo código. O un contrato (no PLACSP) que se ha dado de alta en CoFFEE con el código de contrato "2023OIP45544", tendrá ese mismo código como referencia.
Sin embargo, hay un caso más complejo que es el de los contratos PLACSP, y que se trata específicamente en la siguiente cuestión.
¿Cómo se diferencia un contrato que está dado de alta en la Plataforma de Contratación del Sector Público (PLACSP) de uno que no lo está?
Los contratos PLACSP se identifican por tres códigos: código de órgano de contratación, código de licitación, y código de contrato (ver siguiente cuestión para una explicación detallada). Los contratos no PLACSP se identifican mediante un único código.
En las entradas de alta de contratos en CoFFEE, los dos tipos de contrato se identifican de forma separada.
Dado que las referencias de instrumentos jurídicos se hacen a través de un único campo, en el caso de contratos PLACSP (que, como se ha indicado, tienen tres códigos) la referencia corresponde a la concatenación de los tres valores utilizando el separador “~” entre ellos, incluso aunque los campos estuvieran vacíos.
¿Qué son los códigos órgano de contratación, de licitación y de contrato de PLACSP?
El
código del órgano de contratación es un identificador que usa la Plataforma de Contratación del Sector Público (PLACSP) asociado a cada uno de los órganos (en PLACSP se denomina “ID Plataforma”). Cada órgano de contratación puede consultar el suyo propio en la pantalla de administrador del perfil “administrador del órgano de contratación” de PLACSP.
Además, la Dirección General de Patrimonio del Estado publica periódicamente la relación de códigos en una
hoja Excel que van actualizando.
En el caso de PLACSP y para cada órgano de contratación, los códigos de licitación y de contrato son los que identifican de forma única un contrato que se incorpora a la Plataforma de Contratos del Sector Público:
El
código de licitación se corresponde con el Número de Expediente en la PLACSP, que es el número de expediente que proporciona cada órgano de contratación.
El
código de contrato corresponde con el Contrato de la PLACSP. Es también un valor que determina el órgano de contratación. Corresponde a cada contrato dentro del expediente.
En cualquier caso, ambos son valores que proporciona el gestor a la PLACSP. Ambos se pueden ver en la siguiente imagen.
¿Cuándo se cumplimenta el campo “Otras Fuentes de financiación”?
La información sobre otras fuentes de información se cumplimentará cuando la actuación a la que corresponde la operación esté financiada por alguna otra fuente, de manera adicional a la financiación con cargo al Mecanismo de Recuperación y Resiliencia. En este caso, se identificará el mecanismo o fondo que ha financiado la operación.
Cambios destacados de v1.3.1 a v1.5
Se listan los cambios destacados según el tipo de datos:
-
Todos los tipos:
- codigoIniciativa es ahora codigoActuacion
-
Medida:
- fechaInicio su valor es un trimestre
- fechaFin su valor es un trimestre
-
Contrato:
- contratoPLACSP es ahora codigoInstrumento, codigoLicitacion y codigoOrgano
- contratoNoPLACSP es ahora codigoInstrumento
-
Subvencion:
- convocatoriaBDNS es ahora codigoInstrumento
-
Iniciativa:
- Separada en Proyecto, Subproyecto, SubproyectoInstrumental y Actuacion.
- fechaInicio su valor es un trimestre
- fechaFin su valor es un trimestre
-
DeclaracionFinanciera
-
DeclaracionProgresoIndicador
- codigoIniciativa ahora se llama codigoOrigenProgreso
Por norma general, los campos desaparecidos no es necesario informarlos.
Cambios destacados de v1.5.0 a v1.5.1
-
Ruta:
- Se ha actualizado la ruta POST /ejecucion/otros-instrumentos/destinatarios
- Se han actualizado las rutas de detalle de un instrumento jurídico. El parámetro {referencia} se convierte en parámetro de query. Por ejemplo, GET /estructura/actuaciones/{codigo}/convenios/{referencia} se convierte en GET /estructura/actuaciones/{codigo}/convenios/detalle?referencia={referencia}
-
Actuacion:
- Se ha actualizado el campo transferenciaDeRecursosEconomicosAOtroSubproyecto de Actuacion, se convierte en opcional.
- Se ha añadido el campo hitosObjetivosCriticos a Actuacion.
- Se ha actualizado el tipo del campo recursosEconomicos de Actución.
-
Subproyecto:
- Se ha eliminado el campo costeEstimado de recursosEconomicos de Subproyecto.
-
SubproyectoInstrumental:
- Se ha eliminado el campo costeEstimado de recursosEconomicos de SubproyectoInstrumental.
Cambios destacados de v1.5.1 a v1.5.2
-
codigoPropietario El parámetro codigoPropietario pasa a ser opcional en las siguientes rutas:
- /v1.5/estructura/proyectos
- /v1.5/estructura/subproyectos
- /v1.5/estructura/subproyectos-instrumentales
- /v1.5/estructura/actuaciones
Si no va incluido, la lista contendrá todos los elementos del tipo correspondiente a los que el usuario tenga acceso.
-
proyecto Los subproyectos, subproyectos instrumentales y actuaciones incluyen un resumen del proyecto al que pertenecen (propiedad
proyecto).
Cambios destacados de v2.0.0 a v2.0.1
-
Instrumentos jurídicos.
- Se han cambiado los métodos de actualización PATCH por PUT para los nueve tipos de instrumentos jurídicos.
- Se han cambiado los campos rol de los esquemas ContratistaCambios, BeneficiarioCambios y DestinatarioCambios. Ahora se devuelve la descripción y no un objeto.
- Se ha actualizado el nombre del campo importeSinIVA a importeSinIva.
- Se ha añadido la uid a las solicitudes de responsable de operación.
- Se ha arreglado un bug en solicitudes de perfil de instrumentos que no comporta gasto que no mostraba la ruta correcta.
- Se ha añadido un endpoint en los instrumentos jurídicos para anular una solicitud de responsable de operación.
- Se ha añadido un endpoint en los instrumentos jurídicos para obtener los datos de una solicitud de responsable de operación.
Cambios destacados de v2.0.1 a v2.0.2
-
Progreso de indicadores
- Se modifica la url de reportes-de-progreso a progreso-de-indicadores.
- Se incluye en la url el código del nodo al que pertenece el reporte.
- Se incluyen los endpoints necesarios para la consulta paginada de documentos.
-
Instrumentos jurídicos.
- Se devuelven los campos importeSinIvaPrimerNivel e importeTotalPrimerNivel en la información de un instrumento jurídico.
- Se permite la edición del campo numLote en contratistas.
-
Hitos y objetivos.
- Se definen e implementan los endpoints de consulta de certificados de (no) revocación.
-
Recursos económicos
- Se incluyen los endpoints para la consulta de recursos económicos.
Cambios destacados de v2.0.2 a v2.0.3
-
Progreso de indicadores
- Nuevos tipos de edición de reportes de progreso.
-
Instrumentos jurídicos
- Instrumento financiero directo.
- Instrumento financiero indirecto.
- Acuerdo de ejecución.
- Acuerdo de intermediación
- Nuevos tipos de edición de perceptores.
- Nuevo campo fecha de creación.
-
Hitos y objetivos.
- Modificación de los endpoints para el alta y la edición.
-
Seguimiento del plan
- Modificación de PUT /subproyectos/{codigo}/submedidas/{submedida} por POST /subproyectos/{codigo}/submedidas/{submedida}
Cambios destacados de v2.0.3 a v2.0.4
-
Hitos y objetivos.
- Nuevo tipo de documento 'Documentación adicional al certificado'
- Permitir múltiples documentos en controles de primer nivel de un certificado
- GET /hitos-objetivos/{codigo}/seguimiento/certificados/{uid-certificado}/controles-primer-mnivel
- GET /hitos-objetivos/{codigo}/seguimiento/certificados/{uid-certificado}/controles-primer-mnivel/{uid-documento}
- GET /hitos-objetivos/{codigo}/seguimiento/certificados/{uid-certificado}/controles-primer-mnivel/{uid-documento}/contenido
- Mejora en la información de documentos asociados a un logro:
- GET /hitos-objetivos/{codigo}/seguimiento/documentos
- GET /hitos-objetivos/{codigo}/seguimiento/documentos/{uid-documento}
Se incluye:
- Origen del documento
- En certificado firmado
- Importado en nivel superior
- Estado de (no) revocación
- GET /hitos-objetivos/{codigo}/seguimiento/estado-revocacion
- Ciclo de confirmación asociado a un certificado de (no) revocación
- GET /hitos-objetivos/{codigo}/seguimiento/certificados-revocacion/{uid-certificado}
-
Seguimiento del plan
- Información de transición de estados para P, SP y SPI.
- GET /proyectos/{codigo}/historico-estados
- GET /subproyectos/{codigo}/historico-estados
- GET /subproyectos-instrumentales/{codigo}/historico-estados
-
Documentos
- Endpoint para consulta de documentos subidos pero no asociados.
- GET /documentos-pendientes
Cambios destacados de v2.0.4 a v2.0.5
-
Hitos y objetivos.
- Nuevo tipo de documento "spreadsheet" en HGC, HGnC y CID
- Nuevo tipo de documento Índice de mecanismos de verificación
- Endpoints para mecanismos de verificación de nodos inferiores
- GET /hitos-objetivos/{codigo}/seguimiento/nivel-inferior/documentos
- GET /hitos-objetivos/{codigo}/seguimiento/nivel-inferior/documentos/{uid-documento}
- GET /hitos-objetivos/{codigo}/seguimiento/nivel-inferior/documentos/{uid-documento}/contenido
- POST /hitos-objetivos/{codigo}/seguimiento/nivel-inferior/documentos/{uid-documento}/importar
- DELETE /hitos-objetivos/{codigo}/seguimiento/nivel-inferior/documentos/{uid-documento}
-
Instrumentos jurídicos.
- Se añade importeTotalPrimerNivel en instrumentos jurídicos financieros directos e indirectos.
- Corregido el código del Tipo de Contrato "COSECPUPR - Colaboración entre el sector público y el sector privado"
-
Actuaciones.
- Revisión campos obligatorios.
- Nuevo endpoint para cambiar un instrumento jurídico de actuación.
- POST /actuaciones/{codigo}/instrumentos-juridicos/{codigo-unico}/mover/{codigo-destino}
-
Indicadores.
- El campo "valorProgresoAcumulado" devuelve -1 en el caso de tener valores diferentes en algún hito u objetivo
-
Documentos.
- Limitados los nombres de los documentos a 180 caracteres
Cambios destacados de v2.0.5 a v2.0.6
-
Instrumentos jurídicos.
- Nuevo campo 'Subvención bruta equivalente' para los beneficiarios financieros de instrumentos jurídicos de tipo IFD y IFI
Preguntas generales sobre la API v2.0
¿Cómo obtengo el código único de un instrumento jurídico?
El código único de un instrumento jurídico se obtiene de tres formas:
-
Alta de instrumento jurídico: en la respuesta de la operación de alta se devuelve el código único asignado al instrumento jurídico. Por ejemplo:
POST /v2.0/contratos -
Consulta de instrumentos jurídicos de una actuación: el listado de instrumentos jurídicos incluye el código único de cada instrumento jurídico.
GET /v2.0/actuaciones/{codigo}/instrumentos-juridicos -
Consulta de código único: existe una utilidad para obtener el código único de un instrumento jurídico a partir del código de actuación y la referencia del instrumento jurídico.
GET /v2.0/instrumentos-juridicos/utilidades/codigo-unico
¿Cómo se realiza la subida de documentos?
La subida de documentos consta de dos pasos:
-
Subida del documento: Se añade un documento nuevo al sistema y se obtiene el localizador necesario para otras operaciones. El documento se crea con el tipo PENDIENTE. Los documentos subidos y no asociados a un elemento serán borrados periódicamente. El servicio utilizado es:
POST /v2.0/documentos -
Asociación del documento con un elemento: El documento subido en el punto anterior se asocia a un elemento. En la asociación se indica el localizar el documento, el tipo efectivo y los metadatos adicionales. El servicio utilizado depende del elemento, por ejemplo, para añadir un documento a un contrato, el servicio es:
POST /v2.0/contratos/{codigo-unico}/documentos
Si se desea asociar el mismo documento a varios elementos, solo es necesario realizar una vez la subida del documento pudiendo utilizar el localizador tantas veces como sea necesario.
Otras dudas
Tengo dudas funcionales sobre la gestión del Plan de Recuperación Transformación y Resiliencia y el sistema de gestión del mismo, ¿dónde puedo dirigirme?
La descripción del funcionamiento del Plan se articula con dos Órdenes Ministeriales:
- Orden HFP/1030/2021, de 29 de septiembre, por la que se configura el sistema de gestión del Plan de Recuperación, Transformación y Resiliencia.
- Orden HFP/1031/2021, de 29 de septiembre, por la que se establece el procedimiento y formato de la información a proporcionar por las Entidades del Sector Público Estatal, Autonómico y Local para el seguimiento del cumplimiento de hitos y objetivos y de ejecución presupuestaria y contable de las medidas de los componentes del Plan de Recuperación, Transformación y Resiliencia.
Tengo más dudas técnicas relacionadas con la API, ¿dónde puedo dirigirme?
Para el resto de dudas técnicas sobre la API REST de CoFFEE, se puede escribir un mensaje a la dirección de correo electrónico de soporte CoFFEE-Desarrollo@igae.hacienda.gob.es
Desde este buzón se atenderán exclusivamente consultas de carácter técnico referidas al intercambio de información con la plataforma.